 |
Recently, someone at work asked me to weigh in on my experience with Developer Productivity and Velocity. I love this topic so much. There are a ton of different areas to explore. It’s a delightful topic to dig into with a team that is currently “underperforming,” according to them or someone else in their org.
I’m going to avoid evident and boring things like “make sure you meet the Joel test,” “provide good requirements,” and “empower your engineering team to make their own decisions.” Those are table stakes.
The study of Permaculture has a design principle called the Edge Effect. In short, there is a greater diversity of life in a region where two adjacent ecosystems overlap. I think the same is valid with engineering teams and the rest of the organization.
I’ve been fortunate in my career to have the opportunity to lead at different levels of scale, from individual teams, to technical account leadership organizing cross-functional teams, to engineering departments. Across such a span of scale, I have found that engineering team velocity is often directly related to the engineering team’s proximity to the “edge” of another department and the interplay between the two. This effect is not just “collaboration” or “synergy” (🤮) between engineering teams and the rest of the org. It’s another beast that gets into the differences between stress and pressure.
For the most significant sustainable velocity, an engineering team must be close enough to feel the pressure of a deliverable but shielded from the stress of the deliverable by their leadership. This pressure must come from outside the engineering team. That’s the edge or boundary.
A team that trends too far in either direction results in a steep drop in velocity and productivity.
On the one hand, you have the overly-sheltered engineering team. This team has the full support of their leadership to take “as long as it takes” to get something done “right.” In this scenario, velocity drops because the engineering team has enough proverbial weight within the organization to take whatever time they need.
There is no pressure to deliver, so they focus on building an incredible product but deliver too late for peak customer value or product team learnings. They shipped the whole thing at once, tested, and “perfect.” So what if they ended up building the wrong thing? They’re fully back to the drawing board again, rather than being able to iterate quickly.
That usually doesn’t last long, though. After a few cycles of that, I’ve found the engineering leadership starts to take two steps back from protecting the team – often in self-preservation. They do that, or someone else in the org actively removes them from the position.
On the other hand, you have the embedded or under-sheltered engineering team. This team is subject to the whims of every idea that some salesperson, executive, or marketer has. They’re thrashed about back and forth without any protection. Productivity is terrible because the team delivered five things, but the requestor forgot about four of them by the time they left the room. These teams suffer from a different kind of culture hit – burnout, walkouts, high turnover, etc., which drive down productivity further.
The sweet spot is in the middle. External solid forces drive delivery, with strong engineering management that shields and converts that external stress into delivery pressure for the engineering teams that report through them.