Strategy workshop from LDX3 Director+

This is an hour workshop aimed at technology leaders who want to bring a technology strategy to life.

Transcript

1. Alice Bartlett, Tech Director @ Financial Times June 2025 For Director+ De fi ning your engineering strategy
2. Technical Director at the Financial Times I lead the FT.com and Apps teams I work with the CTO and other directors at the Financial Times to set and execute the FT’s technical strategy I’m Alice Bartlett
3. WHY ARE YOU HERE?
4. You could be reading a book about strategy
5. Or reading about it on LinkedIn
6. The value is in this room, with your peers
7. PLEASE GIVE GENEROUSLY
8. Let’s break some ice
9. Activity: Icebreaker 5 minutes Share with your table-mates what has brought you to this workshop. Is there something you particularly need help with? A challenge you have with creating an engineering strategy that you want help with? Maybe you’ve got the beginnings of a strategy and you want some feedback on it? Have you tried to bring in a technical strategy before but it’s stalled or not worked?
10. Strategy - Diagnosis - Guiding Principles - Concrete Actions
11. Strategy
12. “A good strategy honestly acknowledges the challenges being faced and provides an approach to overcoming them.” — Richard Rumelt
13. These are (some) universal system truths Tech debt Reliability and uptime Scalability bottlenecks Legacy systems Conway’s law Running cost [and so on…]
14. The work of the tech strategy is to fi nd out which universal system truths are going to fuck up your business strategy
15. Universal truth: Tech Debt Current problem: Tech debt is slowing down delivery because teams are spending a signi fi cant amount of time navigating around outdated code Business strategy: Di ff erentiate through new features delivered and iterated rapidly
16. Universal truth: Reliability and uptime Current problem: During peak times, we have reliability issues for our customers. Business strategy: Target enterprise customers - who demand strong SLAs and expect reliability as standard.
17. Your technology strategy should be enabling the business to achieve its goals This is so obvious but…
18. Right — let’s get ready to Rumelt
19. Rumelt’s strategy kernel 1. Diagnosis of the problem 2. Principles for solving the problem 3. Concrete Actions
20. The anatomy of a strategy AKA the “kernel” Diagnosis Action Action Action Action Action Action Action Action Action Action Action Action Action Action Action Action Action Action Principle Principle Principle Principle Principle Principle
21. Diagnosis
22. The diagnosis identi fi es the core challenge facing the organisation.
23. A real life problem Delivery is slow in the app :’(
24. Symptom Delivery is slow in the app :’( Symptom Symptom … Why #1 Symptom … Why #2 Symptom … Why #3 Symptom … Why #4 Symptom Delivery is 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. Why #5 5 Why’s
25. Our rough diagnosis Delivery is 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.
26. Properties of a good diagnosis: 1. It identi fi es the critical issue 2. It explains how we got here 3. It answers “why” and “why now?” 4. It creates direction 5. It avoids wishful thinking
27. 1. It identi fi es the critical issue A good diagnosis should clearly point to the single most important constraint, blocker or threat.
28. 1. It identi fi es the critical issue Delivery is 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.
29. 2. It explains how we got here A good diagnosis should show how the problem came to be, and why
30. 2. It explains how we got here 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 e ffi ciently despite it.
31. Your diagnosis should link to the business impact of the problem, and it should show why it is important to fi x the problem now by showing what has changed 3. It answers “why” and “why now?”
32. 3. It answers “why” and “why now?” ++ This structure no longer fi ts 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 e ffi ciently despite it.
33. 4. It creates direction A good diagnosis should frame the problem in a way that strongly implies where you should go next
34. 4. It creates direction 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 e ff i ciently despite it. This structure no longer fi ts 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.
35. 5. It avoids wishful thinking A good diagnosis should be grounded in reality, not optimism.
36. 5. It avoids wishful thinking 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 e ff i ciently despite it. This structure no longer fi ts 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.
37. Ask: Is this diagnosis falsifiable?
38. Your diagnosis should be speci fi c enough to guide actions and be proven wrong
39. A fuzzy unfalsi fi able diagnosis will lead to a bad strategy “Our architecture needs improvements to help us to innovate at scale.”
40. Instead: 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 e ffi ciently despite it. This structure no longer fi ts 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.
41. A good diagnosis should invite disagreement
42. Remember: 1. It identi fi es the critical issue 2. It explains how we got here 3. It answers “why” and “why now?” 4. It creates direction 5. It avoids wishful thinking Activity: Sketch and share your diagnosis 10 minutes Task • (5 mins solo) Sketch a diagnosis for your problem • (5 minutes small group) Share your thoughts on your diagnosis, what you still need to improve about it, with a couple of people at your table
43. 2. Guiding principles
44. Guiding principles de fi ne an overall approach chosen to cope with or overcome the obstacles identi fi ed in the diagnosis.
45. Tips for a good guiding principles 1. Anchor principles directly to the 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
46. Diagnosis: Our teams are siloed and keep duplicating work rather than reusing existing software Guiding principles: • Favour existing platforms over bespoke solutions. • Build new systems for re- use or extensibility. • Ensure existing systems are easy to contribute to. 1. Your principles should stem from your diagnosis
47. Help people say no to attractive but misaligned options 2. Guiding principles should clarify what not to do
48. We will balance reliability improvements and innovation to drive success. No Yes We will prioritise reliability improvements over adding new features until we reduce incidents by 80% 2. Guiding principles should clarify what not to do
49. 3. Guiding principles should be concrete enough to help someone make a decision If your principles are too abstract, people won’t know how to apply them
50. No Yes Focus on improving our CI/CD pipeline. No Yes Prioritise improvements to our CI/CD pipeline, especially where work fl ows require frequent manual intervention, or block independent team delivery 3. Guiding principles should be concrete enough to help someone make a decision
51. 4. Guiding principles should be consistent with one another No 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.
52. Tips for a good guiding principles 1. Anchor principles directly to the 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
53. 3. Concrete actions A coordinated set of steps to carry out the guiding principles
54. Shipping features to the App is slow because a single team owns the whole codebase [etc] Diagnosis
55. Shipping features to the App is slow because a single team owns the whole codebase [etc] Decentralise App ownership by assigning domain aligned teams clear responsibility for speci fi c modules to reduce delivery bottlenecks and improve code quality Diagnosis Guiding Principle 1
56. Shipping features to the App is slow because a single team owns the whole codebase [etc] Decentralise App ownership by assigning domain aligned teams clear responsibility for speci fi c modules to reduce delivery bottlenecks and improve code quality Diagnosis Guiding Principle 1 • Map out areas of the monolith to logical domains and identify ownership gaps • Agree and assign speci fi c code ownership for each module • Establish an Apps platform team and an Apps enablement team to support the work of the teams who have taken on parts of the monolith Concrete Actions
57. Reasons these are good: • They’re aligned to the guiding policy • They’re speci fi c and actionable • They work together • They address root causes, not symptoms • They show strategic investment • Are achievable in a meaningful timeframe • Map out areas of the monolith to logical domains and identify ownership gaps • Agree and assign speci fi c code ownership for each module • Establish an Apps platform team and an Apps enablement team to support the work of the teams who have taken on parts of the monolith Concrete Actions
58. Solo activity: Write a guiding principle and some actions 5 minutes Decentralise App ownership by assigning domain aligned teams clear responsibility for speci fi c modules to reduce delivery bottlenecks and improve code quality • Map out areas of the monolith to logical domains and identify ownership gaps • Agree and assign speci fi c code ownership for each module • Update operational processes to re fl ect ownership • Establish an Apps platform team and an Apps enablement team to support the work of the teams who have taken on parts of the monolith Concrete Actions Guiding Principle 1
59. Kernel conclusion
60. What is a kernel? Diagnosis - The identi fi cation and framing of the critical challenge Principles - The general approach for overcoming the diagnosed challenge, o ff ering coherent direction. Concrete actions - coordinated steps designed to carry out the guiding principles. O ff ering focussed practical implementation.
61. You should now have some rough ideas for each of these bits Diagnosis Action Action Action Action Action Action Action Action Action Action Action Action Action Action Action Action Action Action Principle Principle Principle Principle Principle Principle
62. Table Activity: Run through your kernel 10 minutes • For the 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. Share your: • Diagnosis • Principles • Actions
63. ChatGPT for strategists • You are a strategy consultant familiar with Richard Rumelt’s work. Please evaluate the following technical strategy using his framework — especially focusing on whether it has: • A clear and insightful diagnosis of the problem • A well-de fi ned guiding policy that helps people make decisions • Coherent actions that reinforce each other and follow logically from the policy
64. None of this is rocket science
65. Writing a strategy is about taking a clear eyed look at your problems and cutting through the noise enough to fi x them
66. “A strategy that makes you comfortable is probably not a real strategy.” Roger Martin — Playing to win
67. Further reading on strategy • Good Strategy Bad Strategy: The Di ff erence and Why it Matters. Richard Rumelt • Peter M. Senge, The Fifth Discipline: The Art & Practice of The Learning Organization. • Playing to Win: Roger Martin