The best team I've managed
I recently saw an interesting question on a job application:
Describe the “best” engineer I’d ever managed.
I like this question because it’s different from the usual application questions. But I knew I’d never get to interview because I disagree with the premise of the question! I wrote back anyway 😄 Here’s my take on “the best engineer”.
There can be no “best” engineer because engineers don’t exist on a single continuum. There is no one definition of what a “good engineer” looks like without taking into account variations in preference, strengths, talent, thinking, soft skills etc. This focus on the individual contradicts systems thinking, which describes how a system is defined more by its interconnectedness and the outcomes that emerge from the interaction of its parts. The slogan I often use here is: “work goes to teams, not individuals”. Thus I believe it’s more valuable to talk about the “best team” rather than the “best individual”. A team can accomplish far more than a single, even brilliant, person. (Though we’ve all seen brilliant individuals accomplish great things and rooms full of people deliver nothing of consequence).
what is the best team I’ve managed?
The most high performing team I managed didn’t need me; that I wasn’t on the critical path for their success. Responsibility-wise they were a DevOps team in charge of security and they demonstrated many characteristics of a high-performing team.
They were heterogeneous, with a range of experience from their accomplished lead to the junior career-switcher. They were consciously inclusive of discipline: they didn’t see “their team” as just the engineers, but included their product manager, peers, stakeholders and users as key participants in delivery.
They prioritised security without fear or favour. Everyone at every level in the team was empowered to address issues. My favourite example was the junior engineer boldly calling up the CEO to deal with a security issue we needed him to action immediately—There was no deference to hierarchy or authority, because the need for action was clear to them, and they supported each other.
Pairing and mentoring were a natural part of their work and didn’t need to be planned or enforced.
They socialised naturally even though they were remote-first.
They were humble and communicated how their work directly connected to the success of the business.
They were ruthless prioritisers.
They delivered consistently.
High performing teams are rare, but this team had many of the hallmarks.
I can’t end there without critiquing my own thesis with a call back to systems thinking: even this team only succeeded as a part of a greater whole. Their success didn’t exist in a vacuum, and this collection of talent might have failed in a different company.
Maybe the interesting question is, “how did they become high performing?”
