The Thematic Quarter: Why Your OKRs Are Fighting Each Other

It was a Thursday morning on level 6 and the glass-walled meeting room was full in the way that only quarterly planning meetings are full — every chair taken, a few people standing along the back wall with their arms folded the same way, cups of Thai iced tea going warm on the table because nobody wanted to be the one making noise with a straw. The slide on the screen had forty-three goals across nine teams, colour-coded into something that must have looked like alignment when someone built it at midnight the night before. Namfon was nodding slowly in the second row — the kind of nod that means nothing, the professional nod, the nod that says I am present and processing. Through the glass, you could see the rest of the floor — heads down, headphones on, entirely indifferent to whatever was being decided in there.

We’ve all been in that room. Some of us have run that room. And the problem isn’t the colour-coding.

The OKR Promise That Doesn’t Quite Deliver

OKRs are a genuinely good idea. John Doerr wrote the book on them — quite literally — and the framework is sound: set ambitious goals, measure outcomes, build accountability. The problem isn’t the framework. The problem is the assumption buried underneath it.

That assumption is this: if every team sets good goals, the organisation will have good goals.

It won’t. And if you’ve led more than two or three teams, you already know this in your bones even if nobody’s said it plainly. You can have ten teams all hitting their OKRs — genuinely, not just cooking the numbers — and still end the quarter with the organisation having made no meaningful progress on the thing that actually matters. Because each team optimised locally. Each team did exactly what it was measured on. And local optimisation, done well, doesn’t automatically sum to global progress.

Fredmund Malik, the Austrian management theorist, put it plainly: “The greatest enemy of organisational effectiveness is not incompetence. It is local optimisation.” He wasn’t being clever. He was describing the thermodynamics of how organisations actually work: energy put into one part of the system doesn’t automatically flow to where it’s needed most. It stays where it was generated.

This is the OKR problem nobody wants to say out loud. Teams have goals. Teams pursue them. The organisation drifts.

Enter Lencioni — and the Thematic Goal

Patrick Lencioni’s Silos, Politics and Turf Wars is a book most engineers won’t read because it’s written as a business fable and it doesn’t mention a single line of code. That’s a shame, because the central insight is one of the most practically useful things I’ve encountered in over two decades of leading engineering teams.

Lencioni’s argument is deceptively simple: silos aren’t caused by bad people, territorial managers, or bad culture. They’re caused by the absence of a compelling shared objective — one single goal that temporarily overrides everything else, one thing that everyone in the room is trying to accomplish together. He calls this a thematic goal.

Not a set of OKRs. Not a strategy doc. Not a vision statement. One goal. Qualitative, not quantitative. Defined for a specific period. Shared across the whole leadership layer in a way that’s specific enough to hurt.

Lencioni arrives at this idea through an observation that’s worth understanding: working across several companies, he noticed that one of them didn’t seem to have a silo problem when all the others did. The reason turned out to be a crisis the company was already living through — the kind where if they didn’t solve it, everyone goes home. That level of stakes had pulled the organisation together in a way that normal operations never had. Everyone knew what mattered. Everyone knew why. Nobody was protecting territory because there was no territory worth protecting if the whole thing collapsed. The crisis had manufactured the shared context that made collaboration the obvious default rather than the effortful exception.

His insight — and it’s a sharp one — is that crises create exactly the shared context that makes people collaborate. The bad news is that most organisations don’t figure this out until they’ve nearly destroyed themselves. The thematic goal is Lencioni’s answer: a deliberately manufactured shared context that mimics the clarity of a crisis without requiring the near-death experience. You want the urgency. You don’t want the stakes.

I’ve Seen the Crisis Version

Before Agoda, I worked at a ticketing company based in Australia, doing ticketing for large festival seasons. Once a year, the big onsales hit: hundreds of thousands of customers simultaneously trying to buy tickets for the same events. The system didn’t always cope.

