Why Engineering Teams Need Operating Models

As an advisor to tech scaleups, and a former CTO and SVP of Engineering,  I've often encountered a familiar CEO complaint: "Our engineering team is too slow!" However, focusing solely on increasing individual productivity is rarely the solution. Sometimes the answer is changing the organizational structure. 🔍 The Issue with Flat Structures: Time to market was a major problem in a scale-up I advised, even though they had a flat structure where 40+ engineers reported directly to the VP of engineering and all of them shared equal accountability to the delivery of the software. 🚧 The Consequences: Major overcommitment.  People raised their hands to take on work even if the group was super extended. There was nobody that fully understood the team’s capacity vs the actual workload they took on. This approach led to a lack of predictability, chronic delays, unhappy customers, and ultimately, a tarnished reputation. 🛠️ The Solution: Transitioning to a hierarchical structure with focused teams and accountable experienced leaders was the game-changer. This shift brought in clarity, accountability, and much-needed structure. 📈 The Results: Predictable schedules, improved customer satisfaction, and a thriving engineering culture. ✅ Takeaways for Your Organization: Examine your organization with critical eyes: Is your ownership and accountability structure clear? Are your teams sized and focused appropriately? Do your leaders have the authority to deliver effectively? For more on the case study and about building a sustainable, efficient, and customer-centric engineering team in the blog post. 💭 I'm curious to hear your thoughts: Have you faced similar challenges? How did you address them? Let's share insights and grow together! #EngineeringManagement #Leadership #Productivity  _______________ ➡️ I am Talila Millman, a fractional CTO,  a management advisor, and a leadership coach. I help CEOs and their C-suite grow profit and scale through optimal Product portfolio and an operating system for Product Management and Engineering excellence.  📘 My book The TRIUMPH Framework: 7 Steps to Leading Organizational Transformation will be published in Spring 2024 https://lnkd.in/eVYGkz-e

𝐃𝐞𝐬𝐢𝐠𝐧𝐢𝐧𝐠 𝐭𝐡𝐞 𝐄𝐧𝐭𝐞𝐫𝐩𝐫𝐢𝐬𝐞 𝐀𝐈 𝐎𝐩𝐞𝐫𝐚𝐭𝐢𝐧𝐠 𝐌𝐨𝐝𝐞𝐥 In my previous post, I discussed the Enterprise AI Talent Stack and the talent architecture organizations need to scale AI.  But hiring the right talent is only the first step. Once those capabilities are in place, the next critical question becomes: How does the organization actually run AI as a function? This is where many enterprises struggle. Even with strong AI talent, organizations often face the same pattern: * AI initiatives emerge across different teams * Ownership of models in production becomes unclear * Governance is applied too late in the lifecycle * Scaling beyond experimentation becomes difficult The missing piece is usually a clearly defined AI Operating Model. The operating model defines how AI work flows through the organization—from idea to production to long-term oversight. A strong enterprise AI operating model typically answers four critical questions: 1. How Are AI Use Cases Prioritized? AI resources are finite. Not every opportunity should be pursued. The operating model should define: * How business teams propose AI use cases * How initiatives are evaluated for value and feasibility * Who ultimately prioritizes investment Leading organizations treat AI initiatives as a portfolio, balancing impact, risk, and strategic alignment. 2. Who Owns AI Systems After Deployment? One of the most common gaps in enterprise AI is post-deployment ownership. The operating model must clearly define: * Who monitors models in production * Who is accountable for model drift or performance degradation * Who manages updates as data, markets, or regulations evolve Without lifecycle ownership, even well-built AI systems degrade over time. 3. How Is Governance Embedded Across the Lifecycle? Governance cannot be a final checkpoint before deployment. A mature operating model integrates governance across: * Use case approval * Model development and testing * Validation and risk assessment * Production monitoring and auditability This ensures AI systems remain trusted, compliant, and aligned with enterprise risk appetite. 4. How Do Business Teams Access AI Capabilities? AI should not remain confined to a central team. The operating model should create clear pathways for business units to: * Propose AI opportunities * Collaborate with AI teams * Integrate AI solutions into operational workflows Many organizations adopt a hub-and-spoke model, where a central AI function provides standards, governance, and platforms while business units drive use case innovation. Scaling AI is not just about building models. It’s about designing an operating model that clarifies: * Decision rights * Lifecycle ownership * Governance integration * Collaboration between business and technology teams Because at enterprise scale, AI success is as much an organizational design challenge as it is a technological one.

