Here's a question that divides every leadership team: "Should this team have its own strategy?" Every time this comes up, the room splits into "everything cascades from the top" traditionalists and the "every team needs autonomy" advocates.
Both are wrong. And both are right.
The real question isn't whether your team needs a strategy - it's knowing where to keep teams aligned under one strategy and where to let them diverge.
The Decision Stack and How It Connects
As a reminder, the Decision Stack is a mental model for connecting the big picture to daily work through five questions:
- Where are we going? (Vision)
- How will we get there? (Strategy)
- What matters right now on that journey? (Objectives)
- What actions do we take to move forward? (Opportunities)
- How do we do the work? (Principles)
One of the things that makes the Decision Stack such a powerful mental model is that those 5 questions create a two-way street: they help us answer "How?" from top to bottom (how do we achieve the vision? here's our strategy; how do we execute the strategy? here are our objectives, and so on), and "Why?" from bottom to top (why does this work matter? because it achieves these objectives; why these objectives? because they deliver this strategy). This laddering connects the dots from vision to execution for leaders, and from daily work to vision for the teams doing the work.
Most Organisations Split the Stack Wrong
Here's the thing: any organisation larger than a handful of people will have multiple Decision Stacks. The question isn't if you'll split into multiple stacks, but where.
This is where most organisations go wrong: they split based on their organisational chart, not where answers actually diverge. The temptation is to give each team a complete Decision Stack, but that ends up in a fractal mess. Just because you have separate teams doesn't mean you need separate visions or even strategies.
In fact, the more teams can share one Decision Stack, the better. Shared vision, strategy, or objectives create compounding benefits - teams naturally coordinate, unnecessary conflicts dissolve, duplicate efforts disappear, and the whole becomes greater than the sum of its parts.
The goal isn't to give every team its own stack. It's to share as much as possible and split only where necessary.
Finding Your Natural Fracture Points
The how/why laddering reveals a simple truth: fracture points occur wherever different teams would answer "How?" differently.
There's a simple heuristic I use: start from your company vision and work down, asking "How?" at each level. The moment teams have different answers to "How?" is where you need to split your stack.
- How will we achieve our vision? → Different answers = different strategies
- How will we execute our strategy? → Different answers = different objectives
- How will we achieve our objectives? → Different answers = different opportunities to pursue
- How should we approach our work? → Different answers = different principles
This makes the fracture points obvious. If two teams have the same answer to "How will we achieve the vision?", they should share the same strategy. If they have the same answer to "How will we execute the strategy?", they should share objectives. Keep sharing until their answers diverge.
Split where answers diverge, not where org charts divide.
Making it Real
Let me show you how this plays out in practice with examples from my time at Monster.
When Strategy Splits
Strategy fundamentally answers "where will we play" and "how will we win there." If two teams have different answers to these questions, they need different strategies.
At Monster, we tried to bolt a SaaS business onto our traditional transactional model (job ads and resume database access). It failed, largely because we didn't recognise that these needed fundamentally different strategies. The SaaS team was trying to win through annual contracts and platform stickiness. The core business won through volume and transaction velocity: same go-to-market team, completely different playbooks.
We should have split the strategy and given each business its own "how to win" narrative. When teams are going after different markets or competing with different rules, they need distinct strategies.
The key lesson here is that when you split strategies, you don't abandon the company-level strategy - you add a layer. You should still have a clear company strategy that articulates your overall market position and competitive approach. Then, beneath that, you articulate team-specific strategies that explain how each team contributes to that company strategy in their particular domain. Both ladder up to the company strategy, but each provides specific guidance for its distinct playing fields.
Yes, this means you have two strategy levels in your Decision Stack, which might feel like the cascading we're trying to avoid. But there's a crucial difference: you're not cascading the same strategy down through levels - you're acknowledging that these teams operate in fundamentally different contexts. The company strategy provides the "what" and "why", while team strategies provide different "hows" for different games.
Without this clarity, teams either get lost trying to force-fit a company strategy that doesn't match their reality, or they go rogue and create strategies that don't connect to the company's direction at all. Neither leads anywhere good.
Remember: just like OKRs, we don’t want to cascade these endlessly - team strategy should be one step removed from company strategy at most. Any more and you lose the focus that strategy should provide and break the how/why laddering that connects daily work to the bigger picture.
When Objectives Split (But Strategy Doesn't)
Sometimes teams are playing in the same market with the same strategy, but need different objectives. This is probably the most common split point, and it's healthy.
Two product teams might share a strategy of "win the SMB market through superior user experience", but have completely different quarterly objectives - one focused on activation, another on retention. That's fine. They both ladder up to the same strategy.
When Principles Stay Connected
Here's where it gets interesting. At Monster, we had a principle: "Job seekers even over Recruiters." You might think the recruiter product team should have their own principles - after all, they're building exclusively for recruiters.
But that misses the point. The "even over" format doesn't mean recruiters don't matter - they absolutely do. It means when faced with a trade-off, we err on the side of job seekers. The recruiter team can and should build fantastic products for recruiters. They should delight recruiters, solve their problems, and make their lives easier. When a decision could go either way - when there's a genuine tension between job seeker needs and recruiter convenience - the principle guides us toward the job seeker.
This shared principle prevents local optimisation that damages the overall ecosystem. Every recruiter feature should ultimately create better outcomes for job seekers by helping recruiters find and engage the right candidates more effectively. The principle acts as a north star, not a prohibition against serving one side of the market.
If your teams genuinely need different principles, you might actually have different businesses.
That said, teams can and should add their own principles on top of company ones - as long as they complement rather than contradict. Think of company principles as the foundation, with team principles adding specificity for their particular context.
These team-level principles don't replace or contradict the company principle - they add another layer of guidance for decisions that are specific to that team's work. The key test: if a team principle ever conflicts with a company principle, the company principle wins. This maintains coherence while giving teams the tools to make consistent decisions in their own domain.
This two-level approach to both strategy and principles might feel like added complexity, but it's actually how you maintain both alignment and autonomy. Company-level decisions provide the boundaries and direction; team-level decisions provide the specific guidance needed to win in different contexts.
The Sense Check
Once you've split your stacks, you need to verify they still connect. Use the how/why laddering again:
- Can someone at the bottom explain WHY their work matters by climbing up through their stack to company vision?
- Can someone at the top explain HOW the vision gets delivered by climbing down to team-level work?
If at any point this laddering breaks, you've found hidden complexity or lack of clarity that needs resolving.
Of course, you also want to ensure that any teams that diverge from each other in the stack are still complementing one another and the overall company strategy. There's no point having a mental model for alignment if you make teams work at cross-purposes to each other!
The Twist
Here's the twist. While you shouldn't let your org design drive your stack, you should probably let your stack drive your org design. When you get to a point where answers diverge, if you don't have separate teams that own each answer, you'll leave one team confused about their priorities.
This is either a sign you need to make a tough strategic decision about which to pursue, or to split the team into two, each with its own strategy for how to achieve the company strategy.
Principles to Guide You
There's no universal answer to "does my team need a strategy?", but there are principles to guide you:
- Split where answers diverge, not where org charts divide. Natural fracture points don't always match your reporting structure.
- Share as much as possible. The more teams that share elements of a Decision Stack, the more aligned and effective your organisation becomes.
- When you split, add layers rather than replace. Company strategy and principles remain the foundation. Team-specific strategies and principles add precision for their context without breaking from the company direction.
- Different markets or competitive dynamics require different strategies. Same market with different objectives? Keep the strategy unified.
- Resist the cascade temptation. Whether it's strategy or OKRs, one step removed from the company level is best.
- Principles should transcend team boundaries. They're guardrails for the entire system, not local optimisations.
- Always verify the connection. If you can't ladder up and down between stacks, something's broken.
So What Should You Do?
When someone next inevitably asks, "Should this team have its own strategy?", don't reach for the org chart. Instead, work through the "How?" questions together.
Start with your vision. Ask "How will we achieve this?" If everyone has the same answer, you share a strategy. Keep going. Ask "How will we execute our strategy?" Keep sharing elements until the answers genuinely diverge.
The Decision Stack isn't about creating perfect hierarchical alignment. It's about maintaining coherence while acknowledging that different parts of your organisation might need to make decisions at different levels.
Get this wrong, and you have either chaos or suffocating centralisation. Get this right, and teams have both autonomy and alignment.
Finding the natural fracture points in your Decision Stack? That's a strategy that scales.