How to develop a high-performance team – Part 2
Part 2 of “How to develop a high-performance team. Part one can be found here.
The sum is greater than the parts
Most every manager know about 10x developers. These are your rockstars that seem to know everything about your organization’s technology. You know the guy… he’s the first person that’s called when there is an emergency. These guys are hard to find and are expensive – and most organizations believe they are completely indispensable. But are rockstars types the ones you want on your high-performance team? Not necessarily.
What you should be focusing on instead is building a 10x team. You want your team to be comprised of individuals with strengths that complement the other members of the team. Before continuing, read this great post by Avichal Garg explaining 10x teams in detail.
Now consider your rockstar again. How would they fit on a 10x team? Can they be the tech lead? Are they able to teach and share knowledge? Having the wrong type of rockstar can be detrimental to your team. Here are the characteristics of a detrimental rockstar:
- Believes he/she is always right - this person does not listen to other’s ideas and will stamp them out with a condescending attitude. Perhaps they get away with it because they are usually right. Over time, other team members are too afraid to provide ideas and your team fails to develop stronger contributors in the future.
- Territorial - your rockstar developer work son the most critical parts of the code. Because of his/her expertise in those areas, no one else has any knowledge about how it works. And the rockstar prefers it that way. The consequence is that the rockstar often becomes the bottleneck on every project and your team never becomes well-rounded.
- Lone-wolf – this is the guy that just wants a task spelled out for him and be left alone. He thinks Agile is just a buzzword and he can’t be bothered with it. He thinks discussing backlog items and estimating them as a team is a waste of time. Worst, this attitude can hang in your scrum meetings like a dark cloud – negatively affecting the rest of your team.
- Perception that he/she is too valuable to be removed - this perception comes from the company as well as the individual. This belief compounds all of the problems above because the individual has less incentive to change behaviors.
I’m not saying that people with these characteristics are not valuable – in fact without these rockstars, most startups would never have gotten off the ground in the first place. But once that startup has reached that inflection point where production is measured by the output of teams instead of individuals, then a change in behavior must be coached – or as a last resort, the detrimental rockstar must be removed from your team.
Get a sheet of paper and list in a column the seven attributes that Avichal has listed: Technical Ability, Charisma, Grit, Teaching Ability, Hustle, Honesty, and Work Ethic. Create a column for each of your team members. For each team member, score them on each attribute on a scale of 1-10. Then add the scores across. Which attribute is your team weak in? Keep this in mind when hiring or restructuring teams.
One of the biggest things you can do for your team is have them sit near each other. And I’m not just talking about developers sitting together. I’m mean everyone on the team. Many organizations have an separate areas for developers, QA, devops, and project managers. Where is the logic in that? Can the QA department ship a product for the company on its own? Can project mangers ship a product on their own? The answer is no. Only teams that include members from each functional area can create and complete a shippable product. So the logical thing would be to get your scrum team to sit together. You’ll begin to see immediate benefits due to reduced communications overhead.
Secondly, teams with offshore members will just never be as efficient. Given the choice, I would take one developer in the building over three developers overseas. Its has nothing to do with skills, but everything to do with hidden costs. It is up to you to do the cost-benefit analysis for your team, however, consider these hidden costs:
- Management overhead
- Communication overhead – sprint planning, stand ups, reviews and retrospectives become difficult with time zone differences, more risk on miscommunication of requirements
- Less efficient and collaborative team meetings
- Lengthened feedback loops – especially if your QA is outsourced, developers questions not answered until the next day resulting in idleness or rework
- Non-optimal team dynamics
The small delays that occur everyday add up and compounds over the course of a project. It represents a tremendous cost. As I mentioned, all these characteristics work as part of an integral whole, so consider the impact that remote resources will have on the other characteristics as well. This loss in potential is harder to quantify, but do not weigh it lightly.
Ownership of quality
There is a theory that more crimes occur in neighborhoods that have a lot of broken windows. This is because the low standard of upkeep by the neighborhood has been accepted as the norm by residents and passerby’s. If you’ve ever bought a brand new car, you know the feeling of dreading that first scratch. You’ll park it carefully and avoid potholes while driving. But once you get that first ding… you start to take less and less care with your car.
The same can be said for software. In the book, Essential Scrum by Kenneth Rubin, he applies the term technical debt to the “broken windows” in software. By allowing existing workarounds, hacks, and “acceptable bugs” to exist, you will find that future development will lead to more of the same. It is called technical debt because these bugs must be fixed one day. The debt continually compounds and problems they cause become exponentially worse. Because of this, technical debt must be stamped out with extreme prejudice. To start paying your technical debt:
- Run an audit of existing technical debt and make them highly visible.
- Create an Epic of technical debt backlog items and add a few of them to every sprint.
- It is important that your team sees technical debt being burned down.
- This will help unfreeze old norms and introduce quality as the new norm.
In order to prevent technical debt in the future, the best teams fix bugs immediately. They fix deployment issues immediately. If a team member breaks an environment with some code they’ve committed, the entire team stops and fixes the issue. The commit is rolled back if necessary. Bugs that roll over from sprint to sprint are immensely costly, as they essentially amount to double-work. There is also the opportunity cost of not being able to work on the next prioritized backlog item.
If your developers aren’t doing so already – writing the automated tests for their code needs to be a part of the acceptance criteria for a completed user story. Any time you can take human error out of the equation, it is worthwhile to do so. I recommend reading Continuous Delivery by Jez Humble for in-depth strategies on how to give your developers short feedback loops so they are able to fix bugs immediately.
You’ve set a clear vision and your team has bought in. You’ve defined the metrics for success and your team has met them. Make sure your team feels appreciated. I would argue that it is your responsibility to provide visibility for your team. You have the 360 degree view of your team’s impact internally, externally, and across all functional disciplines. Celebrating as a team is important because it builds camaraderie, re-enforces internal rewards via acknowledgement, and sets the expectation of continued success in the future. Here are simple ways to celebrate success:
- Forward kudos from stakeholders to your entire team
- Bring in stakeholders to sprint reviews to thank the team personally
- Share the success metrics that were defined and how they were met
- Explain to your team the business value and impact of their work
As you can see, I’m not talking about extravagant parties or tossing the team the carrot on the stick. Its anything that contributes to a sense of purpose fulfilled and acknowledgement of mastery. Remember, internal motivators are much more powerful than external motivators.
“When will it be done?” is probably the most headache-inducing question that you face as a product manager. It is deflating to strategize and construct roadmaps only to miss time and time again. Why is it so hard to pin down? Like motivation, predictability is an emergent characteristic. You must have “self-contained”, “self-improving”, and “ownership of quality” characteristics. Self-contained is important because it minimizes dependencies and handoffs between groups. Self-improving because a team must have this characteristic to eventually reach a state where they are able to accurately commit to and execute on sprint goals. They must display ownership of quality because rework is a major source of delays. All the other characteristics contribute to your team’s predictably as well.
Did you think a product manager’s most dreaded adversary would have an easy fix? It shouldn’t be a surprise that your team must display just about all the characteristics listed in order to achieve predictability. It is indeed a great challenge. Take it as your responsibility to help cultivate these characteristics with your team as a servant leader, and you will be rewarded with fulfilling professional relationships and most importantly, happy customers.