On one occasion, we took a telephone exchange offline. Not metaphorically. The call volume from customers trying to buy tickets overwhelmed the local network infrastructure. An entire telephone exchange. Offline.

In that moment, nobody in the office asked what the quarterly priorities were. Nobody checked the backlog. Nobody talked about process. Every single person in that building knew exactly what needed to happen and who needed to talk to whom to make it happen. The team in Bangkok and the team in Australia, who might otherwise have traded polite emails for days, were on the phone with each other continuously. The onsale season, every year, was a voluntary manufactured crisis — a period where everyone dropped territorial behaviour because the shared problem was too obvious and too immediate to ignore.

That’s Lencioni’s thematic goal at its most visceral. You don’t want to need a crisis to feel that way. But you do want to find a way to bottle it.

Jim Collins, in Good to Great, wrote something that applies here at a different level than most people use it: “If you have more than three priorities, you don’t have any.” That’s usually quoted in the context of individual or team focus, but the more important application is across teams. Across ten teams, you have fifty priorities. None of them are shared. Collins is making an argument about concentration of force. The thematic goal is how you apply that force at the organisational level.

Breaking the Monolith: What a Thematic Quarter Actually Looks Like

Let me give you a concrete example from Agoda, because abstract frameworks are only as useful as the stories you can attach to them.

A few years ago, across roughly ten engineering teams, we ran what I’d now describe as a thematic year — though we wouldn’t have used that term at the time. The goal was structural: we had a large central monolith that one team owned, and that ownership had made them a bottleneck for every other team that needed to ship anything touching their domain. The solution was decomposition — breaking the monolith into bounded services, each owned by the product team closest to that business domain.

In principle, this was a clean win. In practice, it required nine teams that had previously been consumers of another team’s work to become contributors to a shared codebase they’d never owned. Cross-team code reviews. Shared responsibility for deployment pipelines. Design decisions that couldn’t be made unilaterally. That friction was the shared investment that made the goal real — this wasn’t one team’s project that everyone else watched from the sidelines. Every team gave something up.

A few things made it work that wouldn’t have been obvious in advance.

A specialist team took the first heavy lifting. A dedicated group built the initial project templates, the shared CI infrastructure, and did enough of the first migration work that product teams had a pattern to follow. The activation energy problem is real: people won’t change how they work if the new way of working requires them to invent everything from scratch while also delivering a quarter. Give them the first move, and they’ll follow.

Measurement was on the right metric — and it wasn’t obvious. We tracked merge requests into the monolith versus the new services, and we deliberately prioritised moving the components that had the highest contribution volume first — the parts people were most actively changing, not the parts that seemed most architecturally central. This is counterintuitive. You might think you should start with the core. But starting with what’s most actively touched means you immediately reduce the friction that teams feel every day. Progress becomes visible to the people who are doing the work.

The goal was the question in every 1:1. Not occasionally. Not quarterly. Every relevant technical review, every planning session, every OKR check-in: “How is this helping with the monolith split? If it’s not, why are you doing it?” Not as a gotcha. As a genuine coordination question. (This is the mechanism that makes culture stick — I wrote about it in the context of building repeating leadership habits — the same principle applies at the goal level. If the goal isn’t the question you ask in every room, it isn’t the goal.)

A monthly cross-team demo kept progress social. With ten teams, a monthly demo where everyone sees what everyone else is shipping is tractable. The monolith progress was visible and accumulating. Teams could see each other’s work. The goal had a face. Past much beyond ten teams this stops working — the demo becomes too long, too broad, and too passive to be useful. If you’re operating at that scale you’ll need a different mechanism for cross-team visibility, but the underlying need is the same: progress has to be seen, not just reported.

