## Intro Technology leaders often face a common challenge: a new strategy is approved, but the organization continues to operate in the same way. The gap between strategy and execution is rarely about technology; it is about how the organization is designed to deliver value. A Target Operating Model (TOM) is a blueprint that defines how a technology team should operate in the future to achieve its strategic goals. However, a TOM is not a document that can be written by a single person in isolation. It requires a structured, facilitated workshop where key stakeholders align on the future state, trade-offs, and transition path. This article provides a practical workshop template for technology teams to apply the Target Operating Model. It covers the management context, a realistic technology organization example, and a decision and governance checklist. The goal is to help you run a workshop that produces actionable decisions, not just a set of slides. ## Management Context A Target Operating Model describes how an organization will deliver value in the future. It answers questions such as: What capabilities do we need? How are teams structured? What processes and governance are required? What technology supports the operating model? Who makes which decisions? A TOM workshop is not a one-off ideation session; it is a structured decision-making process with clear inputs, facilitation, and outputs. When to use a TOM workshop: - After a strategic shift, such as a new product line, market entry, or merger. - When there is persistent misalignment between business and technology. - When scaling a team or platform beyond its current operating capacity. - When transitioning from project-based to product-based delivery. When not to use a TOM workshop: - For small, incremental process improvements better handled by continuous improvement cycles (e.g., PDCA) or lean methods. - For pure technology architecture decisions, which require architectural evaluation and design authority. - For market discovery or new product innovation, where methods like customer discovery, design thinking, or Lean Startup are more appropriate. Boundaries and adjacent methods: A TOM workshop is not a substitute for strategic planning. It assumes a strategic direction exists. It is also distinct from OKRs, which set objectives and key results; a TOM defines the operating structure to achieve those objectives. While SWOT analysis can inform the TOM by identifying internal strengths/weaknesses and external opportunities/threats, it is a situational analysis tool, not an operating model design tool. Similarly, PDCA is a continuous improvement cycle, not a design workshop. Use PDCA after the new operating model is implemented to refine processes. The TOM workshop should produce a future-state model, a gap analysis, and a sequenced transition plan. The output is a decision package for leadership, not a detailed implementation plan. ## Technology Organization Example Let's consider a fictional mid-sized technology company, Acme Software, which has grown rapidly from a single product team to multiple product lines. The CEO wants to scale from 50 to 200 engineers within 18 months. The current operating model is informal: teams are organized around projects, with matrixed reporting, no clear product ownership, and manual deployment processes. The CTO decides to run a TOM workshop to define the future operating model. Workshop participants: - Sponsor: CTO (decision rights for final model) - Facilitator: External consultant or internal strategy lead - Product leaders (one per product line) - Engineering managers - Head of Operations - Head of Security - Head of Data - HR business partner - Finance representative Workshop agenda (two days): Day 1: - 09:00-09:30: Opening and objectives. Sponsor explains why the TOM is needed and what success looks like. - 09:30-10:30: Current operating model review. Map current processes, structure, and pain points. - 10:30-12:00: Strategic context. Present strategy, market trends, and implications for technology. - 12:00-13:00: Lunch - 13:00-15:00: Design future capabilities. Identify required capabilities and organizational enablers. - 15:00-17:00: Breakout groups: Each group designs one aspect (e.g., team topology, governance, technology platform). Day 2: - 09:00-10:30: Groups present designs and discuss trade-offs. - 10:30-12:00: Consolidate into a draft TOM. Identify conflicts and decisions. - 12:00-13:00: Lunch - 13:00-15:00: Gap analysis: Compare current and future state. Identify priority gaps. - 15:00-16:00: Develop transition roadmap with phases, owners, and success metrics. - 16:00-17:00: Define decision rights and governance. Review and close. Key exercises: - Capability mapping : List required capabilities (e.g., product management, UX, engineering, SRE, security). For each, define ownership, metrics, and dependencies. - Organizational archetype selection : Choose a structure (e.g., product-centric pods, platform team, functional silos) and justify selection. - Decision rights matrix : For major decisions (e.g., architecture, hiring, budget, product roadmap), assign authority: who proposes, who approves, who consults, who informs. - Process design : For key processes (e.g., demand intake, delivery, incident response), define the future flow and roles. - Risk and governance : Identify risks of the new model (e.g., loss of alignment, security gaps) and mitigation controls. Outputs: - Future-state operating model diagram. - Capability heat map (current vs. required maturity). - Decision rights matrix. - High-level transition roadmap with 3-4 phases and owners. - List of open decisions with due dates. Ownership and follow-up: - Sponsor approves the final model. - A transformation lead is appointed to drive implementation. - Each phase has an accountable owner. - Monthly steering committee reviews progress and adjusts. Measures of success: - Adoption: Percentage of teams operating under the new model. - Delivery metrics: Lead time, deployment frequency, change failure rate. - Employee engagement and retention. - Customer satisfaction and value delivery. - Guardrail metrics: Security incidents, compliance violations, support burden. ## Decision and Governance Checklist Before finalizing the TOM, leadership should review the model against a decision and governance checklist. This ensures the model is not only well-designed but also implementable and governable.
Review QuestionOwnerDecision Check
Does the TOM align with the business strategy and priorities?Sponsor (CEO or CTO)Yes/No with rationale
Are decision rights clearly assigned for key decisions?Governance leadDocumented matrix exists
Is there a clear transition roadmap with named owners?Transformation leadPhases with owners and dates
Have we identified risks and mitigation controls?Risk ownerRisk register with controls
Are success metrics defined, including guardrails?Performance leadMetrics tracked in dashboard
Is the model feasible given current resources and culture?HR/FinanceCapacity analysis completed
Have we considered the impact on security, compliance, and data?Security/Data leadsImpact assessment signed off
Is there a mechanism for continuous improvement after implementation?Process ownerPDCA or similar loop defined
Decision rights: - The sponsor retains authority over the overall model and major trade-offs. - The transformation lead decides on implementation sequencing and resource allocation within approved budget. - Product and engineering leaders decide on team-level structures and processes within the model. - The governance board (sponsor + key stakeholders) reviews progress and resolves escalated issues. Ownership checks: - Each capability in the TOM must have a single accountable owner. - Each process in the TOM must have a process owner responsible for continuous improvement. - Each transition phase must have a named leader and a completion definition. - Decision rights must be communicated to all affected parties. Failures to avoid: - Designing a TOM in isolation without stakeholder input, leading to lack of buy-in. - Skipping the current state analysis, resulting in unrealistic transition plans. - Overcomplicating the model with excessive detail, making it hard to implement. - Neglecting the human and cultural aspects, leading to resistance. - Failing to assign clear owners and decision rights, causing ambiguity and delays. - Not defining success metrics upfront, making it impossible to evaluate progress. Continue/modify/stop criteria at each phase gate: - Continue if milestones are met, guardrails are green, and value is being delivered. - Modify if obstacles arise, but the overall model remains valid; adjust approach, not the model. - Stop if guardrail metrics are breached, strategic assumptions change, or the model proves unworkable; trigger a reassessment. ## Conclusion A Target Operating Model workshop is a powerful tool for technology leaders to align the organization with strategy. By following a structured template, you can facilitate effective discussions, make explicit decisions, and set the stage for smooth implementation. Remember that the workshop is only the beginning; the real work lies in governance, ownership, and continuous improvement. Next steps after the workshop: - Finalize and communicate the TOM decision package. - Appoint a transformation lead and establish a steering committee. - Launch the first phase of the transition roadmap with clear owners and metrics. - Monitor progress using the defined success and guardrail metrics. - Schedule regular reviews to adjust the model as needed. Management checks: - Has the sponsor approved the model and allocated resources? - Are decision rights documented and accepted? - Are phase gates defined with continue/modify/stop criteria? - Is there a feedback loop to capture lessons learned and improve? By applying this template, you can move from strategy to a functioning operating model that delivers sustained value.