The Trio Model: Breaking Down Business-IT Walls

Key Topics Covered

The Business-IT Dysfunction Problem

• Why blame games develop between business and IT teams
• The 'technical purgatory' of mid-sized companies (200-1000 employees)
• Common symptoms: endless backlogs, shadow IT solutions, demoralized engineers

Why Traditional Fixes Fail

• Hiring more managers: Adds abstraction without context
• Adding more engineers: Brooks' Law in action
• Better ticketing systems: Makes misalignment visible but doesn't fix it
• More meetings: Creates 'status theater' without decisions

The Trio Model Explained

• Three core roles: Business owner, technical lead, designer/analyst/ops lead
• Co-ownership of outcomes, not just task handoffs
• Clear decision rights to prevent gridlock
• Not a committee: Explicit authority assignment

Implementation Strategy

• Which problems warrant a trio (high ambiguity, cross-functional dependencies)
• Decision rights framework
• Shared metrics and accountability
• Starting with 1-2 pilot areas

Leadership Requirements

• Stop bypassing trio processes with 'urgent' requests
• Protect trio time and focus
• Hold business owners accountable for outcomes
• Accept timeline realities

Key Quotes

• "If every request is urgent, there's no way for IT to prioritize"
• "Shared ownership of the outcome doesn't mean you can point at someone else when your part goes wrong"
• "The trio owns it can quickly become no one owns it"

Action Items

• Identify 1-2 high-friction problem areas
• Form pilot trios with clear problem definitions
• Establish shared success metrics
• Review and iterate after one quarter

Chapters

• 0:00 - The Business-IT Blame Game Problem
• 1:56 - Life in Technical Purgatory
• 5:29 - Why Traditional Fixes Don't Work
• 10:09 - Introducing the Trio Model
• 15:51 - Implementation and Decision Rights
• 23:42 - Measuring Success with Shared Metrics
• 24:50 - Leadership Changes Required
• 29:25 - Getting Started: A Practical Approach

Why Your Team Rituals Are Optimized for the Wrong Thing

Key Topics Covered

The Missing Middle Challenge

• Why mid-sized companies (200-1000 employees) face unique coordination challenges
• Too big for startup osmosis, too small for enterprise playbooks
• The need for distributed decision-making without dedicated alignment teams

Two Contrasting Standup Experiences

• NASA JPL: Nightly standups across three time zones that built trust and enabled handoffs
• Medical Startup: Transactional daily standups that created artificial harmony
• What made the difference: optimization for relationship building vs. status updates

The Five Dysfunctions of a Team Framework

1. Absence of Trust - Vulnerability-based trust, not competence trust
2. Fear of Conflict - Artificial harmony vs. productive disagreement
3. Lack of Commitment - What happens when people don't feel heard
4. Avoidance of Accountability - When standards become suggestions
5. Inattention to Results - Individual ego over team success

Three Practical Shifts for Better Rituals

Shift 1: Surface Vulnerability

• Leadership modeling uncertainty first
• Structured moments for admitting what you don't know
• Moving from posturing to problem exploration

Shift 2: Practice Disagreement

• Red team rotations in roadmap reviews
• Making challenge a role, not a personality trait
• Ensuring friction happens constructively in the room

Shift 3: Build Shared Context (Not Just Information)

• The difference between "here's the roadmap" and "here's the trade-off I struggled with"
• Smaller cross-functional context sessions vs. large all-hands presentations
• Enabling distributed decision-making through understanding reasoning

Key Questions for Diagnosis

• How much time was spent on information transfer vs. relationship building?
• Did anyone admit uncertainty without it being a problem?
• Was there constructive disagreement that led to better outcomes?
• Do people understand the reasoning behind decisions, not just the decisions themselves?

Resources Mentioned

• Patrick Lencioni's "The Five Dysfunctions of a Team" (2002)
• Concept of vulnerability-based trust
• Red team methodology for productive conflict

Next Episode Preview

Episode 14: The Product Trio Model - Making it Actually Work in Engineering-Heavy Organizations

Chapters

• 0:00 - The Meeting Problem: Status Theater vs. Real Progress
• 2:20 - The Missing Middle: Mid-Sized Company Challenges
• 4:21 - Tale of Two Standups: NASA vs. Startup
• 11:15 - The Five Dysfunctions Framework
• 16:13 - Three Practical Shifts for Better Rituals
• 23:55 - The Compounding Effect of Trust
• 28:39 - Diagnostic Questions and Next Steps

Episode 12: Why Kubernetes Is Probably Wrong for Your Mid-Sized Company

Key Topics Covered

