Quick Navigation
- Start here — Why the future operating model must be designed
- How technology organisations are changing
- The AI-augmented technology function
- Platform-based operating models
- The evolving role of architecture
- Skills and capabilities
- Governance in a future operating model
- Designing the transition
- AI and workforce composition
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
AI and automation are changing what humans in technology organisations need to do. Platform thinking shifts funding and governance models — from projects to products. The role of the architect is evolving — from designer to strategist and governor. Organisations designed for yesterday's technology will struggle to operate tomorrow's. I've seen 500-person technology organisations structured for 2020 — projects, manual operations, centralised decisions — trying to operate AI-native systems. It doesn't work.
The future operating model must be designed, not drifted into — AI changes everything about how technology organisations work.
This isn't speculation. In 2026, AI handles routine coding, testing, and monitoring. Platform teams provide self-service infrastructure. Architects shift from designing systems to governing ecosystems. The organisations that design for these conditions will thrive. The organisations that drift will find their structures obsolete.
Keep it in mind.
1. Why the future operating model must be designed — The forces reshaping technology organisations
Technology organisations are structured for a world that no longer exists. Project-based funding, manual operations, centralised decision-making, and vendor management were designed for slower rates of change. Four forces are making these structures obsolete simultaneously.
Four forces are reshaping every operating model:
flowchart TD
FORCES["🌊 Four Forces"] --> AI_F["🤖 AI & Automation\nRoutine work automated\nWhat humans do changes"]
FORCES --> PLAT_F["📦 Platform Thinking\nSelf-service foundations\nHow teams are structured changes"]
FORCES --> PROD_F["🎯 Product Models\nContinuous funding\nHow teams are funded changes"]
FORCES --> ECO_F["🌐 Ecosystem Participation\nExternal capabilities\nHow organisations relate changes"]
AI_F --> SHIFT["✅ Operating Model Shift\nDesigned, not drifted into"]
PLAT_F --> SHIFT
PROD_F --> SHIFT
ECO_F --> SHIFT
The shift — from what to what:
| From | To |
|---|---|
| Humans do all work | AI handles routine; humans handle judgement |
| Teams build everything | Platforms provide foundation; teams build on top |
| Project-based funding | Product-based continuous funding |
| Vendor management | Ecosystem participation |
Each force requires specific responses: AI needs role redesign; platforms need self-service teams; products need continuous funding; ecosystems need integration capability. These four forces are interdependent — AI without platforms has no leverage, platforms without product funding fail to sustain, and all four without ecosystem thinking miss external innovation.
Four forces — AI, platforms, products, ecosystems — are reshaping every operating model.
Try it yourself — The force assessment
Which of these four forces is actively reshaping your organisation?
| Force | Evidence | Response |
|---|---|---|
| AI & Automation | ||
| Platform Thinking | ||
| Product Models | ||
| Ecosystem Participation |
If you can't name evidence for two or more, you're not responding to the forces. You're drifting.
2. The AI-augmented technology function — What changes when AI handles routine work
Most technology organisations still assume humans do all work — all coding, all testing, all monitoring, all documentation. AI now handles routine versions of these tasks. If roles aren't redesigned, humans are doing work AI could do, or worse, competing with AI instead of complementing it.
AI changes every activity, not by replacing humans, but by changing what humans focus on:
flowchart TD
ACTIVITIES["🤖 Activities"] --> CODING["💻 Coding\nAI generates code\nHumans review & design"]
ACTIVITIES --> TESTING["🧪 Testing\nAI generates tests\nHumans define requirements"]
ACTIVITIES --> MONITORING["📊 Monitoring\nAI detects anomalies\nHumans investigate"]
ACTIVITIES --> DOCS["📝 Documentation\nAI generates docs\nHumans verify"]
ACTIVITIES --> ARCH["🏗️ Architecture\nAI suggests patterns\nHumans decide & govern"]
CODING --> HUMANS["✅ Humans Focus On\nJudgement · Design\nGovernance · Ethics"]
TESTING --> HUMANS
MONITORING --> HUMANS
DOCS --> HUMANS
ARCH --> HUMANS
What humans still do — and will do more of:
| Activity | Why AI can't do it |
|---|---|
| Judgement | Decisions with incomplete information, ambiguity, trade-offs |
| Design | Defining what to build and why — intent, not implementation |
| Governance | Setting constraints, reviewing outcomes, ethical oversight |
| Communication | Translating between technical and business worlds |
| Ethics | Value-based decisions AI can't make |
The human-AI collaboration levels: L1 Assist — AI suggests, human decides (e.g., code suggestions). L2 Automate — AI does routine, human handles exceptions (e.g., automated testing). L3 Collaborate — AI generates options, human evaluates (e.g., design alternatives). L4 Govern — AI operates independently, human sets constraints (e.g., infrastructure management).
AI handles routine; humans handle judgement, design, governance, and ethics.
Try it yourself — The AI audit
What activities in your organisation is AI currently handling?
| Activity | AI level (L1-L4) | Human focus shifted to |
|---|---|---|
| e.g. Code generation | L2 — AI generates, humans review | Design, architecture, complex logic |
If you're still at L1 for most activities, you're not augmenting — you're experimenting.
3. Platform-based operating models — How shared platforms reshape team structures
Without platforms, every team builds its own CI/CD, monitoring, deployment, and infrastructure. At scale, this duplication becomes unsustainable — inconsistent, slow, and expensive. Platforms eliminate duplication, but they also reshape how teams are structured and what they own.
Platforms create a clear division of responsibility:
flowchart TD
BEFORE["❌ Before Platforms"] --> B1["Every team builds own CI/CD"]
BEFORE --> B2["Every team configures monitoring"]
BEFORE --> B3["Every team manages infrastructure"]
BEFORE --> B4["Teams spend 30% on infrastructure"]
AFTER["✅ With Platforms"] --> A1["Platform team provides CI/CD"]
AFTER --> A2["Platform team provides observability"]
AFTER --> A3["Platform team provides self-service infra"]
AFTER --> A4["Teams spend 5% — rest on features"]
BEFORE --> RESULT["Result: Duplication\nInconsistency · Slowness"]
AFTER --> RESULT_OK["Result: Velocity\nConsistency · Focus"]
Team structure shift:
| Team type | Before platforms | After platforms |
|---|---|---|
| Feature teams | Build features + infrastructure | Build features on platform |
| Platform teams | Don't exist | Provide shared foundation |
| Enabling teams | Don't exist | Help teams adopt capabilities |
| Architecture teams | Design all systems | Govern ecosystem; design strategically |
The platform operating model checklist: Platform teams funded continuously, measured by adoption. Feature teams consume platform without asking permission. Enabling teams help teams adopt — not do work for them. Architecture teams govern — not design every system. Clear boundaries between platform and team responsibilities.
Platforms shift teams from building foundations to building features — restructuring follows.
Try it yourself — The platform check
What percentage of team time is spent on infrastructure vs features?
| Team | Infrastructure % | Feature % | Could platform reduce infra? |
|---|---|---|---|
If infrastructure is over 20%, you need a platform team.
4. The evolving role of architecture — From design authority to strategic governance
If architects keep designing every system, reviewing every decision, and creating every diagram, they become the bottleneck. AI can suggest patterns, platforms provide foundations, and teams are empowered to decide. The architect must evolve — or become irrelevant.
The architect's role shifts from control to influence:
flowchart TD
BEFORE_A["❌ Before"] --> B_DESIGN["Design every system"]
BEFORE_A --> B_REVIEW["Review every decision"]
BEFORE_A --> B_DIAGRAM["Create diagrams"]
BEFORE_A --> B_CONTROL["Control"]
AFTER_A["✅ After"] --> A_GOVERN["Govern the ecosystem"]
AFTER_A --> A_STRATEGY["Set strategy and direction"]
AFTER_A --> A_PRINCIPLES["Set principles; teams decide"]
AFTER_A --> A_INFLUENCE["Influence"]
BEFORE_A --> RESULT_A["Result: Bottleneck\nSlow decisions\nArchitect resentment"]
AFTER_A --> RESULT_OK_A["Result: Strategic impact\nFast decisions\nArchitect value"]
The architect of the future — five roles:
| Role | What it means |
|---|---|
| Strategist | Defines direction, not just design |
| Governor | Sets guardrails, not gates |
| Communicator | Translates between business and technology |
| Ethicist | Makes value-based decisions AI can't |
| Influencer | Shapes decisions without authority |
The evolution moves through stages: today architects design and review; near future they govern and set principles while AI suggests patterns; future they focus on strategic direction and ethical oversight while AI designs routine systems. Governance mechanisms shift from manual review to fitness functions, strategic reviews, and ethical frameworks.
Architects evolve from designer to strategist and governor — AI handles design; humans handle judgement.
Try it yourself — The role check
What does your architecture team spend most of their time on?
| Activity | % of time | Should it be? |
|---|---|---|
| Designing systems | Should decrease | |
| Reviewing decisions | Should decrease | |
| Setting strategy | Should increase | |
| Governing ecosystem | Should increase |
If design and review are over 50%, you're the bottleneck.
5. Skills and capabilities — What the technology organisation of the future needs
If the organisation invests in AI, platforms, and new team structures but the workforce still has the skills of 2020, the transformation fails. Skills must lead structural change — not follow it. Organisations that upskill after restructuring are already too late.
A clear split emerges between skills that increase and decrease in value:
flowchart TD
SKILLS["🎓 Skills Shift"] --> UP["📈 Increase in Value"]
SKILLS --> DOWN["📉 Decrease in Value"]
UP --> JUDGEMENT["Judgement &\nDecision-making"]
UP --> DESIGN_S["System Design &\nArchitecture"]
UP --> COMMS["Communication &\nInfluence"]
UP --> GOVERN_S["Governance &\nRisk Management"]
UP --> CREATIVE["Creative\nProblem-solving"]
DOWN --> ROUTINE["Routine Coding\nAI does it"]
DOWN --> MANUAL_T["Manual Testing\nAI does it"]
DOWN --> MANUAL_O["Manual Operations\nAutomation does it"]
DOWN --> MEMORY["Memorising Details\nAI provides them"]
Skills the future organisation needs:
| Skill | Why it matters |
|---|---|
| AI literacy | Understanding what AI can and cannot do |
| Systems thinking | Seeing relationships and consequences |
| Communication | Translating between technical and business |
| Governance | Designing and operating control systems |
| Data thinking | Understanding data as an asset |
| Ethical reasoning | Making value-based decisions |
| Adaptability | Learning continuously as technology shifts |
Invest heavily in AI literacy, systems thinking, and governance. Moderately invest in communication, data thinking, and ethical reasoning. Maintain domain expertise through communities of practice. Retire routine coding and manual testing skills by transitioning to AI and reskilling practitioners.
Judgement, design, communication, governance, and ethics — the skills AI can't replace.
Try it yourself — The skills gap
Rate your team's current skills:
| Skill | Current level (1-5) | Target level | Gap action |
|---|---|---|---|
| AI literacy | |||
| Systems thinking | |||
| Communication | |||
| Governance | |||
| Ethical reasoning |
Any skill below 3 needs investment. Don't wait for restructuring to start.
6. Governance in a future operating model — How oversight adapts as systems become autonomous
Traditional governance assumes humans review every decision. When AI makes routine decisions and platforms enforce standards automatically, reviewing everything becomes impossible — and unnecessary. Governance must shift from reviewing decisions to setting constraints and monitoring outcomes.
Governance adapts across every concern:
flowchart TD
GOVERN["⚖️ Governance Shift"] --> DECISION["🎯 Decision Review\nAI makes routine decisions\nHumans review exceptions"]
GOVERN --> COMPLIANCE["✅ Compliance\nAutomated fitness functions\nNot manual audits"]
GOVERN --> RISK["⚠️ Risk Management\nContinuous AI monitoring\nNot periodic assessments"]
GOVERN --> STANDARDS["📏 Standards\nEnforced by platforms\nNot manual review"]
GOVERN --> ETHICS["🧭 Ethical Oversight\nExplicit & designed in\nNot implicit"]
DECISION --> PRINCIPLE["✅ Principle\nSet constraints\nMonitor outcomes"]
COMPLIANCE --> PRINCIPLE
RISK --> PRINCIPLE
STANDARDS --> PRINCIPLE
ETHICS --> PRINCIPLE
Governance principles for autonomous systems: Humans set constraints — systems operate within boundaries humans define. Automated compliance — routine checks are automated; human review for exceptions. Transparency — all AI decisions are logged and auditable. Escalation — clear paths when systems exceed their mandate. Kill switches — humans can override any autonomous system.
Adaptive governance: low autonomy systems get high governance (manual review). Medium autonomy gets medium governance (automated checks + exception review). High autonomy gets low governance (fitness functions, dashboards, kill switches). Key mechanisms: fitness functions for automated compliance, architecture decision records for audit trails, constraint definitions for boundaries, and ethical review boards for AI decisions with moral implications.
Govern by setting constraints and monitoring outcomes — not by reviewing every decision.
Try it yourself — The governance audit
How much of your governance is manual vs automated?
| Governance activity | Manual % | Automated % | Target automated % |
|---|---|---|---|
| Compliance checks | |||
| Standards enforcement | |||
| Risk monitoring | |||
| Decision review |
If manual is over 50%, you're not ready for autonomous systems.
7. Designing the transition — How to move from current to future operating model deliberately
The transition from current to future operating model can't happen overnight. Attempting to restructure everything at once fails — people resist, technology isn't ready, and the foundation isn't in place. The transition must be phased and deliberate.
The transition has four sequential phases:
flowchart LR
P1["🏗️ Phase 1\nFoundation\n6-12 months\nPlatform teams\nProduct funding\nAI literacy"] --> P2["🤖 Phase 2\nAugmentation\n6-12 months\nAI tools integrated\nRoutine work automated"]
P2 --> P3["🔀 Phase 3\nRestructuring\n12-18 months\nTeam topology redesigned\nRole evolution"]
P3 --> P4["⚡ Phase 4\nOptimisation\nOngoing\nGovernance automated\nContinuous improvement"]
Transition principles — what to do and what not to do:
| Do | Don't |
|---|---|
| Build foundation first | Restructure before foundation is in place |
| Pilot in one domain | Big-bang across entire organisation |
| Invest in skills before role changes | Change roles without skills in place |
| Communicate the vision | Assume people know where they're going |
| Measure the transition | Assume it's working without data |
Phase details:
| Phase | Focus | Duration | Key activities |
|---|---|---|---|
| Foundation | Platform teams, product funding, AI literacy | 6-12 months | Establish platforms, change funding, train workforce |
| Augmentation | AI tools integrated, routine work automated | 6-12 months | Deploy AI tools, automate testing/monitoring/coding |
| Restructuring | Team topology redesigned, role evolution | 12-18 months | Redesign teams, evolve roles, establish new patterns |
| Optimisation | Governance automated, continuous improvement | Ongoing | Automate compliance, refine, measure, iterate |
Manage transition risks: too fast causes resistance, too slow causes obsolescence. Use a pilot-first approach — select one domain, implement the full future model, measure results, learn and adapt, then scale to the next domain. Key risks: restructuring before foundation is ready, changing roles without investing in skills, and failing to communicate the vision.
Foundation → Augmentation → Restructuring → Optimisation. Don't skip steps.
Try it yourself — The transition check
Which phase is your organisation in?
| Phase | Evidence | Ready for next? |
|---|---|---|
If you're trying to restructure before building foundation, you'll fail. Go back to Phase 1.
8. AI and workforce composition — How AI changes the ratio of human to automated work
AI doesn't just change what work is done — it changes how many humans are needed, what roles exist, and how teams communicate. If organisations don't proactively redesign team boundaries based on new communication patterns, they end up with structures that no longer match the flow of work.
AI changes the workforce composition and communication patterns:
flowchart TD
BEFORE_W["👥 Before AI"] --> B_100["100 engineers\ndoing all work"]
BEFORE_W --> B_JUNIOR["Junior engineers\nwrite code"]
BEFORE_W --> B_SENIOR["Senior engineers\nreview code"]
BEFORE_W --> B_OPS["Ops team\nmonitors systems"]
AFTER_W["👥 With AI"] --> A_60["60 engineers + AI\ndoing routine work"]
AFTER_W --> A_JUNIOR2["AI writes code\njuniors review & learn"]
AFTER_W --> A_SENIOR2["Senior engineers\ndesign systems & govern"]
AFTER_W --> A_OPS2["AI monitors\nops handles exceptions"]
BEFORE_W --> COMMS["Communication pattern\nstays the same\nStructures become misaligned"]
AFTER_W --> HEATMAP["🔥 Communication Structure\nHeatmap\nRedesign team boundaries\nproactively"]
The workforce shift:
| Dimension | Before AI | With AI |
|---|---|---|
| Team size | Larger teams doing all work | Smaller teams + AI doing routine work |
| Seniority mix | Many juniors, fewer seniors | More seniors, fewer juniors (higher judgement) |
| New roles | None | AI operations, prompt engineering, agent governance |
| Learning | Learn by doing routine work | Learn by reviewing AI output, focusing on judgement |
The Communication Structure Heatmap maps how communication patterns between teams change when AI is introduced. When AI handles routine coding, testing, and monitoring, the communication that previously flowed between teams for these activities shifts or disappears. If team boundaries were designed around old communication patterns, they become misaligned.
How to use it: Map current communication — who talks to whom, about what, how often. Identify AI-impacted flows — which communications will AI handle or change. Predict new patterns — what will teams need to communicate about after AI. Redesign boundaries — adjust team boundaries to match new communication flows. Validate — test new boundaries with a pilot before scaling.
If the strategy requires a unified platform but the organisation has 20 autonomous silos, fix the org first. Redraw team boundaries before redrawing system diagrams — because the system will follow the organisation, not the other way around.
Fewer humans, more judgement-heavy roles, continuous learning — redesign team boundaries proactively using the Communication Structure Heatmap before structures become misaligned.
Try it yourself — The communication heatmap
Map your current team communication:
| Team A → Team B | Frequency | AI will change this? | New pattern |
|---|---|---|---|
If AI will change more than 30% of your communication flows, your team boundaries need redesigning.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
FORCES_FM["🌊 Four Forces\nAI · Platforms\nProducts · Ecosystems"] --> AI_FM["🤖 AI Augmentation\nRoutine automated\nHumans handle judgement"]
FORCES_FM --> PLAT_FM["📦 Platform Model\nShared foundation\nTeams build features"]
FORCES_FM --> ARCH_FM["🏛️ Architecture Evolution\nDesigner → Strategist\n+ Governor"]
AI_FM --> TRANS["🛤️ Deliberate Transition\nFoundation → Augmentation\n→ Restructuring → Optimisation"]
PLAT_FM --> TRANS
ARCH_FM --> TRANS
TRANS --> GOV_FM["⚖️ Adaptive Governance\nSet constraints\nMonitor outcomes"]
TRANS --> SKILLS_FM["🎓 Skills Shift\nJudgement · Design\nCommunication · Ethics"]
GOV_FM --> RESULT_FM["✅ Future Operating Model\nDesigned, not drifted into"]
SKILLS_FM --> RESULT_FM
The foundation:
The future operating model must be designed, not drifted into. AI, platforms, products, and ecosystems are reshaping technology organisations — design for these conditions or accept obsolescence. AI handles routine; humans handle judgement, design, governance, and ethics. The architect's role evolves from designer to strategist and governor. Invest in the skills AI can't replace. Transition deliberately: Foundation → Augmentation → Restructuring → Optimisation. Don't skip steps. Pilot before scaling. Redesign team boundaries proactively using the Communication Structure Heatmap before redrawing system diagrams. Design the future — or accept whatever structure emerges by accident.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Four forces | AI, platforms, products, ecosystems | Design for all four |
| AI-augmented function | AI handles routine; humans handle judgement | Redesign roles accordingly |
| Platform model | Shared foundation; self-service | Restructure teams around platforms |
| Architecture evolution | Designer → Strategist + Governor | Evolve the role — don't cling to control |
| Skills | Judgement, design, communication, governance, ethics | Invest in these before restructuring |
| Governance | Set constraints, monitor outcomes | Automate compliance; review exceptions only |
| Transition | Foundation → Augmentation → Restructuring → Optimisation | Deliberate, not drift — don't skip steps |
| Workforce composition | Fewer humans, more judgement roles | Use Communication Structure Heatmap to redesign boundaries |
How to know if this landed
You'll know this has landed when someone stops treating the future operating model as speculation and starts treating it as a design problem. Can explain the four forces reshaping the operating model and how they interact. AI tools are integrated with governance — not adopted ad-hoc without role redesign. Platform teams exist and are funded continuously, measured by adoption. Architecture role has shifted from design authority to strategic governance. Skills investment programme exists — focused on judgement, design, and governance. Governance adapts to system autonomy — automated for routine, human review for exceptions. And Communication Structure Heatmap has been used to proactively redesign team boundaries before restructuring system diagrams.
What changes when the mental model clicks
I've run this session with a 500-person technology organisation structured for 2020 — projects, manual operations, centralised decisions. AI tools adopted ad-hoc — no strategy, no governance, no role redesign. Platform teams existed but were request-based, not self-service. Architecture team was a bottleneck — reviewed every decision. The gap at the start is usually not about understanding the future — it's about not designing for it.
What changes after this session:
Teams stop drifting into the future and start designing it. The Communication Structure Heatmap exercise — "map current flows, predict AI-impacted flows, redesign boundaries" — is always the moment things click. People stop treating AI as a tool and start treating it as a workforce composition change. Their results get better. They stop restructuring system diagrams when the real problem was that their team boundaries were misaligned.
The transition pathway exercise tends to immediately change how teams think about their transformation. They start sequencing correctly — foundation first, augmentation second, restructuring third. Their success rates go up. They stop trying to restructure before the foundation is ready when the real problem was that they skipped Phase 1.
Book a Workshop
Ready to design the future operating model for your technology organisation?
or
1-day workshop includes current state assessment — where is your operating model today, future vision design — what does the future operating model look like for your context, AI impact analysis — what work will AI automate? What roles change, platform restructuring — how do platforms reshape your team topology, architecture role evolution — what does the architect role become, Communication Structure Heatmap — map flows, predict AI impact, redesign team boundaries, transition pathway — Foundation → Augmentation → Restructuring → Optimisation, and future operating model scenarios + AI-native organisation design principles + transition pathway.