EngProd: The Secret of Elite Developer Teams

For companies to be successful, it is important to be able to get new ideas in front of users quickly, so you can keep up with the market and iterate based on real-world feedback. When technology teams find themselves unable to keep up with the pace of product development, they become the blockers of an organization.

Ineffective technology leaders will pressure their developers to ship ever more work, causing developer burnout and software instability. By contrast, effective technology leaders will address the systematic process problems to allow their developers to provide the most business value with the least amount of pain.

In high-performing technology organizations, EngProd (Engineering Productivity) works alongside other engineers to identify and remove bottlenecks. The team names vary from organization to organization; whilst Google has EngProd, Netflix has Developer Productivity (DevProd).

The end result is the ability to iterate quickly on changing customer requirements, whilst delivering reliable software and maintaining happy developer teams.

The Power of Cycle Time

👁 Image
Identifying constraints in a process is such a valuable skill, that Jeff Bezos makes all senior managers at Amazon read a book about Theory of Constraints called “The Goal.”

For a software development team, this begins by looking at the end-to-end Software Development Life Cycle (SDLC). This is measured using a metric known as Cycle Time.

Cycle Time is simply the time it takes from a developer to start working on a product feature to it being deployed in production.

Once we understand Cycle Time for a given project, we can drill into problematic areas that make up Cycle Time to identify the bottlenecks (like Development Time, Build Time, Initial Code Review Time, Rework Time, Idle Completion Time, etc). Often you have to drill a few layers deep to identify the bottleneck and to work out how to resolve it.

Notice how we start by measuring the global picture before measuring local process. Optimizing local processes prematurely can cause us to work on something that won’t actually help the overall Cycle Time.

Shortening Cycle Time allows developers to deliver more business value, reduce Work in Progress and minimize risk from big-bang deployments.

Measure Process, Not People

I recently ran a study that found that 83% of developers are suffering from burnout. The top reasons cited for burnout included high workloads (47%), inefficient processes (31%), and unclear goals and targets (29%).

Optimizing for Cycle Time helps remove inefficient processes whilst quick iterations with customer feedback provide clarity of work. Removing chores through automation and shipping small can also cut Cycle Times by reducing workloads.

That said; treating Cycle Time as a people problem can be deeply damaging. If you attempt to resolve a bottleneck by simply making your teamwork harder at it, whilst neglecting the root cause of such problems, your team will simply burn out and quality will suffer.

Multiple research studies have found that psychological safety is foundational to elite engineering performance. Using metrics to attack engineers, whilst not driving improvements to process, will simply result in a toxic work environment.

Identify bottlenecks and then use tooling, process and management experiments to attempt to alleviate those constraints.

Engineering Management Remains Critical

Optimizing the engineering process cannot be treated as purely a search problem. Professional judgment remains integral.

For example; suppose during the build step of a software project that there is a critical test that takes a few minutes to run. If the risk were ever to materialize to failure, human life would be cost.

 Psychological safety is foundational to elite engineering performance. Using metrics to attack engineers, whilst not driving improvements to process, will simply result in a toxic work environment.

From such a serious risk, you would never want to materialize the damage in order to test its impact. An engineer’s professional judgment would find that, on the balance of risk and reward, the extra few minutes of Cycle Time are worth the mitigation of a risk. Professional judgment would let you apply engineering solutions to both mitigate the risk whilst ensuring fast builds.

Nevertheless, visibility into software quality metrics (like full resolution time of customer-reported bugs) remain a vital tool in helping keep an eye on quality. The same applies when it comes to ensuring engineer wellbeing.

This brings us to the fundamental dogma of engineering metrics; metrics will tell you where to improve your process, but ingenuity and creativity will let you make those changes.

Sooner, Safer, Happier

EngProd adopts a Theory-of-Constraints approach to identifying where the bottlenecks exist for an engineering team and alleviating them.

The end result is that engineering teams can deliver business value sooner and react to changes in the market faster. Doing so delivers more reliable software and drives engineer wellbeing.

To achieve this, it’s vital to adopt a data-driven approach to identify the bottlenecks in an engineering organization. This will allow you to address the process weaknesses systematically.

Effective EngProd teams do this by preserving the integral role of psychological safety in the workplace and ensuring that professional engineering judgment remains at the heart of technology leadership.

At Haystack Analytics, we’ve seen that teams which adopt this approach have been able to ship over 70% faster on average.