What makes top performing teams click

I came across this great New York Times article called "What Google Learned From Its Quest to Build the Perfect Team", and since the topic is near and dear to me I am taking time to share my short interpretation of this knowledge.

This research points out that best performing teams typically excel in what psychology researchers refer to "conversational turn-taking" and "average social sensitivity" behavioral norms - both relating to psychological safety defined by the Harvard Business School professor Amy Edmondson as 

"a sense of confidence that the team will not embarrass, reject or punish someone for speaking up,.. It describes a team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves."

Reducing the number of supported platform variations

Does your product support multiple platform variations (operating systems, databases, etc.)? Have you noticed how it slows your development cycle and adds to the cost of maintenance and new development? If you've contemplated how to get out of this situation, you are not alone. This is a common challenge for many established software vendors.

Consider this hypothetical example:

Two companies compete, both have the same budget. Company A only ships on Linux and only on MySQL database. Company B ships on Linux, Solaris and Windows, and supports Oracle, MySQL and PostgreSQL databases. Question, which company can offer more features, better quality and/or more frequent releases?

Of course one can argue that for Company A part of the market is simply shut off because of the strong platform preferences many customers exhibit, but is it truly always so? What if Company A offers far superior overall solution, could it in some cases swing the balance of platform preferences in its favor? Surprisingly, in many cases, yes!

New products these days are almost always pick one of the following go to market strategies to make it easier to accomplish what Company A is trying to do:

1. Appliance, where the customer gets a box, and simply does not know what OS or DB are inside;
2. SaaS, where the customer uses browser and mobile apps, and again does not know what’s in the data center behind flickering server lights.

In both cases, this helps software vendor to focus on capabilities, quality and time to market (instead of retesting the same feature set on yet another platform variation), helping better optimize available funding.

Granted, it’s a lot harder to shrink to fewer platforms vs. not letting them expand in the first place, just like losing weight. Trying to do this for an existing mature product is guaranteed to upset some of your customers, yet it is still possible to make this decision and announce that going forward you are dropping one of the operating systems and one of the databases for argument sake. In the long run this will help you better serve your customers. If you calculate this well, on a balance you will actually gain more customers, even if you initially lose some.

It's okay to be introvert

I grew up in Eastern Europe, and after immigrating to Australia and living there for 10 years I relocated with my employer to the USA. Ever since that move I started noticing one particular set of cultural differences. I felt like to be successful at work I need to fit in better, to find a way to behave in a way that is unnatural for me - to be more of an extrovert than I really am.

I found it necessary to speak louder and more frequently than I would normally do.

I observed how uneasy people feel about a pause in a conversation. Someone would often start talking without any particular substance just to fill the "awkward silence".

Somehow in this culture high performers are expected to be assertive and outgoing. The enthusiasm is expected not just at work but also during informal social events. Class Participation and Team Projects are important part of the grading process at business schools, while networking skills and etiquette at business dinners and cocktail receptions are often deemed important enough to be explicitly taught.

Over the years I watched how more and more organizations opted for open space office configuration for their employees. As much as I am a big fan of Agile and Scrum Team collaboration dynamics, I just don't find that à la "Wall Street trading floor" workplace setup conducive to any type of work requiring concentration and attention to detail.

Earlier this week I read the Forbes article titled "Research Shows There May Be A Hidden Dark Side To Working With Introverts". It mentioned Susan Cain's book "Quiet" and so I looked her up online. Susan's spirited presentation on this topic is amazing in terms of addressing this very close topic to me. 

To share or not?

Should the product teams submit their internal ideas for voting by their user communities or not?

This reminds me of the internal dilemma some A/A+ students face: to share or not, i.e. to always do their work in solitary mode or to join a study group. Personally, I've always believed I can only get better by sharing what I know. Sharing allows improving my knowledge and skills either through teaching what I know, responding to broader range of clarifying questions, or through a realization that my perceived understanding is not quite accurate.

Hence, I fully support the concept of posting internal ideas for voting and commenting by the user community.

If a potential product idea is misunderstood by the audience or not really seen as valuable it will receive few votes and will be buried by other more critical in the eyes of the user community enhancement requests. It's far better to find out early that what we think is valuable is actually not.

In addition to straight voting score, this approach also gives us the opportunity to hear back from the user community members in the form of comments, including clarifying questions, fine tuning points and additional use cases and scenarios.

As an added bonus, sharing internal ideas with our user community promotes a true two-way collaboration and trust between the product team and the customers and field.

Running our calls on time

In his article Class bells Lynn Grant reminds us of the old good times when our classes in school ended with a bell, making sure we stop and move on to our next class in a timely fashion. Would not the bells be nice in many cases in our modern life when we are scheduled to attend multiple back to back meetings and calls throughout the day? Thanks for the fond memories and releavant association Lynn!

In the absence of bells a few more tricks/ideas may help run your calls/meetings in a more efficient manner:

• We tend to always block off the entire hour, even if a 15 minutes discussion should be sufficient. Go ahead, pick a suitable next meeting and schedule a shorter time slot for it.