I might sound controversial but I often see ENGINEERING teams rewarded for throughput while the business pays the cost in churn, wasted infrastructure, and missed product-market fit ⚠️ If your releases are frequent but your KPIs do not move, the problem is not velocity. The problem is alignment, measurement, and feedback. (SAVE THIS POST FOR LATER) 📌 Here’s what typically fails in fast teams, in technical terms: • Misalignment at peak. Teams optimize for closed tickets and velocity metrics instead of leading indicators like activation, time-to-first-value, and task completion rate. • No hypothesis-driven work. Features are shipped as solutions to assumptions, not experiments that test falsifiable hypotheses. • Poor observability. Releases are blind because telemetry lacks business-context signals. Traces and logs exist, but event schemas that map to user intent do not. • Weak release control. No feature flags, canaries, or rollback strategy, so bad ideas propagate quickly, and recovery costs escalate. • Architecture that prioritizes features over flows. Overly chatty APIs, synchronous blocking paths, and brittle data models make small changes risky. If you want real outcomes, treat your delivery pipeline like a scientific lab 🧪 ⚡ Here is an operational playbook that converts velocity into impact: - Align outcomes to a single north star and 2–3 leading indicators. - Translate OKRs into event-level telemetry you can query in real time. - Define expected metric delta, sample size, and rollback criteria before code is written. - Use structured events, OpenTelemetry tracing, and product analytics (Amplitude, Mixpanel) with event names that map to user intent. - Use feature flags, canary releases, and automated rollbacks so you can validate in production safely. ⚙️ Tools: LaunchDarkly, Flagger, or homegrown flagging backed by robust metrics. When engineering decisions are explicitly tied to business hypotheses and telemetry, shipping becomes learning. You stop paying for churn and start investing in compoundable product improvements. ✅ Repost this post with your network to help them improve business outcomes and focus on the things that matters.

Jira tickets alone don't show team dynamics. Behind each task is a hidden structure. Engineering data is scattered across tools, making it hard to understand how teams are truly organized. Jira has boards, GitHub has its own team definitions, and some tools like Cursor only show individual usernames. This fragmentation hides the real structure behind engineering work. By connecting data points from every platform, commits, pull requests, Jira tickets, and stories, scattered inputs become a single, clear view. Engineers are no longer just usernames or aliases. Each person is mapped to their team, group, site, and even the business unit they contribute to. This unified model reveals who is doing what, where, and with which tools, including GenAI models in use. Leaders gain an accurate picture of their organization, eliminating the guesswork that comes with siloed data. Milestone makes this visibility possible, turning fragmented data into a cohesive understanding of engineering structure and activity.

The $3M Enterprise Architecture Team That Couldn’t Shape Architecture   Last month we reviewed an Enterprise Architecture office with a $3M annual run rate and all the visible signals of maturity. Formal structure. Defined domains. Capability maps.   Yet it had become the single biggest bottleneck in the delivery portfolio.   The failure was not talent, tooling, or intent. It was structural.   There was no operating model.   Every architect was pulled into everything at once. Strategic initiatives. BAU tickets. Solution feasibility. Reviews. Certifications.   With no demand segmentation, no decision rights, and no capacity allocation by intent, the function defaulted to absorption. A team designed to shape outcomes was executing demand.   The cost was predictable. Business Architects documented. Artefacts multiplied. Decisions slowed, escalations stalled, and architectural leverage evaporated.   What accumulated was not clarity, but paper. Artefacts substituted for decisions.   The most honest question came from the team itself:
“What are we actually optimising for?” Speed? Control? Coherence?   That question remained unanswered because it was never a team decision to make. Leadership had not defined the optimisation target, nor designed the system to support it.   Without an explicit operating model for how EA work is prioritised, exercised, and escalated, overload became policy by default.   This is the silent pattern we see repeatedly across Enterprise Architecture, Data, and AI offices. The issue is rarely capability or effort.   Functions are expected to shape enterprise outcomes, yet are given neither the authority nor the structure to shape their own work.   Operating models are design choices, not cultural accidents.   You do not get enterprise leverage from a function that has none over itself.       Transform Partner – Your Strategic Champion for Digital Transformation   Image Source: Gartner