Recognition made the goal visible beyond the room. I had t-shirts made — “Monolith Breaker” — and gave them out to engineers who did meaningful work toward the goal. Not as a formal award programme. As a moment: a photo of the presentation, posted in a large public Slack channel, visible to the whole engineering floor. It sounds small. It isn’t. When people see a colleague being recognised publicly for contributing to a specific goal, two things happen: the goal becomes real to everyone watching, and the recognised engineer becomes a visible ambassador for the work. The t-shirt is a prop. The Slack post is the message. Both together are a reminder, repeated across the year, of what the organisation is actually trying to do.

Three years in, we’re in the tail end. Not finished — these things always have a long tail — but past the heavy phase. After the first year, 80% of pull requests were going into the new services and only 20% were still going into the monolith. The code volume was probably the inverse ratio — there was still a lot of monolith left — but that’s the point. We weren’t trying to move the most code first. We were trying to move the most activity first, the parts people were touching every day. The impact was felt long before the migration was complete. The first year moved the most. That’s typical: the first push creates momentum, the middle phase grinds, the tail is long. If you’re planning a thematic year that involves structural change, build your expectations around that arc.

Why “Shared” Goals Usually Aren’t

The failure mode I’ve watched play out — in different organisations, at different scales — tends to look like one of two things.

The first is the waterfall of OKRs. The goal gets set at senior level, translated into team OKRs, and by the time it reaches engineers it’s unrecognisable. Everyone is technically “contributing to the goal” in a way that’s defensible and meaningless. The goal has been waterfall-planned to death before any work starts. You define the goal at the top, then let the waterfall of translation drain all the meaning out of it before it reaches anyone who can act on it.

The second is the announcement and retreat. The goal is announced. Everyone nods. Teams return to their existing work, attach a thin justification layer to their existing plans, and proceed as before. The thematic goal becomes a filter on how people describe what they were going to do anyway — not a driver of what they actually do.

Both failure modes have the same root cause: there wasn’t much effort on actually pushing the goal down. The announcement happened. The OKRs were set. Leadership assumed the goal had gravity of its own.

It doesn’t. Not at scale.

At ten teams, the informal cross-team connections needed for coordination exist or can be created with light effort. The monthly demo is tractable. One director can maintain real visibility into all ten teams. The mechanism works with relatively light management overhead. This broadly maps to what Large-Scale Scrum (LeSS) recommends: roughly four to eight teams per coordination area before you need to break into separate coordination structures.

Past around ten teams, the mechanism needs deliberate reinforcement that most organisations don’t provide. The informal connections aren’t there to be activated. The goal can’t travel through them. The OKRs are set and then left to fend for themselves. I’ve watched the failure play out at 22 teams — the goal gets announced, the OKRs cascade, and nine months later every team has a coherent story about how they contributed to the goal and the goal hasn’t moved. The stories are all true. The goal is still in the same place.

Two Things a Thematic Goal Actually Needs

The standard OKR advice — be measurable, be ambitious, be time-bound — is all sound. It’s also insufficient. A thematic goal needs two things that the standard advice doesn’t address.

1. Shared Pain — and a Shared Problem

A goal that only inconveniences one team isn’t thematic. It’s that team’s priority with better branding.

The test is honest and uncomfortable: can every team in the room articulate what they had to deprioritise or change because of this goal? If the answer is “nothing, really,” you don’t have a thematic goal. You have one team doing hard work while everyone else offers moral support.

Pain is where it starts. Something hurts — revenue, reliability, speed, customer experience — and that pain is the signal that a real problem exists. But pain alone isn’t a goal. In product engineering, we shape pain into a problem statement, and the problem statement is what drives the work. The thematic goal has to be built on a problem that’s genuinely shared — one that every team can feel in their own work, not just observe in someone else’s. If the goal doesn’t map to a problem that teams are already living with, it won’t generate the shared investment you need. It’ll generate compliance at best.

Across the ten teams in our area, “break the monolith” was a problem every one of them felt directly — slow deployments, risky changes, coordination overhead. The goal named the problem. That’s what made it land.

2. Active Coalition-Building

Setting the goal is not leading the goal.