• Yes, we are often more accustomed to start our meetings/calls 5 minutes past the official start time, allowing participants to switch from their previous call or walk from another meeting room. If you are the organizer, try allowing your meetings to end 5 minutes before the scheduled time.

• Time boxing a particular agenda item often helps.

• When using a WebEx, a GoToMeeting or other similar online meeting technology, making sure the online roster is correctly used/initialized by everyone dialing in helps save time at the start of the call going over the participants on the call, keeps people more engaged in the conversation because at any given time everyone can see who is talking and who is listening, and reduces time waste due to inevitable noise on the line (barking dogs, crying babies, music on hold) from an anonymous caller line.

• The rule of SEVEN, i.e. if you want your meeting to be a productive one where a decision can be made quickly, don't exceed 7 participants. Recent research by Bain & Company, published in the book "Decide & Deliver: 5 Steps to Breakthrough Performance in Your Organization" indicates that once you’ve got 7 people in a decision-making group, adding an additional member reduces decision effectiveness by 10%.  As a result, large groups rarely make any important decisions, at least not in a time efficient manner.

• Don't join every meeting or call, understand why your presence is needed and decline the invitation if you don't anticipate contributing to discussion.

• Excuse yourself from the meeting if you find yourself immersed in something else, reading or answering emails for example. Your departure will reduce participants count and may help run the meeting on time, and it will certainly help you focus better on what seemed to be your primary task.

• If nothing seems to help run your meetings on time, 2-3 minutes before the end time, announce you are leaving and hang up when the meeting time is over. The more people will do this the more we will run our meetings on time.

Do you Ba?

Have you ever attended a backlog grooming session where participants appear detached, yawning around the table, the scrum master is sizing the stories and handing out the tasks, and hardly any questions are raised about the new user stories? How does this compare to the loud, agitated white board discussion, team members eagerly leaning in, volunteering their help, clarifying the objectives and acceptance criteria of the user stories presented? What's the word to describe the different feeling in these two rooms?

For a while now I've been looking for a way to describe this special spirit emanating from a high performing Agile scrum team and, thanks to Dean Leffingwell tip, I think I've finally found it.

Meet the "Ba"

In their research of organizational knowledge creation Ikujiro Nonaka and Ryoko Toyama define "Ba" as a shared context in motion, in which the context is constantly moving and the knowledge is shared, created and utilized. Through interactions with others and the environment, both the contexts of Ba and the participants grow. To participate in Ba means to get involved and transcend one’s own limited perspective.

In his blog (On “Ba” at a Scrum of Scrums) Dean Leffingwell builds on the original teachings and shows how Ba is essential to Agile software product development, as the energy that drives self-organizing teams. 

• Dynamic interaction of individuals and organization creates synthesis in the form of a self-organizing team.
• The fuel of Ba is its self-organizing nature - a shared context in which individuals can interact.
• Team members create new points of view and resolve contradictions through dialogue.
• New knowledge as a stream of meaning emerges.
• This emergent knowledge codifies into working software.
• Ba must be energized with its own intentions, vision, interest, or mission to be directed effectively.
• Leaders provide autonomy, creative chaos, redundancy, requisite variety, love, care, trust, and commitment.
• Creative chaos can be created by implementing demanding performance goals. The team is challenged to question every norm of development.
• Time pressures will drive extreme use of simultaneous engineering.
• Equal access to information at all levels is critical.

Now that we are more aware of it, what are the different options available to employees at all levels in their organization to help build and nurture Ba?

Concealing your weaknesses alone will not make you a winner

My young daughter is quite competitive by nature and when we first started playing chess she immediately focused all her attention on not losing, whether that was about individual pieces or the whole game. She quickly improved at that aspect of the game, but she was still miles away from actually winning her first game...

I am a big believer in open Ideation with my current and prospective customers so that

1. I can build a vibrant Ideation community, with more eyes, views and opinions shared (in the end I will still translate what I see and prioritize my release backlogs, but the value of any Ideation system is only truly unlocked when it is open and embracing vs.when it is tightly controlled)
2. I incur zero admin overhead for membership management (I am busy, and I don't want to stand in the way of my end users who are willing to donate their time to help me build a better solution for them)

I support responsible Ideation - anyone making changes to Ideas (voting, commenting, submitting new ideas) should be authenticated. This allows moderation of online community behavior and generally understanding the participants better, e.g. if we want to interview someone to clarify or better understand where they are coming from.

We are often naïve worrying too much about our "evil" competitors. Truth is they are too busy fighting their own demons.. and if we lose to them it's not because we are open and transparent but because they move faster and develop better solutions for our customers.

We should be worrying more about our ability to execute better and about improving our company's brand appeal. This will make more for growing our business than trying to conceal our deficiencies. Open user communities, Ideation and even the user documentation shared publicly can help turn around sometimes dated and unfavorable perceptions about the vendor. Trust is a critical foundation for turning around stale brand perception (i.e. what our customers think of us), and being more transparent and embracing with our customers, partners and our own employees will go a long way in this endeavor.