Given that it’s my mission to help companies create world-class engineering teams, I often get questions along the lines of, “how does a world-class team behave?” In my mind, that’s a trivial question. The fascinating question, though, is to think about how you would tell that your team is on track to become remarkable.
Teams that have successfully kickstarted their professionalism snowball often excel at candor and craftsmanship. Candor means that the team is formulating coherent and honest feedback. Craftsmanship is not about already being a master of your craft, but about the team having the innate drive to become better at it.
Candor and Craftsmanship
To help make this clear, I will start with the consultant’s favorite tool: the double-axis chart:
Despair: I don’t think this requires a lot of explanation. If the team lacks the openness to give great feedback, and the people on it do not have the drive to improve their craftsmanship—you, as the tech executive, have a lot of work to do, and something very wrong has transpired in the past. Get help.
Cynic Fencing: Candor without the internal drive to become better manifests in a bunch of people telling each other why the other person’s ideas are stupid and why project X is doomed to fail. Imagine a workshop about destructive criticism turned into a profession. It’s a bit like having Dinesh and Gilfoyle from Silicon Valley as your teammates.
Tech Fest: Teams that focus on getting better in their craft without the right feedback to direct their learning often get lost in the different aspects of the tech world. There’s nothing wrong with loving the craft and learning about it. However, when it gets out of whack and an imbalance occurs, the entire team might get stuck in a cycle that does not provide any business improvement, just a bunch of busywork. See the Tech-Product motivation continuum I wrote about here.
Improvement Loop: The sweet spot. This situation is where the team starts helping each other grow and improve.
Life On-Track
I find that my clients often benefit from concrete examples. To help you realize whether your team is doing good, and to visualize the steps you should take to adjust, here are everyday things that happen when the team is in the improvement loop:
Pride in finding issues and giving feedback: The best teams are those where people are open with one another and do not take feedback as a personal blow. I love seeing groups with lively discussions on pull requests with excellent and concise discussions about different approaches to doing things, asking to find a better name for something, and so forth. This might seem trivial, but it acts as an excellent basis to foster more honesty and open and safe culture. It is imperative to make sure that this sort of feedback is welcome from everyone, i.e., not just from the seniors to the juniors.
Teamwork as default: Tasks are not automatically split between people to go off and work alone. The best teams find good opportunities to work together. This is harder nowadays, with the need to find good setups for working together remotely. Still, I do believe that it has a significant impact on creating the relationships and trust that are needed to provide excellent feedback and foster candor.
Help is not a chore: As part of valuing teamwork, in these teams, even seniors do not see the need to help someone else as a burden. It is one of the ways everyone performs as engineering force multipliers and increases their own leverage in the team.
Asking for help is not scary: The other side of the same coin. Once providing help is seen as a positive thing, people are more likely to ask for help when they need to. This means that failure work is reduced, and learning happens faster. Even if it just means sharing new shortcuts in your IDE, these add up.
Quality is personal: The drive for better craftsmanship manifests in a team that takes pride in low quality issues. Finding bugs in a pull request is great. When something slips, the team thinks together about where they need to improve. A bug shouldn’t require an hour long outage to be worth a quick retrospective. If you don’t learn from your mistakes, you learn to make mistakes.
Learning together: The best teams regularly read, learn, and share knowledge. It doesn’t mean this is their entire calendar, but a habit of regularly sharing interesting posts and discussing them, or an internal book club can go a long way.
Coders without borders: Not putting up barriers between engineers and other engineers, or engineering and other departments. They ditch the “it’s not my problem” mentality and roll up their sleeves whenever there’s an issue that they can help with.
Results driven meetings: When there’s enough candor, meetings stop taking longer than they should. People feel free to say when they don’t think they should attend a meeting, and I found that shorter meetings and sharper agendas happen almost automatically once the team’s senses are primed to spot time wastes.
Retrospectives are fun: If you’re giddy with the idea of learning how you could be doing better and improving, retrospectives become the highlights of sprints. There’s no pointing fingers, but a focus on debugging process issues together and committing to becoming better.
How many of these do you feel like you’ve got nailed down? Would love to hear your stories, so tweet at me or email me (address at the bottom of this page).