OKRs for Software Service Companies

Most OKR writing is aimed at product companies. The examples are about activation, retention and roadmap squads. If you run a software house of 50 to 150 people, you read them, nod, and notice that none of it touches how your business makes money. You sell people's time. Your calendar is full of other companies' projects. The question for the quarter is less "what do we ship?" and more "what kind of company are we trying to become?"

This article is for that company.

The situation

A services firm at this size has usually won a lot of work. Delivery teams are busy and utilization looks healthy. The founders still sit in the middle of every important decision: pricing exceptions, staffing conflicts, which client gets the best people.

Initiatives pile up because each one is reasonable. A recruiting push, a new technology practice, a productized offer, a partner program, a rebrand. Nothing gets cancelled, so everything moves slowly, and the same five people carry all of it on top of their billable weeks.

Nobody here is lazy. The structure rewards billable work, and OKRs are about work that isn't billable. That tension is the first thing to design around.

What OKRs can do for a services firm

Two things, and they are enough.

First, they force a short list. Three to five priorities that the whole leadership team can name without looking at a slide. In a firm where every initiative is reasonable, the list is the hard part, and the arguing it takes is the value.

Second, they separate delivery from change. Delivering projects well is the business as usual. Changing what the firm sells, to whom, and at what margin is the OKR. Keeping these apart is easier said than done, because delivery is where all the urgency lives.

The core trap: putting delivery in the OKRs

The easiest services-firm OKR set to write is a restatement of the monthly management report. Utilization at 80%. On-time delivery at 95%. Client satisfaction above 4.5. Attrition under 12%.

Those are health metrics. They are KPIs, and you need them (Article 3 covers the difference). The test from that article applies cleanly: if you stopped working on utilization, would the business break next month? Yes. So it stays on the dashboard, with a threshold and an owner, and it does not take a Key Result slot.

Put it in the OKRs and you get a set that looks busy and changes nothing. The vocabulary is new, and the Monday decisions are the same.

The cost nobody budgets

A change goal needs people with hours to work on it, and in your firm hours are the product. Every hour spent building a managed-team offer is an hour not billed.

Decide this before the quarter starts. How many non-billable hours will the company fund for the objective, and who gives them up? Treat it as the price of the change and say it out loud. When nobody decides, the work happens in evenings and gaps, and the first busy delivery month ends it.

An example (illustrative numbers)

Here is the shape of a company-level OKR for a services firm. The numbers are invented to show the structure. Yours come from your own data.

Objective: Escape project-shop economics

• KR1: Recurring revenue (retainers, managed teams, maintenance) from 12% → 25% of total revenue
• KR2: Gross margin on newly signed contracts from 28% → 35%
• KR3: Revenue from our largest client from 38% → 25% of total

Notice what is missing. "Launch a managed-team offer" is not a Key Result. It is an initiative, a bet on how to move KR1. "Reprice the discovery phase" is another. Keep those in a separate list, because you will change them mid-quarter when the evidence says so, and the Key Results should stay put.

Each KR changes the shape of the business. None is a task, and each has a start value and a target (Article 5).

The same logic works one level down. A delivery team does not need OKRs for delivering. It may need one for a specific change, for example: forecast accuracy on fixed-price estimates, with the gap between estimated and actual hours moving from 30% → 15%. That is a team fixing a leak that shows up in the margin KR above.

Where it goes wrong

The 200-Key-Result sprawl. Every project team writes its own OKRs, each with five KRs, and the company ends up tracking a hundred numbers nobody can connect to a decision. Give delivery teams one change goal at most, and only where it ladders up to the company objective.

Strategy that never reaches Monday. The OKRs are written, but staffing is still decided by whoever argues loudest, and pricing exceptions still go to the founder. Check one thing after the first month: did any OKR change a staffing, pricing or hiring decision this week? If not, the OKRs are decoration.

The founder who can't let go. This is the one below the waterline. Real ownership of a Key Result means a partner stops deciding something they have always decided. For a founder, being the bottleneck is also a way of being needed, and giving that up feels like losing a role. A framework cannot say this out loud. Someone in the room has to. I write more about it in the Below the Waterline series.

What I would do in the first quarter

Start smaller than feels respectable.

1. One company objective. Three Key Results.
2. An owner for each KR who is not the CEO.
3. A written capacity budget: the non-billable hours funded for the quarter.
4. A 30-minute weekly check-in on one question: what is blocking the movement of these three numbers?
5. A retro at the end, because cycle one will be rough (Article 7).

If the three numbers cannot be calculated by one person from one source on a Friday afternoon, fix that before the quarter starts (Article 2, reason 7).

What it surfaces

OKRs surface problems; they don't solve them. In a services firm, the problem they surface is usually that the constraint is the business model and not the team. Margin stuck at 28% is a pricing and scoping problem. A 38% client share is a risk the leadership team has been choosing to carry. Seeing that on one page, with a number next to it, makes it harder to keep ignoring.

Next up: the same exercise for a company that sells software instead of time.