A comprehensive TOM for a 200–500 person ICT group already operating on a product/squad model — designed to evolve and mature that foundation into an AI-native, platform-powered, outcome-accountable operating model for 2026 and beyond.
This TOM is an evolution design, not a transformation from scratch. Your ICT group is already on a product/squad model — the foundation is right. The target state matures that foundation into five dimensions: an AI-native team topology, a genuine platform engineering capability, federated AI governance, outcome-based performance, and a talent model built for the AI era.
Sets direction, governs investment, owns AI strategy, manages portfolio
Stream-aligned squads owning customer-facing capability
ERP, finance, HR, supply chain — operational backbone
Data products, AI features, reporting and insights
Integration layer, partner APIs, event streaming
Golden paths, self-service, CI/CD, observability
Data mesh, quality, lineage, AI-ready infrastructure
Model hosting, MLOps, AI golden paths, inference
AI adoption, tool evaluation, capability uplift
Technical governance, ADRs, architecture runway
Embedded security, compliance, risk controls
Multi-cloud operations, FinOps, reliability
ITSM, incident, problem, change management
Contract, relationship, and performance governance
Skills taxonomy, AI literacy, talent development, psychological safety
ICT PMO, DORA metrics, OKRs, investment governance
Every team accountable for a measurable business outcome — not a delivery milestone. OKRs at squad level, connected to portfolio OKRs, connected to enterprise strategy.
The Internal Developer Platform is a product with a roadmap, a product manager, and a developer NPS target. Not infrastructure ops with a ticket queue.
AI is a deliberate, designed participant in every team's workflow — with explicit human-AI handoff points. Not a tool bolted on. Not optional.
Teams focus on business domain problems. Platform absorbs infrastructure complexity. AI absorbs execution toil. The measure: time spent on domain work vs. everything else.
Teams have autonomy within governed boundaries. Central ICT sets standards and platforms. Squads deliver within them. Neither pure centralisation nor pure autonomy.
DORA + SPACE + Flow Metrics + Business Outcomes. Published, visible, honest. The dashboard is the governance mechanism — not the meeting.
The TOM is reviewed and updated quarterly. AI capabilities change on a quarterly cycle. The operating model must evolve at the same pace — not annually.
For a 200–500 person ICT group on the product/squad model, the target structure organises around six functional areas — each with a distinct mandate, accountability, and way of working. The critical design decision is how these areas interact, not just what they do.
| Domain | Squad type | Typical size (AI-era) | Accountability | Interfaces with |
|---|---|---|---|---|
| Customer & DigitalCustomer-facing products and experiences | Stream-aligned | 4–6 (down from 7–9 pre-AI) | Customer outcome OKRs — NPS, engagement, conversion | Platform (IDP, AI), Data, Security |
| Business OperationsERP, finance, HR, supply chain systems | Stream-aligned | 5–7 (complexity-dependent) | Operational efficiency OKRs — process time, error rate, cost | Platform (IDP), Security, Vendors |
| Data & AnalyticsData products, AI features, reporting | Stream-aligned + Data Platform | 4–6 per product | Data quality, insight consumption, AI outcome OKRs | Data Platform, AI Platform, all BUs |
| Integration & APIsIntegration layer, partner connectivity | Stream-aligned | 4–6 | API reliability, latency, partner SLA adherence | Platform, Security, External Partners |
The single most impactful structural change in this TOM is reorienting the Platform team from infrastructure operations to Internal Developer Platform product team. This means: a Product Manager who owns the platform roadmap. Developer NPS as the primary success metric. Golden paths built with pull (engineers adopt voluntarily because the experience is superior). AI capabilities embedded in the platform — same tooling, same guardrails, every squad. Gartner projected that 80% of software engineering organisations would establish dedicated platform teams by 2026 — that projection has largely materialised, though the path to mature platforms has been longer than many anticipated.
AI capabilities are not stable. Claude Code in January 2026 is fundamentally different from Claude Code in January 2025. The prompting patterns, context engineering approaches, model capabilities, and pricing — everything changes on a quarterly cycle. An enabling team that disbands after teaching "how to use AI" would need to reform 3 months later. Unlike traditional enabling teams (which dissolve once capability is embedded), the AI Enabling Team is a permanent fixture — because the capability it's enabling keeps changing. Without it, each squad spends 10–20% of time independently evaluating tools. With it: 2–5% per squad, with shared results.
The product/squad model you already have is the right foundation. The AI-era evolution is not a structural overhaul — it is a calibration: smaller stream-aligned teams, a platform team repositioned as the highest-ROI investment, and a permanent AI enabling function.
Two teams working closely together for a defined period to discover solutions or solve a complex problem. High bandwidth, temporary, with clear end point.
One team consumes a capability from another via a defined interface — API, golden path, data product. No synchronous coordination needed.
An enabling team helps a stream-aligned team adopt a new capability — then moves on. The goal is always to make itself unnecessary for that capability.
| Role | Count (3–5 person team) | AI shift in the role | Key 2026 skill |
|---|---|---|---|
| Product Manager | 0.5–1 (shared across small squads) | AI generates market analysis, user research synthesis, backlog suggestions — PM validates and decides | Outcome hypothesis definition. AI product ethics. OKR ownership. |
| Senior Engineer / Tech Lead | 1 | Shifts from code writer to system architect and AI orchestrator. Reviews and validates AI-generated code. | Systems thinking. AI orchestration. Architecture judgment. Code review at scale. |
| Engineer(s) | 1–3 | Curates and directs AI agents. Writes business logic where AI cannot. Quality validation of AI output. | Prompt engineering. Output validation. Domain knowledge. AI tool fluency. |
| Designer (UX) | 0.5 (shared) | AI generates design variants and prototypes — designer curates, validates with users, and maintains consistency | AI-assisted design tools. Human-AI interaction design. Accessibility. |
| QA / Quality Steward | 0.5–1 | AI generates test cases and runs regression — QA validates AI output quality, manages evaluation sets | AI quality assurance. Evaluation set design. Hallucination detection. |
Most ICT groups that have adopted the squad model still have persistent cross-squad dependencies, coordination overhead, and delivery friction. The root cause is almost always architecture coupling, not process failure. Squads were formed without aligning domain boundaries to software boundaries. Teams that must constantly coordinate are architecturally coupled — no ceremony redesign fixes that. The structural remedy: domain decomposition using DDD bounded contexts, with squad boundaries aligned to domain boundaries. The dependency map is the diagnostic: if the same two squads appear on the dependency map every PI, the boundary is wrong.
A technology operating model defines how technology work is executed across the enterprise. CIOs must design flexible, AI-native technology operating models that explicitly account for both human and AI contributions to work — embedding automation into workflows, accelerating decision making through distributed yet governed decision rights. Governance must enable speed. Every governance touchpoint that doesn't prevent a risk or enable a decision is waste.
| Decision | Who decides | Mechanism | Cadence |
|---|---|---|---|
| ICT Strategy & InvestmentPortfolio priorities, investment allocation | CIO + Portfolio Review Board | Quarterly portfolio review — decisions only | Quarterly |
| Architecture StandardsTechnology stack, patterns, ADRs | Enterprise Architect + Tech Leads | Weekly Architecture Sync + ADR process | Weekly / per decision |
| AI Tool AdoptionWhich AI tools enter the approved stack | CIO + CISO + AI CoE | AI tool evaluation gate — security + ethics + ROI | Per tool (fast-track for Tier 4) |
| Product RoadmapWhat the squad builds next | Product Manager + Squad | PI Planning / sprint planning — autonomous | Per PI / per sprint |
| Platform Capability PrioritisationPlatform team roadmap | Platform PM + squad community NPS | Quarterly platform roadmap review with consumer squads | Quarterly |
| Vendor & ContractMajor vendor relationships | CIO + Procurement + Legal | CIO sign-off above threshold — delegated below | Per contract cycle |
| Security ExceptionsDeviations from security standards | CISO + Risk Committee | Formal exception process — time-limited, reviewed | Per exception |
| Scope InjectionUnplanned work into a PI | ICT PMO + CIO (above threshold) | Fast-track intake — explicit trade-off decision | On-demand |
The central AI centre of excellence serves as the hub for strategy, enablement and governance rather than as a gatekeeper for approvals. It provides infrastructure, reusable assets, training and guardrails, while the business units take ownership of delivery, funding and outcomes.
The engineer of 2026 will spend less time writing foundational code and more time orchestrating a dynamic portfolio of AI agents, reusable components and external services. The core skill becomes systems thinking, not just syntax. This shift is structural — it requires deliberate investment in reskilling, role redefinition, and a talent model that attracts and retains people who thrive in human-AI collaboration.
| Role family | Current focus | Target state focus | Critical new capability |
|---|---|---|---|
| Software Engineers | Writing code to implement features | Orchestrating AI agents + curating AI-generated code + designing system architecture | AI orchestration, systems thinking, output validation, prompt engineering |
| Product Managers | Feature definition and delivery tracking | Outcome hypothesis, AI product ethics, benefit ownership, AI use case validation | OKR ownership, AI business case construction, ethics judgment |
| Architects | Technical design and standards governance | Domain decomposition, AI architecture, Conway's Law diagnosis, agentic system design | DDD, event-driven architecture, AI system architecture, A2A/MCP protocols |
| QA / Testers | Manual and automated test execution | AI quality stewardship — evaluation sets, hallucination detection, bias auditing | AI evaluation design, probabilistic output testing, continuous monitoring |
| Data Engineers | Pipeline development and data warehousing | Data product ownership, AI-ready data architecture, feature store management | Data mesh, MLOps, vector databases, data quality for AI |
| Platform Engineers | Infrastructure operations and DevOps tooling | IDP product ownership — golden paths, developer experience, AI platform capabilities | Developer NPS, internal product management, AI integration in platform |
| ICT Leaders (SADLs, EMs) | Delivery management and team coordination | Outcome leadership, AI governance, human-AI workflow design, strategic thinking | AI operating model design, portfolio thinking, business acumen |
Understanding what AI is, what it can and cannot do, and the ethical principles that govern its use. EU AI Act Article 4 mandates this for all staff.
Proficient use of approved AI tools in daily workflow. Prompt engineering, output validation, and knowing when not to trust AI output.
Building AI-augmented workflows, integrating AI APIs, designing human-AI handoffs, and evaluating AI output quality at system level.
Designing and governing multi-agent AI systems, managing AI quality at scale, and leading AI adoption within a squad or domain.
AI strategy development, investment governance, ethics accountability, and translating AI capability into business value language for the C-suite and Board.
The future of IT centres on continuous digital transformation, supported by explicit technology roadmapping rather than opportunistic project funding. McKinsey's 2025 technology strategy work points to platform engineering and AI as twin drivers of this shift — changing the unit of planning from "projects delivered" to "capabilities sustained."
| Data Mesh Principle | What it means in practice | Squad responsibility | Platform responsibility |
|---|---|---|---|
| Domain OwnershipSquads own their data products | The Customer squad owns customer data products. The Operations squad owns order data products. No central data team owns all data. | Define, publish, and maintain data products. Own data quality within their domain. | Provide data platform infrastructure, quality tooling, and publication standards. |
| Data as a ProductData treated like a product — with SLAs and consumers | Data products have schemas, SLAs, documentation, and quality metrics. Consumers rely on them as they would an API. | Apply INVEST-like criteria to data products. Treat data consumers as customers. | Provide data catalog, discovery, and quality monitoring tooling. |
| Self-Serve PlatformSquads publish and consume data without central bottleneck | No central data team needed to expose data. Squads use the platform to publish and consume data products autonomously. | Adopt platform standards for publication. No manual sharing of CSV files or database credentials. | Build and maintain the self-serve data infrastructure. Onboarding is the platform team's responsibility. |
| Federated GovernanceGlobal standards, local implementation | AI data requirements (lineage, consent, residency) are enterprise standards. Each squad implements them for their domain data. | Comply with data classification, privacy, and AI data standards for their data products. | Provide governance tooling, templates, and audit capabilities. |
Cloud costs are now operational metrics. Every architectural decision has financial consequences — FinOps can no longer operate in isolation from engineering and operations. In the target TOM, cost visibility is embedded in the IDP: squads see the cost implication of their infrastructure decisions before they deploy. AI inference cost is tracked separately — AI at scale is expensive, and the surprise comes when it's managed reactively. Target: every squad knows their cloud and AI inference cost in real-time. FinOps is a platform capability, not a finance team report.
The metrics model is the accountability backbone of the TOM. Every layer of the organisation has a distinct measurement lens. The CIO sees portfolio outcomes. Delivery leads see flow and DORA. Platform team sees developer NPS. Executives see business value. One dashboard, four views.
| Metric | Current (typical squad model) | Target state | Primary lever |
|---|---|---|---|
| Deployment Frequency | Weekly to daily | Multiple times per day | IDP golden path CI/CD + trunk-based development |
| Lead Time for Changes | 1–7 days | <1 hour | Automated pipeline + reduced handoff queues |
| Change Failure Rate | 10–25% | <5% | Test automation maturity + AI-assisted code review |
| Failed Deployment Recovery | Hours to days | <1 hour | Automated rollback + observability in IDP |
| Rework Rate (new 2025) | <10% | INVEST-ready features at PI Planning + better discovery |
The primary platform health signal. Quarterly survey: "How likely are you to recommend the IDP to a colleague?" Target: >50 NPS. Segmented by squad and capability area.
Time from new engineer onboarding to first successful production deployment via the IDP golden path. Target: <1 day. A measure of platform self-service maturity.
% of new services using the IDP golden path vs. custom pipeline. Target: >80%. Low adoption means the golden path isn't golden enough — fix it, don't mandate it.
| Dimension | Measure | Target | Action trigger |
|---|---|---|---|
| Satisfaction | Developer NPS — squad and platform | >50 overall; no squad below 30 | Declining NPS predicts throughput decline and attrition 1–2 quarters ahead |
| Performance | Quality of outcomes — not output volume | OKR achievement rate >70% | Low OKR achievement with high velocity = building the wrong things |
| Activity | PR volume, deployment frequency (used carefully) | Trending upward — never used as individual metric | Activity up, DORA flat = AI Productivity Paradox — fix the pipeline |
| Communication | Async decision rate, PR review latency | >70% decisions async; PR review <4hrs | High sync dependency = coordination overhead — review domain boundaries |
| Efficiency | % time on domain work vs. infrastructure toil | >70% domain work | <60% = platform investment needed — engineers doing ops work |
The TOM is not implemented in a single transformation. It evolves across three horizons — each building on the last. The sequence matters: data and platform foundation before AI, domain boundaries before AI tool adoption, governance before scale.
At 36 months, the test of this TOM is not whether the org chart changed. It is: Can a new engineer deploy to production on day one? Are DORA metrics in the high or elite range? Is developer NPS above 60? Are squads spending >70% of their time on domain problems rather than infrastructure toil? Is AI embedded in every team's workflow — governed, measurable, and genuinely accelerating outcomes rather than just individual output? If yes — the TOM delivered. If not — the quarterly review cycle exists to find out why and correct course.