In Blog

The final result of a software development department is working code, code that we hope will be valuable (effective).

So, three years ago at Pearson, we 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

When I was appointed in charge of software development at Pearson, we 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.

Now when I left Pearson, 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 we were both more effective and more efficient. We 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 me 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?

Recommended Posts
Showing 4 comments
  • Bob Marshall

    Nice post. I’m finding the section titled “What Does It Look Like in The Real World” very confusing though. Can you help me understand it better?


    – Bob

  • Paul Dolman-Darrall

    I just wanted to give a practical example of its use.

    So at Pearson we employed a lot of surround

    Surround were paid approximately £40
    Developers were paid approximately £32

    (Rounded numbers being used here, the above numbers are more precise – just for example)

    So per hour of development, we would have 3.8 surround people (analysts etc) to every 1 developer. So the total cost was £40 x 3.8 + £32 x 1 = £184 per hour of development.

    Over time we reduced the surround, without negatively impacting effectiveness.

    So development would now cost £40 x 1.8 + £32 x 1 = £104 per hour per hour of development.

    Hopefully that makes is more clear.

    It means we have removed 2 people from the surround per 1 developer. The actual money savings came mainly from natural wastage (people leaving), and because it made sense to do so, more developers were recruited from some of the savings.

  • Ben Mathews

    Where do you draw the line on who to count as surround?

    Definitely surround, their primary function is assisting the software development process:
    BAs, ScrumMasters, QAs, and Designers.
    Middle managers (e.g. Dev Lead, BA lead etc)
    Release Manager
    (If we just count this set, our ratio is 0.83)

    Not sure about these, their primary function is not assisting the software development process but they are heavily involved:
    Product Owners (have responsibilities in their business areas outside what they do with the tech teams)
    Ops (support live rather than focussing on new development)
    SEO/SEM Experts
    (If I count this lot too, our ratio is 1.33)

    • Paul Dolman-Darrall

      You first calculation seems fair enough of 0.83, I typically limit it to those who it is their primary purpose to be part of the software development process. A precise answer is not necessarily helpful.

      0.83 does not seem excessive, since I have suggested a surround of 1:1 is a good initial target point that most companies can achieve,

Leave a Comment