The Kubernetes Reality Check

• Why most mid-sized companies don't need Kubernetes complexity
• The hidden costs: maintenance, YAML management, and developer experience
• Real-world example from NASA: when impressive engineering doesn't solve business problems

Understanding Kubernetes Context

• Origins from Google's Borg system designed for massive scale
• Core benefits: fault tolerance, auto-scaling, declarative infrastructure
• Why these benefits require significant investment to realize

The Real Downsides

1. Complexity: Even cloud vendors are building products to hide Kubernetes
2. YAML Everything: Config management becomes a people and process problem
3. Cost at Scale: Engineering hours, infrastructure, and mental health costs
4. Developer Experience: High barrier to entry and friction in feedback loops
5. Portability Mirage: Cross-cloud deployment still requires deep vendor knowledge

When Kubernetes Makes Sense

• Genuine scale requirements (dozens/hundreds of services)
• Multiple teams with dedicated platform engineering capacity
• Complex deployment patterns that serve real business needs

Practical Alternatives

• VMs with Docker: Boring is good, boring is maintainable
• Managed Container Services: ECS/Fargate, Cloud Run, Azure Container Apps
• Serverless: Lambda, Cloud Functions for event-driven workloads
• Simple Deployment Scripts: Often cheaper than cluster management

Decision Framework: Do You Actually Need Kubernetes?

1. What specific problem are you solving?
2. Do you have dedicated team capacity?
3. What's your actual scale (services, teams, traffic)?
4. How frequently do you deploy?
5. Have you exhausted simpler options?

Resources Mentioned

• Free Download: "You Actually Need Kubernetes" Checklist (available in show notes)
• Consulting: Concept Cloud - Pragmatic infrastructure decisions for mid-sized companies
• Website: www.conceptcloud.com
• Contact: tom@conceptcloud.com

Next Episode Preview

Episode 13: "Why Your Engineers and Product Managers Still Don't Talk to Each Other (And How to Actually Fix It)"

Engineering Evolved is the podcast for engineering leaders at mid-sized companies who are tired of getting advice that only works for startups or enterprises.

Chapters

• 0:00 - Introduction: The Kubernetes Controversy
• 3:00 - A Personal Story: Getting It Wrong at NASA
• 4:58 - Understanding Kubernetes: Context and Core Benefits
• 7:07 - The Real Downsides: Complexity, Cost, and Developer Experience
• 10:49 - When Kubernetes Actually Makes Sense
• 13:39 - Practical Alternatives to Kubernetes
• 15:51 - Decision Framework: Do You Actually Need It?
• 18:36 - Wrap-up and Next Episode Preview

In this conversation, Tom Barber discusses the challenges organizations face when dealing with legacy systems and the importance of recognizing the human element in system migration. He emphasizes that migration is not just a technical project but a transition that impacts people's identities and roles within the organization.

Takeaways

• Think about your current environment for a second.
• Do you have systems running that are older than some of your engineers?
• Maybe it's that monolithic application written in a language nobody wants to touch.
• Maybe it's hardware that needs special handling.
• Or maybe it's just tribal knowledge locked in the heads of three people.
• Not if, but when, that time comes.
• You can treat it like a purely technical project.
• It's a transition that affects people's identities.
• A transition that affects people's identities, their expertise.
• Their sense of value to the organization.

• (00:00) - Intro
• (00:32) - Title
• (01:16) - The Challenge of Sunsetting Legacy Systems
• (06:11) - Principals for Successful Legacy Migration
• (12:04) - Creating a Culture of Evolution

In this episode of Engineering Evolved, Tom Barber discusses the critical first 90 days of a modernization initiative for engineering directors. He emphasizes that success is not solely about technology but about understanding the business pain, building trust, and navigating organizational dynamics. The episode provides a week-by-week action plan, highlighting the importance of quick wins, effective communication, and avoiding common pitfalls in modernization efforts.

Takeaways

• The first 90 days will make or break your initiative.
• It's about trust, momentum, and not declaring war on allies.
• Understand the business pain that led to your hiring.
• Your job isn't to fix everything but to prove you can be trusted.
• Conduct a 10-day discovery sprint to clarify needs.
• Weeks one and two should focus on listening and mapping.
• Identify a quick win that builds credibility.
• Stay engaged during the execution of the quick win.
• Communicate your vision and reset expectations with leadership.
• Avoid common pitfalls like ignoring the human side of technology.

• (00:00) - Intro
• (00:31) - Title
• (01:13) - The Crucial First 90 Days
• (07:48) - Week-by-Week Action Plan
• (14:10) - Communicating the Vision
• (19:49) - Conclusion and Next Steps