AI operating model that works? After nearly two decades of delivering data driven value at scale, I’ve come to a simple view: success with analytics and now AI, comes from understanding and solving real business problems vs. writing the top quality code. Coding infact is getting democratized fast. Tools like Claude Code and OpenClaw are already making it easier than ever to build. That’s no longer the bottleneck. Execution is, infact always was! Most AI efforts don’t fail because the models aren’t good enough. They fail because there’s no clear path from idea to real business impact. Either the problem wasn’t well defined, or no one owned what needed to change once the insight showed up. If you don’t start with a clear business problem, you’re already off track. What decision are we improving, what action will change, and who is accountable for the outcome. If that isn’t clear, nothing else matters. But the bigger issue, and the one I see repeatedly, is how teams are set up to deliver. We overcomplicate it. Too many teams, too many handoffs, unclear ownership. It slows things down. The operating model that works best at the most successful companies is actually very simple. It has just 3 entitities: Business, Insights and Engineering. Business owns the action. Insights drive the decision. Engineering builds and scales the product. When those three are clear, AI moves fast and delivers real outcomes. When they’re not, it stays stuck in pilots and presentations. #Enterprise #AI

AI is the talk of the town (guilty as charged). But let’s be real: AI isn’t a magic wand. Here’s the truth they don’t always tell you: AI is only as good as the foundation you build for it. If you don’t have the basics in place, you’re setting yourself up for garbage in, garbage out. You need: ↳ Clean data: If your data is a mess, AI will only amplify the chaos. Invest in organizing and optimizing it first. ↳ Solid processes: Document workflows that actually work. AI can’t fix broken systems—it can only automate them. ↳ People power: Your team needs to buy in. Change management isn’t just a nice-to-have—it’s essential for success. Models can help: The skeleton is 100% accurate, but doesn’t provide an accurate picture of how the entire human body works. Different models provide different perspectives. Combining the models provides a more accurate picture Jacco van der Kooij put together six essential models for growth that work like a layered cake. Each one builds on the other, creating a powerful growth system. Revenue Model ↳ Defines how your business makes money. Is it subscription-based? Transactional? Usage-based? ↳ Changing this takes years to absorb. Think Netflix moving to ads. ↳ It’s the bedrock. Mess this up, and the rest crumbles. Data Model ↳ Determines what data you collect and how it’s structured. ↳ A well-designed data model ties all functions together—from marketing to customer success. ↳ Garbage in, garbage out. Poor data leads to bad decisions. Mathematical Model ↳ Uses metrics and ratios to explain your growth (e.g., LTV/CAC, churn rates, NRR). ↳ Connects the dots between strategy and execution. ↳ Without this, your insights are anecdotal, not actionable. Operating Model ↳ Defines processes, roles, and accountability. ↳ Crucial for scaling. Absence leads to chaos. ↳ Scaling without an operating model is like driving without a map. Growth Model ↳ Details how growth compounds (e.g., referral loops, upsells, market expansion). ↳ Accelerates your flywheel. ↳ This is the 𝘦𝘯𝘨𝘪𝘯𝘦 that fuels hypergrowth. GTM Model ↳ Aligns your sales, marketing, and customer success teams. ↳ Humans interact with this model daily. ↳ Even the best product fails without execution. Individually, these models provide valuable insights. Together? They’re unstoppable. A solid foundation ensures your strategy is evidence-based and scalable. The dynamic layers adapt to changing market conditions and keep the engine running smoothly. Why do most struggle? ↳ Siloed Thinking: Teams focus on individual models without seeing the bigger picture. ↳ Overlooking Data: Scaling decisions without a solid data model lead to expensive mistakes. ↳ Execution Gaps: Without a GTM model, even the best strategies fall flat. 🌶️ Take The best companies build systems. Systems that 𝘤𝘰𝘮𝘱𝘰𝘶𝘯𝘥 over time. These Six Essential Models are your blueprint to building a recurring revenue engine that not only scales but thrives in any market condition.