This is the part that distinguishes a thematic quarter from a well-named OKR exercise. The goal needs to be the question in every relevant forum. VPs and directors need to be actively mapping which teams need to talk to each other and making those introductions rather than assuming coordination will happen organically. Cross-team touchpoints need to be created — not just a Slack channel, but actual recurring forums where teams report blockers to each other, not just upward.

My Org Chart Trap post argues that Conway’s Law creates an almost gravitational pull toward the shape of your reporting lines. A thematic goal is one of the few tools that can temporarily override that gravity. But it can’t do it by being announced. It has to be the thing the people with organisational authority are actively using that authority to push.

My silos post covers why silos form. This is how you build the temporary bridge across them. The bridge has to be maintained, repeatedly, by the people with the authority to hold it open.

Running a Thematic Quarter: The Practical Version

If you want to try this, here’s what I’d suggest based on what’s worked and what hasn’t.

Set one goal. One. Not “our themes for the quarter.” One thing the whole leadership layer is trying to accomplish. It should be specific enough that a team could argue, convincingly, that what they’re working on either contributes to it or doesn’t. Vague goals survive the announcement meeting and die everywhere else.

Make sure it hurts everyone. Before you announce it, stress-test it. If you’re small enough, talk to every team lead directly and ask what they’d have to deprioritise. If you’re larger, sample deliberately — a few team leads from diverse areas, not just the ones closest to you. At scale, a short survey works well: a single question asking what teams would have to stop or slow down if this became the priority. If the answer coming back is “nothing we weren’t already doing,” the goal isn’t thematic. Keep sharpening until everyone has to give something up.

Appoint a coalition builder. Someone whose job — for the duration of the quarter — is to actively map and facilitate the cross-team conversations the goal requires. This isn’t a passive role. It’s making introductions, attending cross-team reviews, and noticing when two teams are solving the same problem from different angles without knowing it.

Ask the question obsessively. In every planning session. In every 1:1 with team leads. In every technical OKR review. “How is this helping with [the goal]? If it’s not, why are we doing it?” Not as a gotcha. As a genuine navigation question. If the answer is never good enough to stop asking, it means the goal is working. If the question starts feeling rhetorical, the goal is drifting.

Create a cross-team visibility forum. At ten teams, a monthly demo works. Past fifteen, you probably need to structure this differently. But some mechanism where teams can see each other’s progress, surface blockers to each other rather than just upward, and feel the shared accumulation of work — that mechanism is load-bearing.

Measure the right thing. The OKR for the thematic goal should measure the outcome you’re trying to achieve, not the effort you’re putting in. And make sure the measurement makes the work feel meaningful: the monolith migration tracked MRs moving to new services and celebrated each one. Progress should be visible to the people doing the work, not just the people reviewing it in a quarterly business review.

The Bottom Line

Most organisations set OKRs as a goal-setting exercise. The best ones use them as a coordination mechanism. The difference is whether there’s a single shared objective with enough gravity to temporarily override the gravitational pull of team boundaries — and whether someone with authority is actively building the coalition to make that override real.

Lencioni’s insight, filtered through a few years of actually trying it: the thematic goal is a manufactured crisis. It works because it creates the same shared context that a real crisis creates — everyone knows what matters, everyone knows why, and protecting territory stops feeling worth it. But unlike a real crisis, you can choose when it starts, what it’s about, and how much it costs.

The hard part isn’t the framework. The hard part is setting a goal that actually hurts everyone enough to matter, and then not abandoning it when the quarter gets busy and it becomes easier to let teams drift back to their local priorities.

The even harder part is asking the same question, in every room, for twelve consecutive weeks. By week four it feels redundant. By week eight it starts to feel like leadership. By week twelve you’ll have learned whether the goal had legs — or whether you announced it and hoped.

Now, if you’ll excuse me, I have a 1:1 in fifteen minutes and I need to think of a diplomatic way to ask “how is this helping with the goal” for the eleventh consecutive week. Apparently I’m still working on making it sound fresh.