New thought paper: Make overcoming transformation fatigue your unfair competitive advantage – Download now

Developer Surround Ratio – How efficient is your IT department?

Emergn - Developer surround ratio - code on a screen
Written by
Emergn
Engineering Flow Ways of Working

The final result of a software development department is working code, code that we hope will be valuable (effective). A number of years ago, Pearson invented a simple test for the efficiency of a software development department or project. The test is far from perfect and there is no perfect score. Additionally, it may not be worth us improving efficiency if it costs us in effectiveness. But the results we have seen, time and time again at Emergn in differing companies, highlights a major problem that development is usually far too expensive.

Developer Surround Ratio

Working code is typically produced by the developers.

So for every one hour of code development (the actual output), how many hours of support work do we have (for example, analysis, testing (we typically exclude developer testing), management (both project and executives who love not to be counted), administration, design, architecture etc). All things being equal (effectiveness not changing), it would be preferable to have nobody supporting them (usually a unrealistic proposition). However, we have found the ratios for support are way too high, whilst at the same time, developers are often the constrained resource leading to departments employing roles like management to basically say no (in a polite way of course). Instead departments should be examining these surround costs and eliminating them where it makes sense.

What Does It Look Like in The Real World

Pearson had on a typical project six (6) hours of support for every developer hour (1) at one site. If you don’t have timesheets, just do a rough calculation. Now you might initially think this number looks crazy, but we have discovered at Emergn, that 6 : 1 is not an outlier and is actually quite a common ratio. Large companies have large ratios, but don’t have visibility that shows this problem.

Let’s put that into perspective. For every developer desk you have, you need 6 people working with him to do his job, six people watching his monitor as he codes, essentially telling him what to develop. Now of course this doesn’t happen, instead we have tons of waiting time in a typical project (queues) that actually hides this problem.

The ratio was switched from a total average of 3.8 to 1.8 (this is alongside improvements made in the department over a two year period leading to the company winning UK Agile Team of the Year). So they were both more effective and more efficient. They were able to cut department budgets, fund an agile transformation and complete more projects in a single year than ever. One of our leading projects had a ratio of 0.6 : 1.

Now get this, typically the average wage of the surround is also higher than the developer cost. In Pearson it was around 25% higher. So the average cost per hour of development went from £186 an hour to just £91 an hour with no negative (in fact positive) impact on effectiveness. A significantly better result than the usual choice of offshoring which typically drives up surround ratios, hiding the true cost of development by only looking at the developers cost per hour. The 0.6 project, was running at a cost of £52 per hour.

A Word of Warning

Improving the developer surround ratio is something that the vast majority of companies should be doing. We have found that this can only really be done in an evolutionary way (due to HR constraints and the need to not see effectiveness impacted). Alongside an Agile transformation, this makes perfect sense. We have found that a 1 : 1 ratio is usually a good point to initially achieve (of course, reiterating, there is no perfect score).

Let’s be clear, effectiveness is almost always more important. By itself, developer surround ratio can make you focus on the wrong thing. However as part of an overall change of improving effectiveness and efficiency, the developer surround ratio can be used to manage costs within your department (the efficiency side). Aiming for a ratio of zero is likely to lead in massive drops in effectiveness – however we have found that very large ratios, rarely result in effectiveness either.

What is your developer surround ratio and how can you start improving it?

Additional Insights

View all

The art of feedback

Product Quality Ways of Working
Learning happens at the rate of feedback. But only if the feedback is relevant, actionable, and provided in time. The most frequent failures to learn include listening to the views of pretend-users and expecting experts to return with ‘likes’ within minutes.
View all