Since the introduction of DORA metrics, engineering organizations have come a long way in understanding the value of data and professionalizing their work. However, engineering leaders still need to make the best decisions for their business and teams according to their context. Yes, there are industry benchmarks, but they don't cover your organization's unique context. And this makes all the difference, especially when you are scaling.
Today we will explore why context is critical when making decisions in growing organizations, even when you have metrics at your disposal. We will also look through the lens of three examples to help you on your journey.
What is Context?
Context is the frame of the organization, the set of unique circumstances that influence a business. For engineering leaders, your context is a combination of team structure knowledge, product knowledge and business goals knowledge.
Why does context matter?
If we think about DORA metrics, for a team to be considered an Elite Team, they must deploy multiple times a day. But what if you have a mobile team? They can't deploy several times a day because of app store limitations. Does it mean they are low performers?
If engineering leaders don't consider this context, they might push their team to be a "DORA high-performer" when the circumstances do not allow them to. This situation is far from being related to the team's capabilities. They will not get there and get frustrated with the demands. Or worse, you might ignore data and metrics that matter in their context.
Let's look at more consequences of not taking context into account when analyzing engineering metrics by looking at three practical examples.
Context I: The (normal) pain of growing
👉 Indicator: PR Cycle Time has increased in the last month.
💭 Without context: As an engineering leader, if your PR Cycle Time increases, you will agonize over it because it means you are slowing down.
💡 With context: Since the organization is growing, you are onboarding more engineers, meaning they're still adapting to the workflows and the product itself. They need time to ramp and feel comfortable on the codebase and stack.
🚀 Actions: Review the data in a month. Your PR cycle time should go back to normal if onboarding went well.
Context II: The grass is not (always) greener on the other side
👉 Indicator: Your Review Time is 2hrs higher than some “industry benchmarks.”
💭 Without context: You might think your organization is underperforming.
💡 With context: Your team is mostly made up of junior engineers, so your senior engineers are investing a lot of their time in code reviews to train the junior devs properly.
🚀 Actions: Understand the Review Time that works best for your team. There are plenty of reasons a longer code review process could benefit your context.
Top comments (0)