In this conversation, Tom Barber discusses the challenges of managing feature requests and the importance of strategic deployment to enhance team efficiency. He emphasizes the need to prioritize time-consuming tasks to free up valuable hours for the team, ultimately leading to increased productivity without additional hiring costs.

Takeaways

• We are overwhelmed with feature requests.
• Starting with the most time-consuming deployment is crucial.
• Every deployment can save significant time for the team.
• Strategic deployment can lead to substantial time savings.
• Freeing up hours can feel like hiring another engineer.
• Time management is essential in engineering teams.
• Prioritizing tasks can improve overall productivity.
• Efficient deployment processes are key to success.
• Reducing deployment time can enhance team morale.
• Investing in efficiency pays off in the long run.

• (00:00) - Intro
• (00:50) - Title
• (01:33) - Introduction to DevOps ROI Challenges
• (05:29) - Building a Compelling Business Case
• (13:25) - Handling Objections Effectively
• (19:34) - Post-Approval Steps and Checkpoints

In this episode of Engineering Evolved, Tom Barber discusses the critical aspects of cloud migration, emphasizing that many migrations fail due to poor planning and execution. He contrasts successful migrations, like Netflix's, with failures like TSB Bank's, highlighting the importance of treating migration as a product launch. Barber introduces the Strangler Fig pattern as a preferred migration strategy, outlines the six Rs of cloud migration, and stresses the need for effective communication and monitoring during the process. He also provides rollback strategies and discusses the importance of chaos engineering in ensuring resilience against outages. The episode concludes with key principles for successful cloud migration, urging listeners to prioritize discipline over speed.

Takeaways

• Half of all cloud transformations are abject failures.
• Successful migrations treat infrastructure like a product launch.
• Big Bang migrations are no longer viable.
• The Strangler Fig pattern allows for gradual migration.
• Companies should focus on replatforming rather than refactoring.
• Product managers should lead migration efforts, not project managers.
• Rollback strategies are crucial for successful migrations.
• Monitoring during migration is essential to avoid blind spots.
• Communication failures can lead to migration disasters.
• Speed in migration can lead to costly mistakes.

• (00:00) - Intro
• (01:02) - Title
• (01:45) - The Cost of Cloud Migration Failures
• (09:06) - The Six Rs of Application Migration
• (14:21) - Fall Forward Architecture and Recovery Strategies
• (18:54) - Monitoring During Migration
• (28:25) - Communication Strategies for Successful Migration

Takeaways

• Technical debt costs American companies $1.5 trillion annually.
• Most executives are unaware of the impact of technical debt.
• Technical debt is an invisible concept for many organizations.
• C-suite executives often do not understand technical debt.
• Technical debt hides within engineering payroll.
• It contributes to losing deals to faster competitors.
• Technical debt increases risk exposure for organizations.
• It's like a ticking time bomb within companies.
• The consequences of technical debt can be severe.
• Addressing technical debt is crucial for organizational success.

• (00:00) - Intro
• (00:27) - Title
• (01:10) - Understanding Technical Debt
• (09:43) - Revenue Blockers and Their Impact
• (21:18) - Operational Drain: The Hidden Costs
• (27:06) - Catastrophic Risks Of Ignoring Technical Debt

Most midsize companies are making terrible architecture decisions because they're copying Netflix instead of solving their actual problems. This episode cuts through the hype and gives you a practical framework for deciding when you need microservices, when you don't, and everything in between. We talk about why "microservices" is a terrible name that encourages bad decisions, the five factors that should actually drive your architecture choices, and the spectrum of options between monolith and distributed systems that nobody tells you about. Plus, specific signals that tell you when it's actually time to evolve.

In This Episode:

