High performing software engineering teams are motivated, have ownership over their objectives and goals, and they autonomously make important decisions within the scope of their work.
It’s widely known that measuring engineering performance is a highly needed but also a highly controversial topic. The DORA metrics framework has become a widely popular one to address this issue. The framework states there are 4 key metrics that indicate the performance of a software engineering team.
Deployment Frequency: How frequently the team deploys to production
Lead Time for Changes: The amount of time a PR or commit takes to get to production
Change Failure Rate: The percentage of deployments that are breaking production
Time to Restore Service: How long it takes to recover from a failure in production
DORA metrics come from the company DORA, created by Gene Kim and Jez Humble along with Dr. Nicole Forsgren, who are also co-authors of the bestselling “DevOps Handbook.”
The first 2 DORA metrics measure velocity, and the final 2 measure stability.
McKinsey recently published a study where they claim they invented a master framework for measuring developer productivity. It’s a win for the software development ecosystem that a traditional company is thinking about this problem.
However, it doesn’t work that way. Velocity is funny because it’s a conformist way of measuring productivity. It’s always easy to go for the dirty and noisy metric. Velocity is actually more akin to measuring capacity than performance.
Individual contributors should understand that although DORA metrics is a quantitative framework, the feedback they get about it should be qualitative, and the actionable should be something qualitative as well. Dear IC: If your manager is solely measuring your output with DORA metrics or other misguiding indicators such as story points, number of commits, or PRs closed; we invite you to question yourself why that’s happening. Hint: It probably means the company has a technically weak management team and you should quit. Not career advice.
Recall that earlier in this blog post we mentioned that high performing software engineering teams have ownership over their goals and have a high level of autonomy. How autonomous should you be as an individual contributor?
The 1974 HBR classic: Who’s Got the Monkey? Talks about how managers also work for their subordinates, how they become the bottleneck if they don’t address those “monkeys” (analogy for pending tasks), and how good managers care more about providing the correct tools for her team to work rather than supervision (micro-management).
In the scope of discussing DORA metrics “passing the monkey around” looks like this: The manager identifies there’s a bottleneck in the organization’s DORA metrics due to the team’s velocity. The manager has a 1-1 conversation with the individual contributor she thinks is contributing the most to this bottleneck. “Hey, I see you’ve got our velocity down. Let me start this meeting by asking, what can I do to help you increase velocity?” Then the IC is thinking inside her mind “I just wish you could let me have a maker schedule so I can ship this thing, instead of booking useless meetings”, but probably goes with something synonym that sounds more gentle. Then the manager has the monkey, invests time in non-sense tasks over others that should have a higher priority, and later finds out the IC simply needed more focus time.
(This is also why managers with a technical vocation and who manage their team asynchronously are more successful than those without technical chops and who manage synchronously. But that’s a topic for another blog post).
If you have a very competent manager, you don’t have this problem. If you have a manager that prioritizes supervision over providing the correct tools and velocity is the current DORA metrics bottleneck, you should have an open and honest discussion with your boss. “Dear manager, to be able to address this velocity bottleneck we have, I need more individual focus time to shoot this monkey that consists of X, Y, and Z”.
The more autonomous your manager allows you to be, the higher the chances you’ll solve the DORA metrics bottleneck your company has. Whether that’s around velocity or stability. Steve Jobs said: “It doesn't make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.”
Different teams have different bottlenecks in their DORA metrics. Velocity is the most common bottleneck. Companies that suffer from stability as a DORA bottleneck are of a special kind.
Whatever your case as an individual contributor is, think systemically to solve the DORA metrics bottleneck your employers have. The more you are aware about DORA metrics, the better you’ll be able to guide that conversation with your manager.
Product development is an uncertain discipline. You can spend 1 week, 1 month, or 1 year developing a feature and you won’t know if it will be successful or not until it’s released.
As an individual contributor you need to understand that you are shipping to learn. To ship and measure what sticks with users and what doesn’t. Therefore, you should be shipping as fast as you can, without nitpicking unnecessary details. As the product gets more product-market-fit, the organization will be in the position to increase engineering capacity.
The best teams will solve the velocity bottleneck by creating the development environment that’s best for engineers to thrive.
- Use framework-defined infrastructure over custom infrastructure scripts. It makes deploying something trivial
- Make each change a more granular and a self-sufficient task