Optimizing Development and Engineering Performance

Low development performance is one of the most common—and most painful—problems I see in engineering organizations. Features take too long, bugs pile up, and the business gets frustrated. As CTOs and engineering leaders, we’re under constant pressure from CEOs and stakeholders to deliver faster, ship more, and do it all with fewer resources. The demand for higher performance never stops, but the path to real improvement is rarely obvious. Let’s talk about why low performance happens, why it’s such a critical issue, and how you can start turning things around.

My Story

As a CTO and engineering manager I have been pressure for development performance for decades. There was allways the expectation to go faster. There was always the expectation that company success was hold back because development was ’too slow'.

I see CTOs struggle with development performance, mostly because the factors are complex and development feelas like a water baloon. You squeeze it here and it bulges there.

The Four Step Framework

I poured all my experience into a way to optimize development and engineering performance. My framework for optimizing development and engineering performance has four steps:

1. Effectiveness Level
2. State of Code
3. Motivation
4. Measure & Optimize

First thing, set the effeciveness level of the features you develop. Steve Jobs was famous on iterating over features until they were perfect. If you do not fix effectiveness level of your features, there is no way to optimize performance. For a great feature, you might need to iterate five sprints. For a version of the feature that no one likes or is using, you can do it in one sprint. In that case, development performance is 5x higher!

• Get effectiveness/ impact of features/products to desired level
• Measure effectiveness/impact
• Keep effectiveness at level while optimizing performance or increase impact

Next, rate the level of code. Two teams develop a similar feature, one takes 2 sprints, the other takes 8 sprints. The second is a bad team that slacks off? No, the first team has a greenfield project with nice code, high test coverage and a low number of integrations, while the second team has a code base that is five years old, dozens of people have worked on, has many different framework and library dependencies to maintain and dozens of integrations into other systems. Without understanding the state of code, you can’t understand the performance of teams

• Measure state of code to A,B,C,D,E,F levels
• Code quality, code age, technical debt
• Tech complexity
• Dependencies
• Keep state of code at level or get better while optimizing

Managers act as development performance does not depend on people. The biggest impact on output is developer motivation. Every team and every member is different. Without understanding motivation, you can’t understand the performance of teams

• Developer motivation has big impact on performance
• Understand motivation
• Fix frustrations Give ownership

Now, you can start optimize performance. Measure output (e.g. $$$ revenue add / developer day) and optimize from there. Give ownership to the team for optimal performance, and treat a team like a team

• Developer motivation has big impact on performance
• Understand motivation
• Fix frustrations
• Give ownership