While data leaders focus on the newest technology, they forget the operating model is really the difference maker And I've never seen a bigger problem within data teams than a lack of operating model This is a crucial framework for guiding how the data and analytics function is organised and operates to deliver value within an organisation. To dive into more detail, I have mapped out three main levels in an Operating Model, each with key components worth noting: 1. 𝐖𝐡𝐚𝐭 𝐏𝐞𝐨𝐩𝐥𝐞 𝐃𝐨 – 𝐃𝐚𝐲-𝐭𝐨-𝐃𝐚𝐲 𝐎𝐩𝐞𝐫𝐚𝐭𝐢𝐨𝐧𝐬 👥 𝐑𝐨𝐥𝐞𝐬 & 𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐢𝐛𝐢𝐥𝐢𝐭𝐢𝐞𝐬: Defining the purpose of each role, the decisions they make, and their accountabilities. This clarity eliminates inefficiencies and sets a clear direction for individuals and teams, necessary in complex data operational structures. 2. 𝐒𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞 𝐨𝐟 𝐃𝐞𝐥𝐢𝐯𝐞𝐫𝐲 – 𝐆𝐮𝐢𝐝𝐢𝐧𝐠 𝐭𝐡𝐞 𝐎𝐩𝐞𝐫𝐚𝐭𝐢𝐨𝐧𝐚𝐥 𝐃𝐞𝐥𝐢𝐯𝐞𝐫𝐲 💼 𝐑𝐞𝐩𝐨𝐫𝐭𝐢𝐧𝐠 𝐋𝐢𝐧𝐞𝐬: Establish a clear reporting structure within the data team and their interaction with other business functions. In large organizations, knowing who reports to whom is vital for maintaining timelines, ownership, and delivery. 🏗️ 𝐃𝐞𝐥𝐢𝐯𝐞𝐫𝐲 𝐌𝐨𝐝𝐞𝐥: Define how teams deliver data initiatives from start to finish (e.g., agile, waterfall, etc.), including how they work across capabilities/ teams 🔄 𝐖𝐨𝐫𝐤𝐟𝐥𝐨𝐰 & 𝐃𝐞𝐥𝐢𝐯𝐞𝐫𝐲 𝐏𝐫𝐨𝐜𝐞𝐬𝐬𝐞𝐬: Implement processes for collaborating with data and business stakeholders. Design to alleviate existing pain points and promote collaboration 3. 𝐎𝐯𝐞𝐫𝐬𝐢𝐠𝐡𝐭 & 𝐃𝐢𝐫𝐞𝐜𝐭𝐢𝐨𝐧 – 𝐀𝐥𝐢𝐠𝐧𝐦𝐞𝐧𝐭 𝐰𝐢𝐭𝐡 𝐎𝐫𝐠 & 𝐋𝐞𝐚𝐝𝐞𝐫𝐬𝐡𝐢𝐩 𝐆𝐨𝐚𝐥𝐬 🎯 𝐏𝐫𝐨𝐠𝐫𝐚𝐦/ 𝐎𝐫𝐠 𝐋𝐞𝐚𝐝𝐞𝐫𝐬𝐡𝐢𝐩: Designate individuals with accountability to ensure the overall direction is clear and consistent 💡𝐃𝐚𝐭𝐚 𝐒𝐭𝐫𝐚𝐭𝐞𝐠𝐲 & 𝐓𝐞𝐚𝐦 𝐆𝐨𝐚𝐥𝐬: Ensure the ‘what’ and ‘where’ is defined when it comes to the data direction 🧑🏫𝐆𝐨𝐯𝐞𝐫𝐧𝐚𝐧𝐜𝐞 𝐅𝐨𝐫𝐮𝐦𝐬: Establish forums to discuss issues, align on progress/ direction and determine the best path forward 📚𝐎𝐩 𝐌𝐨𝐝𝐞𝐥 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞𝐬: Set guiding principles (kind of like values) for how teams should work together in respectful, collaborative and efficient ways 📈 𝐏𝐞𝐫𝐟𝐨𝐫𝐦𝐚𝐧𝐜𝐞 𝐌𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭: Define KPIs and ROI for data initiatives. Set up points to regularly measure progress and performance to ensure teams remain focused Check out more in my article on this topic!