• Why a 12-person team with 47 services is a disaster waiting to happen, and what they did to fix it.
• The naming problem with "microservices" and how chasing "micro" destroys your ability to ship.
• Why that address CRUD service with its own database and deployment pipeline is architectural malpractice.
• The distributed transaction nightmare: how turning a 50-line function into seven networked service calls creates a distributed systems PhD thesis.
• The five-factor framework: team size and structure, deployment frequency and blast radius, data ownership and consistency, independent scalability needs, and technology heterogeneity.
• Conway's Law isn't a suggestion, it's gravity: why your architecture will mirror your org chart whether you want it to or not.
• The rule of thumb for team size: 1-5 engineers means monolith, 5-15 means modular monolith, 15-30 means a few services, 30+ means you can start thinking about real service-oriented architecture.
• Why deploying all 12 services together with the same version number means you have a monolith with extra steps.
• The data partitioning trap: when placing an order requires coordinating across seven services, you've created distributed transaction hell.
• Why "we want to scale differently" usually isn't a good reason to split services, but video transcoding versus API serving actually is.
• The polyglot tax: every additional technology stack means different tools, longer onboarding, harder on-call, and ongoing costs forever.
• The modular monolith: the sweet spot for most midsize teams with strong internal boundaries but simple deployment.
• How to use tools like ArchUnit and dependency-cruiser to enforce module boundaries and make your CI fail when someone violates them.
• The Majestic Monolith plus strategic services pattern: keep the core together, extract two to five services for specific reasons only.
• Self-contained systems: why thinking in complete vertical slices (Customer Portal, Checkout System) beats thinking in technical services (User Service, Order Service).
• The four breaking points that signal it's time to evolve: deploy coordination hell, team bottlenecks, scaling waste, and blast radius pain.
• Why "the code is messy" is a refactoring problem, not an architecture problem, and Shopify ran on a monolith to billions in GMV.
• The hardest lesson: complexity is easy to add, simplicity is hard to maintain.

• (00:00) - Intro
• (00:37) - Title
• (01:19) - Understanding Microservices and Their Misconceptions
• (09:43) - Framework for Architectural Decisions
• (18:54) - Evaluating Factors for Microservices
• (28:22) - Signals for Architectural Evolution

Are your "cross-functional" teams actually just a feature factory in disguise? In this solo deep-dive, I break down the real differences between truly empowered teams and organizations that just reorganized the boxes on an org chart. You'll learn how to measure true cross-functionality, spot the warning signs you're still running a feature factory, and get concrete strategies to transform your teams.

What You'll Learn

The Real Definition of Feature Factory – It's not about org structure; it's about how decisions get made and what gets measured

Five Capabilities That Define True Cross-Functionality:

• End-to-end ownership of customer value streams
• Real decision authority in their domain
• Direct customer access and learning loops
• Complete skill set without external dependencies
• Clear outcomes (not just a backlog)

Eight Red Flags You're Still Running a Feature Factory:

• Your roadmap is a Gantt chart
• Teams are measured on velocity
• Product managers act like project managers
• Engineering estimates drive prioritization
• "Alignment meetings" happen weekly
• Features ship but metrics don't move
• Teams can't say no to stakeholders
• "We can't because..." is a common phrase

Three Frameworks to Measure Cross-Functionality:

• Team Autonomy Audit
• Dependency Debt Score
• Outcome Ownership Matrix

Six Transformation Strategies That Actually Work:

• Start with outcomes, not structure
• Do a dependency purge
• Change what you measure
• Train PMs to be outcome owners
• Create strategic buffers
• Fix your incentives

• (00:00) - Intro
• (00:54) - Title
• (01:36) - Understanding Cross-Functional Teams vs Feature Factories
• (05:54) - Key Characteristics of True Cross-Functional Teams
• (13:26) - Identifying Red Flags of Feature Factories
• (20:01) - Measuring Cross-Functionality in Teams
• (27:09) - Empowering Teams for Success

In this episode, I break down the Product Thinking Framework: a radically different approach to engineering leadership that will change how you think about your team forever.

In This Episode:

