If you’re a fan of DORA Metrics, you already know how measuring your software team’s true performance can help you identify areas that need improvement, and thus get a quick (and measurable) ROI.
We talk with a lot of DORA fans who are trying to convince their organizations to make investments in improving DORA Metrics. They get questions like:
- Why should we prioritize improving DORA Metrics, or setting DORA-related OKRs, versus all the other things we could do?
- If we’re considering investing in tools that help us improve our DORA Metrics (like Shipyard), how do we make the ROI justification / business case?
These kinds of questions are difficult to answer for the same reason it’s difficult to confidently answer any engineering initiative’s ROI: Engineering is complicated.
But we’ve come up with an approach to quantifying the ROI and making the case for improving DORA metrics - and of course, investing in Shipyard as part of your DORA improvement journey - that is rigorous and exec-friendly.
Quick DORA background
DevOps Research and Assessment (DORA) Metrics are the premier standard for evaluating the performance of modern DevOps and Platform teams. There are four metrics that, when combined, give you an idea of your engineering org’s process:
- Lead time for changes: How long does it take for new code changes to get integrated into production after initial commit?
- Deploy frequency: How often does your org deploy to production?
- Change fail percentage: What percentage of deployed changes result in a failure or regression?
- Failed deployment recovery time: How long does it take your org to restore/recover/rollback/patch after a bad deployment?
You can get a sense of your ballpark DORA Metrics in under a minute with this self-assessment.
DORA and ROI - A Simple, Time-Savings Approach
Let’s first start with the shape of ROI that you’d get from improving your DORA Metrics. Then we can get to specifics.
The basic shape is: engineers waste less time on non-value-add tasks. And so do others throughout the organization (QA, Product, DevOps, etc.)
So there’s a simple ROI calculation that says, essentially:
- Developers currently waste X amount of time per week
- A developer costs $Y per hour
- So we waste $Z per year in salaries
For most companies, this kind of simple math works well enough if everybody is kinda onboard. Which basically means: This simple math worked way better pre-2022.
In addition, we don’t like this view very much. It just looks at developers as a cost center. And that’s not right. Developers drive value, drive revenue and (gasp) profit when they focus on the core of their work.
DORA and ROI - A Deeper Version
Our ROI model takes this a step further, inspired by Don Reinertsen’s book, Principles of Product Development Flow. The book is pretty deep, but Don essentially argues that you prioritize product development initiatives by comparing the net present value of different projects’ lifecycle profits.
Avoiding a very deep rabbit hole - the point we take away from this is that we can directly connect developers’ work to revenue.
How do we do this?
At a high level, we calculate revenue per effective developer hour, and say, “if we cut out a bunch of waste, we get more effective developer hours that convert to more sales and better customer retention.”
So let’s say you’re at $20M ARR and have 20 developers. So, each developer supports $1M ARR with their current effective hours. If each developer is wasting 4 hours per week (10% of a 40-hour week) on administrative post-PR tasks that would be eliminated by improving DORA Metrics, you can argue that each developer could support $1.1M ARR (~10% * $1M ARR). By improving DORA Metrics, the real value to the business is $2M ARR.
Imagine, instead, if you just made the case for “time savings” - without connecting this to revenue. You’d look at the average developer salary, say $200k, and make the case that you’re saving 10% of their time, which equates to 20 * $200k * 10% = $400k theoretical cost savings. I don’t know about you, but I would prefer $2M extra ARR to $400k cost savings.
Now, you can make this kind of calculation much more detailed and CFO-ready. Two main ways to do that would be:
- Do a “net present value” calculation on the $2M ARR example from above. This calculation tells you the total value today of increasing revenue by $2M ARR in perpetuity. If you have an MBA on the team, see if they learned anything by asking them to help you do this.
- To get even fancier (say, if you have two underworked MBAs on the team), you can actually convert your product roadmap to a “net present value” calculation and determine what the value of accelerating your product roadmap by 10%+ would be.
Do This Yourself!
Email us at hello@shipyard.build if you’d like a free calculator to do this. Our recommendation is a simple model that shows:
- Each developer wastes X% of their week on things that, if we improved our DORA Metrics, they would no longer spend their time on. (Typical estimates range from 5-15%, in our experience.)
- The value of developers’ time is Y (calculated as total ARR divided by number of developers).
- Therefore, the value of improving our DORA Metrics are X * Y.
When you do this, we expect you’ll find that improving your DORA Metrics is among the most valuable investments you can make.
(And, while you’re at it, this calculation makes a very strong case for implementing ephemeral environments with Shipyard - in a few weeks you can make huge strides on your DORA Metrics. Massive ROI!)
