Real-world challenges and solutions for building high-performance teams

The beauty of QCon’s open-space format is that it gives you a chance to hear about other people’s challenges and how other experienced folks respond to that. And that’s not all. It really helps to hear that everybody is struggling with the same issues. I attended two of these this year, one on JavaScript (yes, really) and one on building high-performance teams.

I joined three individual discussions and started with one to getting some advice on how to deal with senior engineers that are not as senior as they think. After some clarifying questions, it appeared the proposal referred mostly to the maturity of that engineer. So even though this engineer was technically very skilled, he missed the experience to understand that every tool, technique and principle has pros, cons and a context in which it is supposed to work. He often sided on dogma in adopting or rejecting something.

Some suggested to solve the problem at the root by measuring seniority from different angles. Examples of such angles included communication skills, being able to grasp the business goals, experience with coaching developers, understand what it takes to make code maintainable, but also political awareness. Another, more reactive, suggestion was to have technical discussions in a group instead of in one-to-one meetings. You could even use quality attributes to steer such a discussion in the right direction. This may also help surface or suppress certain limiting thoughts or opinions. But some even suggested to embrace the learning aspect by allowing this engineer to fail in a safe environment. All made total sense to me.

Kind of related to this topic was the desire to break down silos. I’ve experienced this issue first-hand and was happy to see I was not the only one. Several suggestions were offered by the group. A financial incentive for working together, possibly with a common mission or goal, might work well. Whether this is going to be costly or worth the money wasn’t clear, since nobody tried it. From a tool perspective, making sure you remove any barriers for communication between tools got a lot of support as well. Somebody even suggested a dedicated team that just builds tools to support the collaboration of other teams.

A more radical suggestion was to start moving people around or even completely rebuild the teams using Myers-Briggs Type Indicators. If that’s too permanent for you, someone suggested to have so-called visiting engineers, people that move between teams for a couple of days to cross-pollinate. Using Guilds or focus groups to unify like-minded people was suggested as well, but I particularly liked the brown bag meetings. Those leverage the natural curiosity of people and may help people empathy for other people’s challenges.

Because mentoring was mentioned a couple of times, a discussion started on what makes a great mentor. A lot of that was kind of an open door, but the folks standing around that topic thought that a good mentor will give room for failure and autonomy. In other words, give the person being mentored the chance to experiment and promote them taking ownership. The mentor should also give honest feedback and not sugarcoat anything. Next to that, we all agreed that a mentor does not have to be a manager or somebody with a higher position. Just lead by example and be empathic.

The entire block concluded with a final group discussion on what makes a great team. We all agreed that a shared goal or vision is crucial. Consequently the team should be rewarded and not the individuals. But having a sense of community can help as well. Great teams help other teams and are open to feedback. And they don’t have to be equal to be able to collaborate efficiently.

Sounds obvious right? So what do you think? I would love to hear your thoughts by commenting below. Oh, and follow me at @ddoomen to get regular updates on my everlasting quest for suggestions and ideas to become a better professional.