This article dances around some of the important stuff.
Maintaining engineering velocity is about adapting your culture to focus on the right things. At the beginning, engineering velocity is driven by low communication barriers and fast decision making and lack of existing tech debt. But this doesn't scale.
For engineering velocity at scale you need the following:
- Maintaining a high quality bar: You need to properly manage and prioritize tech debt and infrastructure complexity. This also means keeping dependencies low. The more engineers you have, the more code you're going to have. If this catches up with you, your velocity can be severely impacted.
- You need to have good change management: things like database migrations or big code changes should carry the least amount of risk possible. Documentation is important. You quickly get into hot water if you get stuck here.
- A culture of continuous improvement: teams should be data driven in measuring their performance and motivated to maintain and improve that performance over time. That means, for example, tracking sprint completions, bugs, etc. Each team needs to own this. The goal: ship high quality code faster.
- A close connection with the business and customers: When you focus on what the business needs and what the customer needs, it prioritizes things in such a way that your teams are dialed in to work on only what is needed. You can waste a lot of engineering time on things which don't matter.
- A culture of coaching and personal improvement: hiring good people is key, but ultimately it's how they play together as a team which is the most important. People need guidance on how they can be the most useful in that context. Sometimes people don't work out, so having fast feedback and showing people the door when they don't work out is necessary. Not doing this is a great way to demotivate other team members, at the very least.
- High amounts of ownership. This has sort of become a trendy topic in management philosophy, but ultimately it comes down to: can teams make autonomous decisions and own outcomes in the greatest way possible. This is all aimed at reducing decision making and communications overhead. It is also about making sure people with the greatest context can make decisions rather than somebody higher up with less context.
I'm sure I'm missing other stuff, but if you apply these principles things start aligning themselves in a direction where velocity is constantly improving.
However, I think talking about engineering velocity can sometimes miss the mark. What you really want is consistency.
Engineering lives within a broader organizational structure and other parts of the business need to be able to rely on you for certain things. When you can say: "Yes we can ship this feature by this date" and then hit that, you enable a lot of things. So yes, being fast is great. But you won't get there without being consistent.
Maintaining engineering velocity is about adapting your culture to focus on the right things. At the beginning, engineering velocity is driven by low communication barriers and fast decision making and lack of existing tech debt. But this doesn't scale.
For engineering velocity at scale you need the following:
- Maintaining a high quality bar: You need to properly manage and prioritize tech debt and infrastructure complexity. This also means keeping dependencies low. The more engineers you have, the more code you're going to have. If this catches up with you, your velocity can be severely impacted.
- You need to have good change management: things like database migrations or big code changes should carry the least amount of risk possible. Documentation is important. You quickly get into hot water if you get stuck here.
- A culture of continuous improvement: teams should be data driven in measuring their performance and motivated to maintain and improve that performance over time. That means, for example, tracking sprint completions, bugs, etc. Each team needs to own this. The goal: ship high quality code faster.
- A close connection with the business and customers: When you focus on what the business needs and what the customer needs, it prioritizes things in such a way that your teams are dialed in to work on only what is needed. You can waste a lot of engineering time on things which don't matter.
- A culture of coaching and personal improvement: hiring good people is key, but ultimately it's how they play together as a team which is the most important. People need guidance on how they can be the most useful in that context. Sometimes people don't work out, so having fast feedback and showing people the door when they don't work out is necessary. Not doing this is a great way to demotivate other team members, at the very least.
- High amounts of ownership. This has sort of become a trendy topic in management philosophy, but ultimately it comes down to: can teams make autonomous decisions and own outcomes in the greatest way possible. This is all aimed at reducing decision making and communications overhead. It is also about making sure people with the greatest context can make decisions rather than somebody higher up with less context.
I'm sure I'm missing other stuff, but if you apply these principles things start aligning themselves in a direction where velocity is constantly improving.
However, I think talking about engineering velocity can sometimes miss the mark. What you really want is consistency.
Engineering lives within a broader organizational structure and other parts of the business need to be able to rely on you for certain things. When you can say: "Yes we can ship this feature by this date" and then hit that, you enable a lot of things. So yes, being fast is great. But you won't get there without being consistent.