For two years I reported six engineering metrics to a board every quarter. Velocity, story points completed, commits per engineer, tickets closed, sprint predictability, and a bug count. The slides looked rigorous. Not one of those six numbers ever caused anybody to decide anything. When the team was visibly struggling, the metrics stayed flat. When we fixed something significant, the metrics stayed flat. They were decoration with error bars. What finally worked was smaller and much less comfortable: four delivery metrics, one honest baseline, and a rule that they never appear in a performance review. This is the seven-step setup I now use, written for engineering leaders in Singapore who need a measurement that survives contact with a budget conversation and actually tells them which role to open.
Step 1: Write Down the Decision Before You Instrument Anything
The reason my six metrics were useless is that I never defined what they were for. I was measuring because measuring felt responsible. Before you touch any tooling, write one sentence: “We are measuring delivery performance in order to decide X.”
For most Singapore engineering leaders, X is one of four things: whether to add headcount and in which role, whether to invest in tooling instead of people, whether a delivery problem is a team problem or an architecture problem, or whether a change you already made actually worked. Each of those needs different evidence, and only the first two are hiring questions.
Apply this test to every metric you currently report: name a specific decision in the last year that this number changed. If you cannot, the metric is overhead. Commits per engineer never passes this test. Story points almost never pass it, because they are a planning instrument that gets misread as an output measure, and they are not comparable between teams or even between quarters on the same team.
Our Expert Take
The decision-first rule sounds like consultancy language until you apply it honestly, and then it deletes most of your dashboard. That is the intended result. A small number of metrics that are actually consulted beats a comprehensive dashboard nobody opens between board meetings. The second-order benefit matters too: when you can state which decision a number informs, engineers stop treating measurement as surveillance, because the purpose is legible and it is obviously not about them.
Step 2: Instrument the Four DORA Keys From Systems You Already Run
The DORA framework, developed through the DevOps Research and Assessment programme and published annually in the Accelerate State of DevOps reports, settled on four measures that correlate with organisational performance. Two describe throughput, two describe stability.
- Deployment frequency. How often you successfully release to production. Source: your deployment pipeline or release tags in Git.
- Lead time for changes. Elapsed time from code committed to that code running in production. Source: commit timestamp joined to deployment timestamp.
- Change failure rate. The share of deployments that cause a degradation needing remediation, such as a rollback, hotfix or patch. Source: your incident tracker joined to deployments.
- Time to restore service. How long from failure detected to service recovered. Source: incident open and close timestamps.
The important practical point: all four are derivable from Git, your CI or CD system and your incident tool. You do not need to buy an engineering intelligence platform to begin, and you should not, because a purchase decision at this stage usually delays the measurement by a quarter and imports someone else’s definitions. Start with a weekly script and a spreadsheet. If the numbers end up driving decisions, buying better tooling becomes an easy case to make later.
The finding that makes these four worth using together is that throughput and stability move together in high-performing organisations rather than trading off against each other. Teams that deploy more often also recover faster. That is counter-intuitive to most executives, who assume speed must cost reliability, and it is the single most useful thing to be able to demonstrate with your own data in a budget conversation.
Step 3: Take an 8-Week Baseline Before You Change Anything
The urge once the numbers appear is to act on them immediately. Resist it for eight weeks. Two sprints of data is mostly noise: one large feature, one public holiday, one bad incident or one release-cycle quirk will dominate the signal entirely.
Eight weeks is usually enough to see whether a pattern is structural. In Singapore it is worth choosing the window deliberately so it does not straddle a major holiday period, which distorts both throughput measures and then quietly poisons every comparison you make against that baseline for the next year.
Record the baseline somewhere permanent and date it. The most common failure here is informal baselining, where the team remembers deployment frequency as “about weekly” and six months later nobody can prove whether an improvement happened. A dated baseline is what converts a later argument from opinion into evidence.
Step 4: Keep These Metrics Strictly Out of Individual Performance Review
This is the step that determines whether the whole exercise works, and it is the one most organisations get wrong.
The four keys measure a delivery system: the pipeline, the review process, the test suite, the architecture, the operational tooling, the amount of unplanned work. An individual engineer controls very little of it. Attaching the measures to a person is both unfair and ineffective.
It is also self-defeating on a short timescale. The moment engineers understand that deployment frequency affects their review, the number improves and the underlying reality does not: pull requests get split into meaningless fragments, trivial commits get deployed to inflate the count, and necessary but risky refactoring work stops happening because nobody wants to own a change failure. You will have paid for a measurement system that now actively misleads you.
Three rules keep this clean. Report at team level or above, never per person. Make the data visible to the engineers it describes, in the same form the leadership sees, because secret measurement is correctly read as surveillance. And state explicitly, in writing, that these numbers are not inputs to performance review or compensation, then hold that line the first time someone senior asks for a per-engineer breakdown. That first refusal is what makes the policy credible.
Metrics say you need people, but not which people?
Translating a delivery bottleneck into the right role and the right seniority is where most hiring plans go wrong. We scope engineering roles for Singapore employers against the actual constraint.
Scope the Role With UsStep 5: Add the 2 Context Signals DORA Does Not Capture
The four keys tell you how your delivery system performs. They do not tell you why. Two additional measures explain most of the remaining variance, and both are cheap to collect.
Review latency. Median time from pull request opened to first substantive review. This is the most common hidden cause of long lead times, and it is invisible in the four keys because it hides inside the commit-to-deploy interval. Teams routinely discover that half their lead time is code sitting in a queue waiting for attention, which is a scheduling and ownership problem rather than a capacity problem.
Unplanned work share. The percentage of engineering time spent on incidents, urgent escalations and interruptions rather than planned work. This is the strongest leading indicator of both burnout and attrition, and it is the one signal in this whole set that most directly justifies headcount. A team sustaining a high unplanned work share is not slow, it is saturated, and no process improvement fixes saturation. If you are seeing this alongside retention problems, our note on developer retention in Singapore covers the downstream consequences, and building a sustainable on-call rotation addresses the most common structural cause.
Step 6: Convert the Bottleneck Into a Specific Hiring Decision
This is the step the first five exist to serve. Each failure pattern points to a different response, and most of them are not hiring. Being able to say that with evidence is what makes the measurement worth the effort.
| Pattern in the data | Most likely cause | Correct response |
|---|---|---|
| Long lead time, review latency high | Review queue and ownership | Process change. Hiring makes it worse |
| Long lead time, review latency normal | Slow pipeline or heavy manual testing | Tooling and automation investment |
| High change failure rate | Test coverage or environment drift | Tooling, not headcount |
| Long time to restore | Knowledge concentrated in one person | Hire, plus documentation and on-call reform |
| High unplanned work share, sustained | Operational load exceeds capacity | Hire. This is genuine saturation |
| Low deployment frequency, everything else healthy | Batch-size and release culture | Process change |
Note how few rows say hire. In my experience the most frequent genuine finding is the first: a long lead time driven almost entirely by review latency. Adding an engineer to that team increases the number of pull requests queued behind the same overloaded reviewers and makes the metric worse. The correct fix costs nothing and takes a fortnight.
When the data does argue for hiring, it also tells you the seniority. Saturation from operational load is usually solved by a mid-level engineer who can absorb run work. Knowledge concentration and a long time to restore usually needs a senior hire who can redesign the operational model, not just add hands to it. That distinction routinely changes a search by several weeks and a salary band by a wide margin, and getting it right beforehand is worth more than any sourcing tactic. Our guide to structuring a technical interview process in Singapore covers the loop once the role is settled.
Step 7: Review Quarterly and Delete Metrics That Stopped Changing Decisions
Measurement systems accumulate. Someone asks for a number during an incident, it gets added to the dashboard, and it stays there for three years because removing it feels like hiding something.
Run the Step 1 test every quarter on every metric you report: which decision did this change in the last two quarters? If the answer is none, delete it. This applies to the four keys as well. A team that has had a change failure rate of near zero for a year does not need it on the weekly review; move it to an exception alert and reclaim the attention.
Add one thing to the quarterly review that is not a metric: ask the engineers whether the numbers match their experience. When the dashboard says delivery is healthy and the team says it is grinding, the dashboard is wrong, or it is measuring a system that has routed the pain somewhere you are not looking. That divergence is the most valuable signal in the entire exercise, and it is the only one that never shows up in a chart.
Our Expert Take
The reason the DORA keys survive contact with a budget conversation, where velocity and story points do not, is that a finance director understands them without translation. Time from decision to customer. Share of releases that break. Time to recover. Those are business quantities expressed in business units. The most practical argument for adopting them is not measurement rigour at all: it is that they let an engineering leader make a headcount case in language the people approving headcount already speak.
Frequently Asked Questions
What are the four DORA metrics?
Deployment frequency (how often you successfully release to production), lead time for changes (elapsed time from code committed to code running in production), change failure rate (the share of deployments causing a degradation that needs remediation), and time to restore service (how long recovery takes once a failure occurs). The first two describe throughput, the last two describe stability. The central research finding is that throughput and stability rise together in high-performing organisations rather than trading off, which is why measuring only one pair gives a misleading picture. All four are derivable from Git, your deployment pipeline and your incident tracker, so you can start without buying anything.
Can DORA metrics be used to evaluate individual developers?
No, and trying is the most common way organisations destroy the value of the measurement. The four keys measure a delivery system: pipeline, review process, test suite, architecture, operational tooling. An individual controls very little of that. Once engineers understand the numbers affect their review, the metric is gamed within a sprint through split pull requests, trivial deployments that inflate frequency, and avoidance of risky but necessary refactoring. Three rules keep it clean: report at team level or above, make the data visible to the engineers it describes, and state in writing that it is not an input to review or compensation, then hold that line the first time a senior stakeholder asks for a per-engineer breakdown.
How long before DORA metrics are useful for a hiring decision?
Plan an eight-week baseline before drawing conclusions. Two sprints is mostly noise driven by release cycles, holidays, one large feature or a single bad incident. Eight weeks usually distinguishes a structural pattern from an artefact. In Singapore, choose the window so it does not straddle a major holiday period, which distorts both throughput measures and then quietly poisons every later comparison against that baseline. Once a baseline exists and is dated and recorded permanently, a sustained four-week deviation is meaningful. Hiring on a two-week dip is how teams end up with headcount that does not address the real constraint, which is expensive and very slow to reverse.
What if the metrics say the bottleneck is not headcount?
That is the most valuable outcome, and it is the common one. A long lead time caused by review latency is a process and ownership problem, and adding an engineer makes it worse because more pull requests queue behind the same reviewers. A high change failure rate usually means missing test coverage or an environment that does not resemble production, which is a tooling investment. Only two patterns argue clearly for hiring: sustained high unplanned work share, meaning operational load exceeds capacity, which typically calls for a mid-level engineer to absorb run work; and a long time to restore caused by knowledge concentrated in one person, which calls for a senior hire who can redesign the operational model rather than just add hands.
Instrument the Four Keys This Month. Open the Right Role Next Quarter.
We help Singapore engineering leaders turn a delivery bottleneck into a scoped role at the right seniority.
Role scoping, sourcing, technical screening and salary benchmarking, handled end to end.
Scope Your Next Engineering Hire