near you: 1. Who are you? 2. When it comes to strategy setting are you: • A tourist - new to it, here to explore • A regular visitor - some experience, still figuring things out • A tour guide - done it a few times, could probably show others around? 5 minutes
near you: 1. Who are you? 2. When it comes to strategy setting are you: • A tourist - new to it, here to explore • A regular visitor - some experience, still figuring things out • A tour guide - done it a few times, could probably show others around? 5 minutes time’s up! … minute remaining minutes remaining 1 2 3 4 5 -
the bedrock of your strategy and should encapsulate the challenge precisely. Guiding Principles Policies that shape every decision. These are the active constraints that you have to work within. They should guide your approach to how to solve the diagnosis. Coherent Actions Actions you will actually take to solve the diagnosed problem. These should be concrete, have owners, timeframes and people committed to them. Rumelt’s Strategy Kernel
creative agencies • 8 years old, 2,000 paying customers • Mostly small and mid-sized agencies, a few larger ones • Engineering team of 40 • Monolith with a React front-end, deploys twice a week • Good uptime but occasional slow page loads on larger accounts • Two competitors: one winning on enterprise features and compliance, one winning on speed of new feature delivery
subscribers • 1 apps team, 12 web teams • Web app with native wrappers for Android and iOS • Features often appear on web first, then on the app • App is a 15 years old codebase with lots of tech debt and legacy • Only the apps team can work on the app • App is where the highest B2C subscriber engagement is - with B2B engagement also climbing. AcmeNews Factsheet
the business’s future growth comes from, they are where their most engaged customers are, but the engineering team can’t ship work in them quickly enough to keep up with customer expectations. Our starting point:
the app is highly complex — the architecture, the patterns, the interdependencies — and that complexity has grown over time without being addressed. Why #3
app because changes require deep support from the central apps team. The mobile app is very complex, and hard for contributing teams to understand. Simplifying it has never been prioritised.
the app because changes require deep support from the central apps team. The mobile app is very complex, and hard for contributing teams to understand. Simplifying it has never been prioritised.
slow on the app because changes require deep support from the central Apps team. The mobile app is very complex, and hard for contributing teams to understand. Simplifying it has never been prioritised. Delivery is slow on the app because changes require deep support from the central Apps team. ++This dependency exists because the app is structured in a way that prevents autonomous contributions. Simplifying it has never been prioritised.
on the app because changes require deep support from the central Apps team. This dependency exists because the app is structured in a way that prevents autonomous contributions. Simplifying it has never been prioritised. ++…because the maintaining team had enough internal knowledge to work efficiently despite it.
no longer fits our growing organisation with multiple contributing teams. ++ Failure to address this has resulted in delivery bottlenecks and coordination overheads, limiting our ability to ship features rapidly, respond to user needs, and compete on product experience. Delivery is slow on the app because changes require deep support from the central Apps team. This dependency exists because the app is structured in a way that prevents autonomous contributions. Simplifying it has never been prioritised because the maintaining team had enough internal knowledge to work efficiently despite it.
because changes require deep support from the central Apps team. This dependency exists because the app is structured in a way that prevents autonomous contributions. Simplifying it has never been prioritised because the maintaining team had enough internal knowledge to work ef fi ciently despite it…. IN SCOPE: • Restructure the app so multiple teams can contribute • Invest in platform work that enables autonomous contribution • Modularise the codebase along team boundaries • Change the ownership model OUT OF SCOPE: • Hire more people into the Apps team • Rewrite the app from scratch • Process improvements without architectural change • Speed up the Apps team
mobile app architecture to unlock innovation and accelerate our path to becoming a mobile-first organisation.” Doesn’t name what’s actually wrong “Modernise” could mean anything “Unlock innovation” is a vague Not falsifiable Could be the diagnosis for any company
app because changes require deep support from the central Apps team. This dependency exists because the app is structured in a way that prevents autonomous contributions. Simplifying it has never been prioritised because the maintaining team had enough internal knowledge to work efficiently despite it. This structure no longer fits our growing organisation with multiple contributing teams. Failure to address this has resulted in delivery bottlenecks and coordination overheads, limiting our ability to ship features rapidly, respond to user needs, and compete on product experience.
deep support from the central Apps team. This dependency exists because the app is structured in a way that prevents autonomous contributions. Simplifying it has never been prioritised because the maintaining team had enough internal knowledge to work efficiently despite it. This structure no longer fits our growing organisation with multiple contributing teams. Failure to address this has resulted in delivery bottlenecks and coordination overheads, limiting our ability to ship features rapidly, respond to user needs, and compete on product experience.”
on the app because changes require deep support from the central Apps team. This dependency exists because the app is structured in a way that prevents autonomous contributions. Simplifying it has never been prioritised because the maintaining team had enough internal knowledge to work efficiently despite it. This structure no longer fits our growing organisation with multiple contributing teams. Failure to address this has resulted in delivery bottlenecks and coordination overheads, limiting our ability to ship features rapidly, respond to user needs, and compete on product experience.”
(8 mins solo) Sketch a diagnosis for your problem • (7 minutes 2-3 people) Share your diagnosis sketch and what you still need to improve about it. time’s up! … minute remaining minutes remaining 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 -
from your diagnosis 2. They should clarify what not to do 3. They should be concrete enough to help someone make a decision 4. They should be consistent with one another
named owning team 2. Contributing teams should be able to merge to their part without central review 3. The Apps team exists to enable contributors, not to be a gatekeeper Diagnosis Contributing teams can’t make app changes independently because the codebase has no clear module ownership — every change requires the central Apps team to get involved. 1. Your principles should stem from your diagnosis
contributing teams with new feature delivery No Yes We will not take on new feature work that increases central team dependency, even when the feature is valuable. 2. Guiding principles should clarify what not to do
Prioritise improvements to our CI/CD pipeline, especially where workflows require frequent manual intervention, or block independent team delivery. 3. Guiding principles should be concrete enough to help someone make a decision
Yes 1. Every app release must maintain 100% stability and zero regressions. 2. Prioritise rapid iteration and experimentation in the app. No Yes 1. Every app release must maintain 100% stability and zero regressions. 2. Invest in robust automated testing and release validation pipelines.
stem from your diagnosis 2. They should clarify what not to do 3. They should be concrete enough to help someone make a decision 4. They should be consistent with one another
minutes Examples 1. Every part of the codebase has a named owning team 2.Contributing teams should be able to merge to their part without central review 3.The Apps team exists to enable contributors, not to be a gatekeeper
minutes Examples 1. Every part of the codebase has a named owning team 2.Contributing teams should be able to merge to their part without central review 3.The Apps team exists to enable contributors, not to be a gatekeeper time’s up! … minute remaining minutes remaining 1 2 3 4 5 6 7 -
other, not be an unrelated list They should centre people/money on the same focal point They should be derived from the guiding policy. If actions “make sense on their own” they are just good ideas - not strategically coherent.
single team owns the whole codebase [etc] Guiding Principle #1 Decentralise App ownership by assigning domain aligned teams clear responsibility for specific modules to reduce delivery bottlenecks
single team owns the whole codebase [etc] Guiding Principle #1 Coherent Actions Decentralise App ownership by assigning domain aligned teams clear responsibility for specific modules to reduce delivery bottlenecks • Map the monolith to domains and assign named owning teams • Establish a platform team to abstract shared infrastructure, so domain teams can contribute without deep App knowledge • Establish an enablement team to build the capability of domain teams to own and ship independently
✓They’re specific and actionable ✓They work together ✓They address root causes, not symptoms ✓They show strategic investment ✓Are achievable in a meaningful timeframe • Map the monolith to domains and assign named owning teams • Establish a platform team to abstract shared infrastructure, so domain teams can contribute without deep App knowledge • Establish an enablement team to build the capability of domain teams to own and ship independently
accomplish that meaningfully advances your strategy. Helps your teams focus on something concrete and achievable, rather than struggling to see how they can contribute to a wider strategic objective. Needs to be at the edge of your current capabilities.
feature end-to-end without touching the central team's backlog. It’s proximate because it’s the first meaningful signal that the strategy is progressing. At the current point in time, this proximate goal is simply not possible. Once you have achieved your proximate objective - set the next one!
Guiding Principle 1 Example actions: • Map the monolith to domains and assign named owning teams • Establish a platform team to abstract shared infrastructure, so domain teams can contribute without deep App knowledge • Establish an enablement team to build the capability of domain teams to own and ship independently
Guiding Principle 1 time’s up! … minute remaining minutes remaining 1 2 3 4 5 6 7 Example actions: • Map the monolith to domains and assign named owning teams • Establish a platform team to abstract shared infrastructure, so domain teams can contribute without deep App knowledge • Establish an enablement team to build the capability of domain teams to own and ship independently -
the bedrock of your strategy and should encapsulate the challenge precisely. Guiding Principles Policies that shape every decision. These are the active constraints that you have to work within. They should guide your approach to how to solve the diagnosis. Coherent Actions Actions you will actually take to solve the diagnosed problem. These should be concrete, have owners, timeframes and people committed to them. Rumelt’s Strategy Kernel
whole table, take it in turns to run through your kernel sketch. • Do not give feedback, just listen and think about what you can learn from how the rest of your table has approached their challenge.
whole table, take it in turns to run through your kernel sketch. • Do not give feedback - your job is to think about what you can learn from them, not help them improve. time’s up! … minute remaining minutes remaining 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 -
outsource the listening. You cannot outsource the relationship building. But you can use LLMs as thinking partner. And you can use them to challenge your diagnosis, principles and actions.
Difference and Why it Matters. Richard Rumelt • Peter M. Senge, The Fifth Discipline: The Art & Practice of The Learning Organization. • Playing to Win: Roger Martin
alicebartlett
denniskardys
3n
inesmontani
addyosmani
khoart
aleyda
honzajavorek
rmw
samanthasiow
schlessera
thirion