• Why most engineering improvements fail (and the shocking similarity to shipping features nobody asked for)
• The uncomfortable truth: Engineering leaders make decisions about tools and processes without understanding what engineers actually need
• Real story: The team drowning in infrastructure that thought they needed more people (spoiler: they didn't)
• Pillar One - Product Discovery for Engineering: How Engineering Office Hours helps you uncover what your team actually needs
• Pillar Two - Customer Empathy: Why you should spend a full day working as an IC on your own team (quarterly)
• Pillar Three - MVP Approach to Infrastructure: How to cut any project down to a 2-4 week learning experiment
• The microservices migration that would have cost millions (and what we did instead)
• The mindset shift: From manager to product manager - falling in love with problems, not features
• Measuring outcomes (shipping speed, learning, enjoyment) not outputs (story points, commits)
• Common objections: "My engineers don't know what they want," "We need long-term thinking," "I don't have time"
• Real results: The team that went from 3-day deployments to 30 minutes without hiring anyone

Key Takeaways:

1. Set up Engineering Office Hours

• One hour per week, open attendance for any engineer
• Focus on discovery, not problem-solving in the session
• Ask: "What's slowing you down?" and dig deeper with "Tell me more"
• Share action items within 48 hours

2. Shadow your engineers quarterly

• Spend a full day working as an IC on your team
• Use their tools, follow their processes, feel their friction
• Every minute of frustration reveals a system problem to fix

3. Cut infrastructure projects into MVP experiments

• Take your biggest project and cut it in half, then half again
• Find something completable in 2-4 weeks that teaches you something
• Focus on learning what you need, not delivering what you planned

4. Measure outcomes, not outputs

• NOT story points, lines of code, or number of commits
• INSTEAD shipping speed, learning rate, work enjoyment, retention
• Sometimes the best way to improve outcomes is to do less

5. Iterate constantly on your team

• Your team is never "finished" - it's a product requiring ongoing improvement
• Always maintain a backlog of team improvements
• Ship small changes frequently vs. big transformations rarely

• (00:00) - Intro
• (01:03) - Title
• (01:45) - Engineering Teams as Products
• (05:32) - Product Discovery for Engineering
• (11:11) - MVP Approach to Infrastructure
• (16:55) - Iterative Improvement in Engineering
• (22:32) - Addressing Common Objections

You'll hear the story of two catastrophic failures: turning atmospheric science research code into a production web portal, and failures with month end reporting systems as a junior developer. They taught me lessons that no certification or consultant ever could.

If you've ever had a "works on my machine" moment turn into a deployment disaster, this episode is for you.

Key Topics Covered

• The MATLAB Trap: Why research code and production code are fundamentally different
• The Spark Mistake: When choosing the "industry standard" technology kills your product
• Product vs Platform: The critical decision that determines deployment success
• The Ego Test: How admitting failure defines modernization leadership
• Four Core Lessons: Future state thinking, maintainability, embracing failure, knowing when to pivot

Key Takeaways

Lesson 1: Always Think About the Future State

Before writing a single line of code, ask: Where will this actually run? Who will maintain it? What happens when things fail? The gap between "works in dev" and "works in production" gets baked in at the architecture stage, not discovered at deployment.

Lesson 2: You Can't Deploy Something Impossibly Hard to Maintain

Elegant architecture means nothing if the team who has to run it can't understand, debug, or update it. Build for the maintainers, not for the architects. Meeting requirements includes sustainability.

Lesson 3: Empower Developers to Test and Embrace Failure

The best modernization teams fail early, fail small, fail visibly, and learn fast. Create realistic test environments. Give permission to break things. Make failure a learning opportunity, not a career-limiting move.

Lesson 4: Know When You're Going Down the Wrong Path—and Admit It

The worst thing in modernization is forcing a bad approach because you're too proud to pivot. Recognize the signs: projects that keep slipping, workarounds that multiply, excuses about the environment. Have the courage to stop, reassess, and choose a different path.

Sometimes the right answer is the simpler tool that works everywhere, not the sophisticated tool that requires expertise to deploy.

• (00:00) - Intro
• (00:00) - Chapter 2
• (01:09) - Titles
• (01:52) - The Dangers of 'It Works On My Machine'
• (07:07) - Lessons from NASA JPL
• (13:06) - The Reality Of Production Environments
• (20:19) - Common Problems in Mid-Sized Companies
• (25:30) - Learning from Failures and Successes

You've achieved product-market fit. You're generating real revenue. You have 200-1000 employees and a tech team of 20-150 engineers. You're not a startup anymore—but you're also not Google.

And you're stuck in hell.

The VP of Engineering reads all the right blogs, follows all the thought leaders, and decides to implement microservices like Netflix. Six months later, deployments take longer, bugs multiply, engineers threaten to quit, and leadership is asking why you just spent half a million dollars to make things worse.

This isn't incompetence. This is the reality of being in the missing middle—too big for startup playbooks, too small for enterprise frameworks.

In this episode, host Tom Barber breaks down:

• The 6 types of debt suffocating your company: code, documentation, process, architecture, testing, and knowledge debt
• Why startup methodologies fail at scale (and destroy your company faster)
• Why enterprise playbooks will kill you just as quickly (change advisory boards, anyone?)
• How to build your own playbook with three critical questions every leader must ask

Stop trying to copy Spotify. Stop implementing frameworks designed for 10,000 employees. Start building systems that match your actual reality.

Perfect for: CTOs, VPs of Engineering, and technical leaders at mid-sized companies who are tired of advice that doesn't fit their world.

• (00:00) - Intro
• (01:01) - Titles
• (01:44) - Techincal Purgatory
• (05:37) - Why Startup Methodologies Fail At Scale
• (12:25) - The Importance Of Documentation And Ownership
• (22:14) - The Pitfalls Of Enterprise Engineering Playbooks
• (30:45) - Building Your Own Playbook