Your competitor made >$10M with AI predictive model. But your data team delivered 221 dashboards in 12-months. Your team not slow, just broken. Been hearing this for the past weeks “Our data team is so slow.” Iterations, requests take weeks. Priorities keep shifting. Everyone’s busy, but nothing moves. Let’s be clear, that’s not a talent issue. It’s a structural failure. Your data team isn’t drowning in work. They’re drowning in dependencies, misaligned ownership, and bad incentives. Mistake #1: You Built by Function, Not by Outcome Most teams look like this: Engineers ingest data Analytics engineers model it BI developers visualize it Analysts most times nobody knows what they doing. Looks efficient on paper. In reality? It’s a garbage. Each role optimizes for its piece, not the outcome. The engineer ships a pipeline which already made. The analyst ships a dashboard which usless. Nobody owns the impact that dashboard is meant to enable. That’s why velocity dies. Fix: Organize around data products, not job titles. Each data product (e.g., revenue insights, supply chain metrics, marketing attribution) should have cross-functional memeber that owns it end-to-end. When the same squad owns ingestion → modeling → delivery, you eliminate 80% of the handoffs that kill speed. Mistake #2: You Measure Output Instead of Impact You’re tracking the wrong KPIs. Executives love vanity metrics: “How many dashboards did we build?” “How many pipelines went live to prod?” That’s noise. What you should measure is throughput, how fast the business goes from question, problem → trusted data → impact If your don't have clera defintions of done, ETA and ROI. You doing nothing. Fix: Velocity isn’t how fast engineers code, it’s how fast the business gets results. Mistake #3: You Built a Platform Without an Operating Model Every company says they have a “data platform.” Few have a data operating model, a clear system for ownership, collaboration, and accountability. So you get chaos: Five teams writing pipelines differently Conflicting metrics definitions Endless meetings to resolve “which number is right” That’s not a tooling problem. It’s an org-design problem. Fix: Define how your platform and data teams interact. Who owns ingestion? Who owns definitions? Who approves changes? And for every dataset, model, and 'data product', name an owner. Velocity doesn’t come from adding tools. It comes from removing friction. Your team isn’t slow because they lack skills. They’re slow because you built an org that rewards activity over impact. You don’t fix that with more headcount or another vendor. You fix it by rewiring focusing on impact, trust and adoption. One team, one outcome, 90-day delivery cycles. If your team’s buried under tickets and “urgent requests,” it’s not a workload problem, it’s an operating model problem. 🧬 Repost if you think most data teams creating bureaucracy.

⭐ 𝗖𝗵𝗼𝗼𝘀𝗶𝗻𝗴 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝗲𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲 / 𝗜𝗧 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝘁𝗲𝗮𝗺 𝗺𝗼𝗱𝗲𝗹 𝗱𝗲𝘁𝗲𝗿𝗺𝗶𝗻𝗲𝘀 𝘀𝗽𝗲𝗲𝗱, 𝗮𝗹𝗶𝗴𝗻𝗺𝗲𝗻𝘁 & 𝗿𝗶𝘀𝗸. One of the biggest misconceptions in our field is that there is one ideal way to organise an enterprise architecture function. 𝗧𝗵𝗲𝗿𝗲 𝗶𝘀𝗻’𝘁. Modern organisations typically choose between three dominant models, each with its own strengths, trade-offs, and failure modes: 🔵 ① Centralised Model 👥 One unified architecture team ✔ High coherence ✔ Strong strategic alignment ✔ Easy knowledge sharing ⚠ Risk: distance from delivery ⚠ Risk: bottlenecks when demand grows Best for: organisations early in their architecture journey or those needing a coherence reset. 🟣 ② Federated Model 🧩 Architects embedded in domains / BUs / product groups ✔ Deep proximity to delivery ✔ Strong contextual understanding ✔ Faster decisions ⚠ Risk: fragmentation without enterprise guardrails ⚠ Requires mature collaboration Best for: product-driven organisations with high domain autonomy. 🟢 ③ Hybrid Model (most common) 🏛 Central EA + cross-cutting roles 🤝 Domain & solution architects close to delivery ✔ Balance of coherence and agility ✔ Scalable as the organisation grows ⚠ Requires disciplined coordination ⚠ More organisational complexity Best for: most modern organisations operating at high change velocity. ⭐ 𝗧𝗵𝗲 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆 Architecture isn’t a role: it’s a capability you design intentionally. Choose the wrong model → misalignment, friction, technical debt Choose the right model → clarity, consistency, and delivery at speed If you’re rethinking your architecture setup (or struggling with the one you have), this is often the best place to start the conversation. #EnterpriseArchitecture #ArchitectureTeam #ArchitectureGovernance #BusinessArchitecture #SolutionArchitecture #DigitalTransformation #OperatingModel #TechLeadership #ITArchitecture #ArchitectureInAction 📕 Discover my book Architecture in Action and turn "EA on paper" into actionable enterprise architecture that shapes decisions, accelerates transformation, and connects strategy with execution in a tangible way. 🔔 𝐅𝐨𝐥𝐥𝐨𝐰 𝐍𝐢𝐞𝐤 𝐃𝐞 𝐕𝐢𝐬𝐬𝐜𝐡𝐞𝐫 𝐟𝐨𝐫 𝐚𝐜𝐭𝐢𝐨𝐧𝐚𝐛𝐥𝐞 𝐄𝐀 𝐚𝐧𝐝 𝐬𝐭𝐫𝐚𝐭𝐞𝐠𝐲 𝐭𝐢𝐩𝐬 & 𝐭𝐫𝐢𝐜𝐤𝐬.