The quarter I remember most clearly ended with a green dashboard. Fourteen key results, thirteen complete. The engineering team had worked hard and had nothing to apologise for. Then the founder asked a reasonable question in the review: given all of that, what can the company do now that it could not do in July? Nobody had a good answer, and the silence lasted long enough to be useful.
The problem was not effort or ability. It was that we had taken a roadmap, split it into fourteen measurable pieces, and called the result objectives. This is the method I use now with engineering teams in Singapore. It takes about two weeks to set up for the first time and roughly an hour a fortnight to run.
Why a 93 percent hit rate is bad news
An OKR set exists to do one job: let a team decline work that does not serve the quarter. Everything else, the grading, the dashboards, the nested company alignment, is administration on top of that single function.
That means a set which is almost entirely achieved has usually failed in a specific way. Either the targets were things the team was already going to do, in which case the exercise added paperwork and no information, or the set was so large that nothing could be declined against it. Fourteen key results is the second case. Everything the team might do is somewhere on the list, so the list cannot arbitrate between two competing requests, which is the only moment an objective earns its existence.
The uncomfortable corollary is that a healthy engineering OKR set contains something you might genuinely miss. If every item is safe, you have written a plan, not a set of objectives.
Step 1: Cap the team at two objectives
Two objectives per quarter, at most three key results each. For a team under eight engineers, one objective is usually better than two.
The arithmetic makes the case on its own. A team of six has roughly seventy engineer-weeks in a quarter. Remove unplanned work, leave, onboarding and the ordinary cost of keeping an existing system running, and around forty weeks are genuinely available for new commitments. Two objectives fit inside that. Four objectives with three key results each do not, which is precisely how you end up hitting the easy twelve and missing the one that mattered.
When a stakeholder insists on a third objective, the productive response is not to argue about importance. It is to ask which of the two existing objectives moves to next quarter. The conversation becomes a trade rather than an addition, which is the entire point.
Step 2: Separate the objective from the roadmap
Write the objective as a change in the world, not a list of things that will exist. Ship the new onboarding flow
is a roadmap item. A new developer can reach a working integration without asking us for help
is an objective.
The difference is not stylistic. The first locks the solution in before the quarter starts. The second leaves room for the team to discover in week three that the real blocker is a confusing error message rather than the flow itself, and to fix that instead without technically failing.
Keep the roadmap. You need it, and the engineers need it more than the executives do. Just keep it in a different document, and never let the two be reconciled line by line, because the reconciliation always wins and the objective always loses.
Step 3: Write key results that survive the shipped-but-useless test
For every key result, ask one question: could we achieve this completely and still fail the objective?
If yes, it is an activity measure and it needs rewriting. Add twelve code samples
fails the test immediately. Sixty percent of new developers make a second API call without contacting support
passes it, because there is no way to satisfy that number while onboarding remains broken.
Two practical notes. First, some key results genuinely need to be delivery-shaped, usually infrastructure and compliance work where the outcome is binary and arrives later. Allow at most one of these per objective and label it so, rather than pretending it is an outcome. Second, if you cannot measure the outcome today, the first key result for the quarter is to instrument it. That is an honest answer and a common one in a team’s first OKR cycle.
Step 4: Reserve explicit capacity for unplanned work
Go back through the last two quarters and work out what share of engineering time went to incidents, customer escalations, security patching and compliance requests. In most Singapore teams I have seen, the honest figure sits somewhere between twenty and thirty five percent, and it is considerably higher for teams serving regulated financial customers.
Subtract that before committing to anything. Teams that skip this step do not discover the problem in week one, they discover it in week nine, and by then the only lever left is to quietly drop the hardest key result.
Write the reserve into the document as a line item. It converts an invisible tax into a visible number, and it gives you something concrete to point at when a stakeholder asks why the team committed to less this quarter than last.
Team hitting every target and the business still feels stuck?
We work with Singapore employers on delivery structure and team design, including the awkward cases where the problem is what the team committed to rather than how fast it works. Send us last quarter’s objectives and we will tell you what they were actually measuring.
Get a second readStep 5: Fit the quarter to the Singapore calendar
A quarter is thirteen weeks on paper and rarely thirteen weeks in practice here.
Chinese New Year removes considerably more than the two gazetted public holidays. Leave clusters around the break, and counterparts in Malaysia, Hong Kong and mainland China are out at the same time, so anything that needs a decision or a review from a regional partner stalls for longer than your own office is closed.
December produces the same pattern at the other end. Leave accumulates towards year end, and the last two weeks are rarely productive for anything requiring coordination.
The adjustment is simple and almost nobody makes it: size a first-quarter commitment against roughly ten usable weeks rather than thirteen, and schedule any key result that depends on a regional counterpart into the second half of the quarter. Teams that do this stop producing a predictable Q1 miss that has nothing to do with engineering capability, and stop writing the same retrospective entry every February.
Step 6: Check in fortnightly with a confidence score
Fifteen minutes every two weeks. For each key result, one person gives a confidence percentage that it will land by quarter end, and one sentence on what changed since last time.
The value is entirely in the trend. A key result sitting at 50 percent confidence is information. A key result that drops from 80 to 50 to 30 across three check-ins is a decision waiting to be made, and the point of the ritual is to force that decision in week six rather than week twelve.
Set an escalation rule in advance: any key result whose confidence falls twice in a row gets fifteen minutes of its own, with three options on the table. Change the approach, reduce the target, or drop it and say so. Dropping an objective in week six is a normal management act. Discovering it failed in week thirteen is not.
Step 7: Grade, write the retrospective, and keep it out of performance reviews
At quarter end, grade each key result as a fraction of target. Then spend the useful part of the hour on one question: where was our estimation wrong, and in which direction?
Over three or four quarters this produces a genuinely valuable artefact, which is a calibrated sense of what the team can commit to. Most teams discover they are consistently optimistic about work involving another department and consistently pessimistic about work entirely inside their own codebase. That is actionable in a way that any single quarter’s grades are not.
Then the rule that matters most: these grades do not enter performance reviews, promotion cases or bonus calculations. Say it out loud at the start of each cycle, and keep the grading document separate from anything a compensation conversation references.
The mechanism is not subtle. If a grade affects pay, people set targets they are confident of hitting, and you get a quarter of 100 percent achievement that teaches you nothing. In Singapore this needs stating more explicitly than elsewhere, because teams are often small enough that the same manager runs the objective review and the performance review, and silence on the point will be read as the answer.
The four patterns I see most often
| Pattern | What it looks like | The fix |
|---|---|---|
| Roadmap in disguise | Every key result starts with Ship, Build or Launch | Apply the shipped-but-useless test to all of them |
| Too many to refuse with | Ten or more key results, all plausible | Cap at two objectives, trade rather than add |
| Borrowed metric | A number the team cannot influence, such as revenue | Move one step closer to what engineering controls |
| Graded into pay | Perfect scores, quarter after quarter | Separate the documents and announce it |
The third pattern deserves a note, because it is the well-intentioned one. Attaching an engineering team to a revenue target feels like alignment, and it produces a number the team can watch but not move. Step one layer closer: conversion from trial to paid is usually still outside engineering control, while time to first successful integration is usually inside it, and the second one is what actually feeds the first.
What the first cycle realistically looks like
Expect the first quarter to be mediocre, and plan for it. The objectives will be slightly too broad, one key result will turn out to be unmeasurable, and somebody will forget a check-in. None of that means the system is wrong.
The second cycle is where it starts to pay, because you now have a calibration point and a team that has seen a target dropped in week six without anyone being blamed for it. That single precedent does more for the honesty of the process than any amount of training, and it is the reason I push teams to drop something visibly in their first quarter rather than grinding everything over the line.
If you are putting this in place alongside other team structure work, our guides on building an engineering career ladder and structuring developer compensation packages cover the performance side that these grades must stay out of, building an on-call rotation covers the unplanned work you are reserving capacity for, and running a distributed engineering team covers the regional coordination that quietly consumes Q1.
A target you cannot miss is a target that tells you nothing.
We help Singapore employers structure engineering teams that commit to outcomes and have the capacity to meet them. If your team is busy and the business cannot tell, that is usually a structure problem rather than a hiring one, and we will say so.
Talk to our Singapore teamFrequently asked questions
How many OKRs should a Singapore engineering team set per quarter?
Two objectives, with no more than three key results each, and for teams under eight engineers one objective is usually better. The purpose of an OKR set is to let a team refuse work, and a list of fourteen items cannot refuse anything because everything is on it. There is also a practical arithmetic problem in a small team. A team of six has roughly seventy engineer-weeks in a quarter, and once you remove unplanned work, leave, onboarding and the ordinary cost of keeping an existing system running, around forty of those weeks are genuinely available. Two objectives consume that comfortably. Four objectives with three key results each do not, which is why teams that set twelve key results tend to hit most of the easy ones and miss the one that mattered.
What is the difference between an engineering OKR and a roadmap?
A roadmap lists what you intend to build. An OKR states what you want to be different afterwards. The test is whether the item could be fully delivered while the situation it was meant to improve stays exactly the same. Ship the new onboarding flow
is a roadmap item: you can ship it and have no new activated users. Reduce time from signup to first successful API call from eleven minutes to under three
is an objective with a measurable outcome, and it leaves the team free to discover that the real blocker was documentation rather than the flow. Keep both documents. The failure mode is not having a roadmap, it is pasting the roadmap into the OKR template and calling the result a strategy.
Should engineering OKRs feed into performance reviews or bonuses?
No, and this is the single decision that determines whether the system survives its second quarter. The moment a grade affects compensation, people set targets they are confident of hitting, which removes the only useful property OKRs have, namely that they make a team commit to something uncertain in writing. You will get a quarter of 100 percent achievement and learn nothing. Keep grading as a learning exercise about estimation, run it in a document that performance conversations do not reference, and say so explicitly at the start of each cycle. In Singapore this matters more than in some markets because many teams are small and the same manager runs both conversations, so the separation has to be stated rather than assumed.
How do Singapore public holidays and Chinese New Year affect quarterly OKRs?
They remove roughly three usable weeks from the first quarter, and almost every team discovers this in week ten rather than week one. Chinese New Year falls in late January or February and most teams lose more than the two gazetted public holidays to it, because leave clusters around the break and regional counterparts in Malaysia, Hong Kong and mainland China are also out, which stalls anything needing a decision from them. December has the same pattern at the other end of the year. The practical adjustment is to size a first-quarter commitment against around ten usable weeks rather than thirteen, and to put any key result that depends on a regional partner into the second half of the quarter. Teams that do this stop producing a predictable Q1 miss that has nothing to do with engineering capability.
Bryan
Delivery & Offshore Teams Expert at HireDeveloper.sg. Works with Singapore employers on delivery structure, distributed team design and the planning problems that surface when an engineering team grows past its first process.