Engineering teams: what and how

I’ve recently been traveling and speaking with engineering teams in different organizations. These organizations are some of the top technology companies in the world with relatively mature development processes.

Occasionally I’ll run across teams full of smart people and regardless of the company they’re a part of, they’ve forgotten some fundamentals. In my experience, if you have the fundamentals, just like with most things in life, the details will get sorted.

In this instance, I’m not talking about the technical details of architecture, testing, etc. I’m talking about team dynamics and the ability to get things done.

Team-based software engineering (the only way to build products, not just projects) is made up of two main areas:
  1. What you build
  2. How you build it
I’ve seen teams be so consumed with one that they forget the other — in either case they don’t succeed.

How you build it is as important as what you build

The most common case is teams become so busy focused on what they’re building that they forget to evaluate how they’re building it. They believe they’re under so much pressure that if they focus on anything other than the final goal, they will fail.

Healthy teams take time regularly to evaluate what’s working, what isn’t, and determine what they need to do differently in light of circumstances. If current high-performing teams stop doing this they will cease to be high-performing. The reality is that software, projects, people, technology, and dynamics all change. Which means to stay healthy, your team has to change how they do things too. 

I’m not talking hours of self-reflective bike-shedding. I’m talking about regular, honest retrospectives followed by change, followed by re-evaluation. It’s as simple as that. It’s better to change, be wrong, and change again, than to never change. There’s tremendous value in knowing what works and what doesn’t.

If you don’t take the time to do this, you’ll have even less time to focus on what you’re building because you will lose velocity. You don’t have time not to improve.

Teams that don’t improve, automatically get worse

Organizations, this also means if you want healthy engineering teams you have to stop prescribing how everything works down to the minutia. Some consistency in transparency, tool set, and delivery is critical but you have to let teams internally organize and define their own internal process.
Some symptoms to watch out for are:
  • Engineers not knowing what to do next
  • Engineers regularly blocked and unable to do what’s next
  • Teams that always miss their own estimated timelines
  • Widely disproportionate contributions by members of the team (it will always vary to a degree)
The last thing I’ll say on this is don’t put boundaries on teams’ retrospectives. You’ll often have teams highlight issues outside of their own team — maybe with a product owner, product management, design, or even you. There’s no middle ground with honesty. They’re either completely honest with themselves and others about what’s working or they’re not.

The flip side

Although less common, I’ve also seen teams so focused on how they do what they do that they make themselves incapable of delivering. This generally happens when the engineering manager or lead of the team turns everything into a democratic exercise. I encourage team ownership because that leads to healthy dynamics. If it goes too far then the end result is that everything is a discussion with no one taking final responsibility. Encourage your team leads or engineering managers to be both strong leaders and facilitate team ownership. Not everyone understands how to effectively do both but when you have it, those teams can handle anything.

A healthy team that continuously improves is resilient. They handle chaos, mundane work, difficult problems, and tight deadlines all-the-while growing through the process. That’s what you want.


Popular posts from this blog

Scaling distributed teams