The model was originally proposed by Mckinsey as the "3 horizons of growth" to help business leaders honing their analysis of where and how to compete, grow, and best manage their organizations.
In this talk I put to the audience the model could be applied to Technology businesses, and I attempt to draw the members present into a discussion on its application to people & teams as well as architecture or tech strategy.
I also outline a few activities that can provide data points for consideration and focus the attention of people as part of the model.
All this comes with the disclaimer "all models are incorrect some are useful". I look forward to hearing your feedback.
https://www.meetup.com/CTO-School-Melbourne/events/235165561/
19. The Product side
Extend and defend
core business
Build emerging
businesses
Create viable
options
20. Experienced business operators
extend the core
Business builders develop
new opportunities
Visionaries, champions
create viable options
The People side
21. Transitional Architecture
modernizes the core
Evolutionary Architecture
guides growth with opportunities
Emergent Architecture
based on disruptive tech
The Technology side
23. Extend and defend core business
Horizon 1
Transitional Architecture modernizes the core
Experienced business operators extend the core
24. We rely on experienced technical leaders who possess:
• A track record and love for working effectively with
legacy code
• The ability refactor as you go along and be disciplined
• The ability to strangle systems along functionality seams
• The explainers. The patient. The calm and steady.
People
25. Transitional Architectures aiming for
SOA/Microservices as a strangler and for complexity management
Automated operations and effective team level support/on-call
New tech as a way of solving problems of scale: AWS, Docker etc.
New tech as a way of decoupling, managing blast radius
Focus on Inter-operability
Established pattern based decision making
26. Tech Radar as a Reflection Exercise
Activity
Get technologists
in a room.
Ask them to reflect on
Techniques, Tools,
Platforms and Languages
in use.
Classify these as
Assess, Trial,
Adopt or Hold.
27. TIME modeling with Leadership
Activity
Sit with your leadership
team
Ask them to review
products and systems using
Gartner’s TIME model.
Classify each into one of the
four quadrants
Use the results as an
input to decision making
28. STARS modeling with Leadership.
Activity
Sit with your leadership
teams
Ask them to assess their
products and the teams
working on them
Classify each as Start-Up,
Turnaround, Accelerated
Growth, Realignment or
Sustaining Success
Reflect on the implications
31. Build emerging businesses
Horizon 2
Business builders develop new opportunities
Evolutionary Architecture guides growth with opportunities
32. We rely on Product engineers. Characterized by:
• Enthusiasm and passion. Evangelists.
• A Strong sense of optimism
• Comfort with working in higher degrees of uncertainty
• Comfortable with trading tech debt for speed, and the
experience doing it.
• Knowledge of the second system effects
• Ability to think on their feet, adapt fast, and thrive while
under delivery pressure.
People
33. Evolutionary Architectures guided by :
Composibility of existing services to extend/create new products
Add new services to expose new capabilities/data
Invest in older software assets only where required
New tech as a way of attracting and retaining talent
New tech as a way of achieving shortened time to market
Optimize for code for flexibility not efficiency
Focus on Inter-operability
34. FFF Exercise with Teams on a regular basis
Activity
To help teams keep their
focus on the things that
are important.
Use the FFF for non
functional requirements
Have teams determine
The dimensions
35. Trade off sliders with Teams on a regular basis
Activity
To help teams keep
their focus on the
things that are
important.
To help keep product
and technology
teams honest.
36. Tech Debt walls mapping
Activity
Technical teams get uncomfortable with borrowing down on tech debt.
Visibility helps deal with managing the debt versus productivity scales
39. We rely on Entrepreneurial engineers. Characterized by:
• Self driven. Champions and visionaries.
• Comfort with working with a lack of clarity
• Comfortable with building quick and dirty solutions
• Comfortable with throwing work away as products
develop and pivot.
• Ability to learn fast without a lot of formal support
• The courage to be different.
People
40. Emergent Architectures characterized by :
Operating outside the boundaries of established systems
New tech as a market disruptor
New tech as a commercially defensible IP
Optimized for learning
Mandates the need for re-investment later
43. Experienced business operators
extend the core
Business builders develop
new opportunities
Visionaries, champions
create viable options
Culture evolution
47. Discussion notes
Wardley maps: (Matt Fellows and Ervin Van der Koogh)
http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html?m=1
and https://vimeo.com/189984496
Is there a Horizon 0 – the people and tech left behind after an organization has
moved on, post the evolution from horizon 1 -> 2. What does that look like?
(Liz Douglass – has upcoming talk at YOW CTO summit on this)
The 3 horizons model as applied to features and code flows within an application. 3
horizons of features, core feature set, potential high adoption/value-
add/differentiator features, and long shots? How would you engineer these given this
view? Would you put more rigour around networks and error case handling for
horizon 1 versus 3 for example?
(Oliver Jones)
Crossing the chasm & related HBR article : https://hbr.org/2007/07/to-succeed-in-
the-long-term-focus-on-the-middle-term (Nish Mohanty and others)
Notes de l'éditeur
Maybe help you explain whether micro-services could work for you.
Agreement on the axioms. Suspend objection for the duration of this presentation.
Because people without technology is not useful for a tech company
Because technology without people is not useful for a tech company
Good architectures support and are driven by the needs of our business. Bad architectures require our business to change. What is easy to change in your business model should be easy to change in your architecture.
Model disclaimer.
Because assassins are good at execution.
Value creation: Superior execution.
Businesses we’re trying to run better than anyone else and at the same time defend our core business
Metrics: Performance focus. Profit, cash flow, roi etc.
A track record and love for working effectively with legacy code
A special kind of mind set. People here know how to dive into the middle of a code base and work their way into affected regions. The strategies they use for feature development and managing debt is quite different. Level of comfort with tools like Structure 101, Cyclomatic complexity etc.
The ability refactor as you go along and be disciplined
The dark forest analogy. The system heat map. Comprehending the rate of change in the system. The story of the system rewrite.
The ability to strangle systems along functionality seams
Hidden seams in a system. The bus, the system integration points, the ui, the back office process etc.
The explainers.
Deep domain context. Onboarding new members, keeping innovation alive with new thinking while managing the complexity of big/old systems. Explaining Feature complexity.
Transitional Architectures aiming for
Microservices as a strangler and for complexity management
Automated operations and effective Support
New tech as a way of solving problems of scale: AWS, Docker,
New tech as a way of decoupling, managing blast radius
Focus on Inter-operability
Established pattern based decision making
CloudWatch & Splunk & fan out. Central functions and team operations
Statsd for metrics
Docker in Docker or Docker alongside docker, or docker with friend called docker or docker mania
Secrets sucks for everyone. Encrypted repos. LastPass as a service. Vault & leases.
Source of value creation: taking advantage of new opportunity.
Trying to gain a significantly better position relative to your competitors.
Much of the value in a company comes from relatively small business here. Market wants this.
Metrics: Revenue growth, NPV
We rely on Product engineers. Characterized by:
Enthusiasm and passion. Evangelists.
A Strong sense of optimism
Comfort with working in higher degrees of uncertainty
Comfortable with trading tech debt for speed, and the experience doing it.
Knowledge of the second system effects
Ability to think on their feet, adapt fast, and thrive while under delivery pressure.
Evolutionary Architectures guided by :
Composibility of existing services to extend/create new products
Add new services to expose new capabilities/data
Invest in older software assets only where required
New tech as a way of attracting and retaining talent
New tech as a way of achieving shortened time to market
Optimize for code for flexibility not efficiency
Focus on Inter-operability
Activities: Fitness Functions
“The relative effort that the team would have to spend in order to pay this debt.“
“Pain is the direct impact on productivity that this debt causes. (interest)”
Keep paying down the principal, not only the interest
Value creation: Potential value. Little experiments. Clustered experiments rather than a VC model. Clustered around themes.
A focus on insights and foresight on the target market space.
We rely on Entrepreneurial engineers. Characterized by:
Self driven. Champions and visionaries.
Comfort with working with a lack of clarity
Comfortable with building quick and dirty solutions
Comfortable with throwing work away as products develop and pivot.
Ability to learn fast without a lot of formal support
The courage to be different.
Emergent Architectures characterized by :
-> operating outside the boundaries of established systems
-> new tech as a market disruptor – VR,
-> new tech as a commercially defensible IP – machine learning, neural networks, recommendation algos etc.
-> optimized for learning
-> mandates the need for re-investment later
The cultural norms and the behaviors of the teams, tech and products in the horizons 2, move into the core and become the new normal.
Same for 3 to 2
Note the data on Cities versus Companies .
Consider: Closed systems versus open systems.
Traditional view of the company or organization is a closed system. i.e Machine that must be managed to avoid collapse.
Cities on the other hand are Open systems. Complex adaptive systems. Like an organism instead of a machine. Exchanging, reacting and evolving constantly with its environment.
Consider: what happens if we view the modern agile technology company as a complex adaptive system, an organism rather than a machine?
Complex Adaptive systems are a special class of open systems characterized by dynamic networks of agents interacting with each other and their environment. They are continuously evolving and shifting (ant colonies, bee hives, stock markets, political parties, biological ecosystems etc). Interestingly enough, the behavior of the whole cannot be predicted by analyzing parts in isolation.
Cities seem to be able to organize themselves to get things done without central planners and managers. Yes they do have planners and managers, but they do not try to control the activities in the city the way some managers might try to do in a company. What they do is manage the support systems, the infrastructure and essential services..instead of trying to direct the activity of each citizen. i.e. They manage for productivity instead of managing against collapse.