The Trio Model: Breaking Down Business-IT Walls for Better Engineering Collaboration

Here's a question that keeps engineering leaders up at night. Why does it feel like your business and IT teams are playing perpetual game of hot potato with blame? The business says IT can't deliver. IT says business can't prioritize. And meanwhile, customers are wondering why that feature they asked for six months ago is still in the backlog.

I've sat in rooms where the tension between these groups was so thick you could cut it with a knife, where every status meeting felt like a trial, with each side presenting evidence for why the other was responsible for the latest delay. Today, I'm gonna introduce you to a collaboration pattern that doesn't require hiring more people, adding more meetings, or buying another tool. It's called the Trio Model, and it might be the structural change your organization actually needs. But fair warning, this only works if leadership is willing to change their behavior, not their staff's behavior, their own. Let's get into it.

Welcome to Engineering Evolved, where business meets innovation and technology drives transformation. Each episode, your host, Tom Barber, explores the challenges and opportunities facing the organizations in the middle, the forgotten ground where startup rules no longer apply and enterprise playbooks are far too large. From scaling systems and leading teams to aligning engineering with business goals, this is where practical insight meets real-world experience. Engineering Evolved, guiding today's leaders through the evolution of engineering. Welcome to Engineering Evolved, the podcast for engineering leaders navigating the messy middle.

Companies too big for startup chaos, too small for enterprise bureaucracy. I'm your host, Tom Barber, and this is episode number 14. If you're leading engineering at a company somewhere between two hundred and one thousand employees, you know exactly what I'm talking about. You've outgrown the everyone talks to everyone phase, but you haven't yet built the infrastructure of a Fortune five hundred company. You're stuck in what I call technical purgatory.

You can't just walk over to someone's desk and hash things out anymore. There are too many people, too many priorities, too many competing demands. But you also don't have dedicated program managers, robust governance frameworks, or the budgets to throw bodies at coordination problems. And nowhere is that te-- And nowhere is that purgatory more painful than the relationship between business teams and IT. Today, we're diving deep into the Trio Model, what it is, what it isn't, and most importantly, how to actually make it stick in your organization.

I'll share the specific questions you need to answer before implementing it, the leadership behaviors that will make or break it, and a realistic starting point you can try this quarter. So I want to start with a confession. I've been part of organizations where this dysfunction was so deeply embedded that it felt like the natural order of things, like gravity. You didn't question it. You just worked around it.

Picture this. Requests sitting in backlogs for months because no one has the bandwidth to prioritize them. Not because work isn't important, but because there are seventeen other things that are also important. And the people who could make the call are too busy fighting fires to step back and actually make decisions. Then you've got the urgent escalations.

And somehow every escalation is urgent. Every request is ti- critical. Every stakeholder is the most important stakeholder. I remember one organization where I counted, in a single week, eleven different requests that came through as top priority. Eleven top priorities.

That phrase stops meaning anything when you use it that way. Business teams, frustrated by what they perceive as IT's inability to li- deliver, start building their own shadow solutions. Spreadsheets become databases. Personal Dropbox accounts become document management systems. Someone's nephew builds a little access database.

It suddenly becomes business critical. And then IT isn't just playing catch up. They don't even know what they're supposed to be catching up to. They're discovering systems they didn't know existed when some systems break. Meanwhile, the engineers feel like they're reduced to order taking function.

No autonomy, no input on what should be built or why. Just a queue of tickets and a deadline that ha- they had no part in setting. I've talked to so many engineers who describe this as demoralizing. They've got into the field because they wanted to solve problems, and instead they're just executing instructions that sometimes don't even make sense to them. Here's what's interesting.

Not every organization operates this way. I've also been part of teams where business and IT work together beautifully, where there was genuine partnership, mutual respect, and shared accountability. So the question isn't whether the dysfunction is inevitable. It isn't. The question is, how do you recover from it when it's already set in, and how do you prevent it from creeping back?

That's what led me to study the Trio Model, because the usual fixes, they don't work. Let me tell you why. First, a quick word from our sponsor. Why hire when you can partner? Concept Cloud's leading engineers build your startup's prototype without the overhead.

Launch faster. conceptcloud. com. Okay. Back to the show.

Let me walk you through the standard playbook that most organizations try when business IT alignment breaks down. I've seen all of these attempted, and I've seen all of them fail. First fix, hire more managers or engineers. The thinking goes, we have a communication problem, so we need more people to communicate. Sounds logical, right?

But here's the issue. You're adding people who lack context. They don't know the history of why certain decisions were made. They don't know the relationships, the informal power structures, the unwritten rules. They don't know that Sarah in finance and James in engineering haven't spoken since that incident two years ago, and now they're supposed to bridge a gap they don't fully understand.

What you've done is increased your salary costs without addressing the underlying dysfunction. You've added another layer of abstraction between the people with the problems and the people who can solve them. Second, like I mentioned, you could hire more engineers. We can't deliver fast enough, so let's add capacity. This one feels intuitive.

If you're behind, add more people. But there's a famous observation in software engineering that adding people to a late project makes it later. And more broadly, more engineers without alignment just means more code that may or may not solve the right problems. You're optimizing for output when the real issue is direction. I've seen teams, I've seen teams double their engineering headcount and actually slow down because you've now got twice as many people who need to coordinate, twice as many people who need context, twice as many people asking questions about requirements that were never clearly defined in the first place.

The third to fix, attempted fix, is implement better ticketing and prioritization systems. Now, I'll grant you, this can help with visibility. Having a qui- clear queue and defined priorities is better than chaos. If you're currently operating in the whoever shouts the loudest gets attention model, a ticki- a ticketing system is an improvement. But a ticketing system doesn't fix misalignment.

It just makes the lit- misalignment more visible. You can have a perfectly prioritized backlog of the wrong things, a beautiful Kanban board of all the features that don't actually matter. The tickets flow smoothly from left to right, and at the end, you've shipped something nobody wanted. The system becomes a crutch. "Well, it's in the backlog" becomes an excuse rather than a commitment.

And because there's now a formal process, people feel less empowered to have hu- the human conversations that might actually resolve things quickly. The fourth fix, and this is my personal favorite, add more alignment meetings, leadership meetings, planning meetings, status updates, retrospectives, pre-mortems, post-mortems, sync meetings, async catch-ups, stand-ups, sit-downs. Pretty soon, your engineers are spending more time in meetings talking about the work than actually doing the work. And here's what happens in those meetings. They become what I call status theater.

Everyone's performing for each other. Stakeholders are trying to make their requests sound more important than everyone else's. Engineers are trying to explain why things are taking so long without sounding like they're making excuses. Managers are trying to look like they've got everything under control, and nothing actually gets decided. I've sat in two-hour alignment meetings where we went around the room, everyone gave their update, and at the end, they were no more aligned than when we started.

We'd shared information. We hadn't made decisions. We hadn't resolved conflicts. We just talked at each other for two hours and then gone back to doing exactly what we were doing before. The core issue with all of these fixes is they treat business and IT as separate entities that hand work back and forth rather than partners who solve problems together.

You've got a wall between them, sometimes a literal one, sometimes an organizational one, and these fixes are all about making it easier to throw things over that wall. Better ticketing. That's a nicer catapult for throwing requests over. More meetings. That's a regularly scheduled time to throw things back and forth.

More managers. That's more people standing at the wall, catching things and throwing them to the other side. What if you just, how do I put this? Removed the wall, and that's the paradigm shift the trio model demands. So what is the trio model?

At its core, it's a collaboration pattern built around three roles working together on a defined problem. Not separate functions coordinating through tickets and meetings, but genuine collaboration. Same room, same goals, same accountability. In a typical engineering focal o- focused organization, a trio might look like this. First, you have a business owner.

This is the person who owns the problem and the customer relationship. They understand what the customer needs and why it matters to the business. They can answer the question, "Why are we doing this? " And, "What does success look like for people we're serving? " Second, you have the technical lead.

This person owns feasibility and implementation. They know what's possible, what's practical, and how long things will actually take. They can answer questions like, "How do we build this? " and, "What are the technical trade-offs? " Third, you have a designer, analyst or ops lead, something along those lines, depending on the problem type.

If you're building a customer-facing product, maybe it's a designer who optimizes for user experience. If you're improving a business process, maybe it's a business analyst. If you're tackling an operational challenge, maybe it's an ops lead. This person optimizes for their domain's excellence. Now, here's what's crucial to understand.

The trio enables co-ownership of outcomes, not just handoff of tasks. This isn't about the business overwriting requirements, throwing them to the tech lead and waiting for delivery. This is about all three people being in a room together, literally or figuratively, working through the problem jointly, understanding the constraints together, making trade-offs together, owning the outcome together. Let me be very clear about what the trio is not. It is not a committee.

It does not vote on things. It doesn't require consensus for every de- decision. It's not an approval layer. It's not there to sign off work, on work that other people do. It's there to work on the alignment and the decision-making itself.

It's not there to oversee. It's there to bring the right people together before decisions are made, not after. If you're using the trio to review and approve decisions that have already been made elsewhere, you're doing it wrong. It's also not consensus-driven. Three people doesn't mean three votes.

And this is where a lot of organizations get it wrong. They hear trio and think everyone has to agree, but that is a recipe for gridlock. Instead, decision rights are explicitly assigned. The business owner has the final say over customer priorities, what problems we're solving, and for whom. If there's a question about which customer segment to prioritize or which pain point matters most, the business owner makes that call.

The technical lead makes the call on the feasibility and the implementation, whether something can be built, how it should be built, and what the realistic timeline is. If there's a question about architecture, technology choice, or delivery estimate, the tech lead makes that call. The third member decides how to optimize their domain, whether that's user experience, business process design, or operational efficiency. And here's the key. The tech lead cannot be vetoed by the business owner on the technical feasibility.

If a tech lead says, "This will take six months," the business owner doesn't get to say, "Make it three. " That's not how physics works. That's not how software development works. Pressuring engineers to commit to timelines they know are unrealistic is how you get burned-out teams and failed projects. Similarly, the business owner can't be overruled on customer needs.

If they say, "This is what customers are asking for," the tech lead doesn't get to say, "Well, customers are wrong. " The tech lead can certainly raise concerns, suggest alternatives, or explain trade-offs, but the business owner is the one with the customer relationship. This clear assignment of decision rights prevents gridlock and ensures each key area is covered. One more thing, the trio is not the entire delivery team. They make directional and trade-off decisions.

They don't execute all the work themselves. The trio sets the direction. The broader team delivers on it. In a ten to fifteen person IT organization, not everyone can be in a trio. If they were, core work would stall because everyone would be in decision meetings instead of doing actual work.

Trios are also not permanent. They form around defined pro- problems and disband when those problems are resolved. Assigning people to trios without clear problems just creates, recreates the committees you are trying to avoid. "We've got a trio for general stuff" is a red flag. What's the specific problem?

And what does resolution look like? And a warning I want to po- plant in your mind right now, "The trio owns it" can quickly become "No one owns it. " Shared outcomes don't mean shared responsibility for everything. Each role still has distinct accountability. The business owner is accountable for understanding customer needs correctly.

The tech lead is accountable for accurate feasibility assessment. The third member is accountable for their domain. Shared ownership of the outcome doesn't mean you can point at someone else when your part goes wrong. [clears throat] All right, so you understand this concept. Now let's talk about how you actually implement this.

First question is which problems warrant a trio? Not everything needs this structure. If every problem required a trio, you'd have more coordination overhead than actual work getting done, so you need to be selective. Good candidates for a trio are problems with high ambiguity, where the solution isn't obvious and requires cross-functional input. If you already know exactly what to build and how to build it, you don't need a trio.

You just go and build it. There are problems with significant cross-functional dependencies where no single team can solve it alone. If engineering can handle something entirely within their domain, they should just do it. Trios are for problems that genuin- genuinely require business context, technical capability, and design or operational expe- expertise coming together. And there are problems of strategic importance, where getting it wrong has meaningful consequences for the business.

Minor features, routine maintenance, incremental improvements, these don't need the heavyweight coordination of a trio. So what doesn't need a trio? Well-defined requests where the path forward is clear. For example, business' usual work that's following established patterns. Pure technical debt that can be handled within a single engineering stream.

Bug fixes. Standard operational tasks. The tricky part is preventing scope creep. Every business stakeholder wants their engineer in a trio. If you let that happen, though, you will end up with too many trios and not enough people to do the actual work.

Leaders need to be disciplined about this. So I recommend a lightweight quarterly revie- review of trio assignments and resources. Look at how many trios you have active. Look at how they're distributed across your technical staff. Too many trios spread technical people thin.

Too few create co- confusion and inertia. People don't know where decisions get made. Balance isn't a one-time fix. It's an ongoing practice that requires attention. Now, let's talk about meeting cadence.

Actually, scratch that. Let's talk about what really matters, which is authority. So here's something I learned. C-suite execs don't actually care about the meeting frequency. They may say they do, but they really don't.

They care about outcomes. Specifically, they care about will this create more meetings that waste time or fewer escalations that waste my time? If you frame authority as trust divided, you can show executives that granting decisional autonomy leads to fewer escalations and faster learning loops. Every time the trio can make a decision without bumping it upstairs, that's time saved for everyone. It's a strategic investment, not a risk.

The real cadence question, though, is what can the trio decide without asking permission, and how often do they need to meet to exercise that authority? This could be daily for high priority, fast-moving project where things are changing quickly. It could be weekly for something more measured. A long-running trio with a slower moving initiative might only need to m-meet once a month. There's no universal answer.

It depends on the pace of the work and the scope of the decisions that the trio is empowered to make. Now, here's the load-bearing section of this whole episode, which is decision rights. Most organizational dysfunction stems from ambiguity about who can decide what. The business thinks they can set priorities. IT thinks they're drowning in competing priorities with no clear ranking because everything comes in super urgent.

Both are frustrated because they have different understanding of who's supposed to be doing what. IT thinks they're empowered to push back on bad ideas. The business thinks it's IT's job to execute whatever comes in, and that IT is being a restrictionist on purpose. Again, different understandings of decision rights. And nobody, literally nobody, knows who can say no to the CEO's pet project.

So, the trio model only works if you can explicitly answer these questions. Who can green-light work entering the trio scope? If anyone can dump work on the trio, you haven't actually solved anything. Who can kill or de-scope work that's not feasible? And this is often the hardest one, because who has the authority to say, "We are not doing this"?

What trade-offs can the trio make without escalation? Can they adjust scope, shift timelines, change priorities among items in their domain? And lastly, what must escalate? Budget thresholds befa-beyond a certain amount, timeline changes beyond a certain point, scope changes above a certain magnitude. You need bright lines.

Here's a test that I like to use. Can your trio members summarize their escalation rules in one tweet? Something like, "Only the tech lead can veto feasibility. Business owner has final say on customer prior-priorities. Anything over fifty K or three-month delay goes to steering.

" If they can't do that, if there's basic hesitation or disagreement, you've got linger, l-- you've got lingering ambiguity that will fuel dysfunction. If you don't answer these questions and make them prescriptive, you'll end up with the same bottlenecks you have now, just with a new name. You'll have replaced vague dysfunction with trio-shaped dysfunction. So let's talk about how you measure success with a trio, and this gets a fundamental problem with how most organizations think about accountability. The classic setup measures IT on delivery velocity and system uptime.

It measures business on reveu-revenue and customer outcomes. Makes sense on paper. Each group has metrics that reflects their contribution, but these metrics can often point in the opposite direction. The business wants features shipped fast because there's a revenue opportunity. IT wants to build it right because there's a stability risk.

If you measure business on feature delivered by Q2 and IT on system uptime above ninety-nine point nine percent, you've created a structural conflict. Shipping fast might compromise stability. Building stable might miss the deadline. Both sides are rationally pursuing their incentives, and those is-incentives are fighting each other. [clears throat] If the metrics aren't shared, the trio becomes adversarial.

The business owner pushes for speed. "We need to do this feature yesterday. " The tech lead pushes for quality. "We need more time to do this right. " And the third person picks a side or checks out entirely because they don't want to be caught in the crossfire.

And this is clearly suboptimal, to put it mildly. A trio needs at least one shared outcome metric that all members are accountable for. Not IT delivered on time and the business adopted it, but rather, this problem got solved, and here's how we're measuring it as a team. The trio should rally around customer-centric metrics, things like customer satisfaction scores, net promoter score, time to market for customer-facing value, defect rate from the customer's perspective, adoption rates, usage metrics. These are tangible goals that all trio members can collectively work to improve, and they require all three functions to be successful.

If customer satisfaction drops, all three need to figure out why. Was it the wrong feature? That's the business owner territory. Was it poorly im-implemented? That's the tech lead's territory.

Was it hard to use? That's the designer's territory. But the trio collectively owns the outcome of customer satisfaction. And this shared metric is what's get, get, is... And this shared metric is what gets reported up the chain to the C-suite executives.

Not IT did their part and business did their part, but we as a trio achieved this outcome together. This translates shared outcomes into concrete action and collective accountability. When you succeed, you succeed together. When you fail, you figure out why together, not point fingers at each other. And now a word from our sponsor.

The same minds that worked on the last Mars rover now work on yours. Concept to Cloud builds startup MVPs that perform. concepttocloud. com. All right.

Welcome back. This is where I need to tell you the uncomfortable truth. All of that structural stuff I just described, it will fail if leadership doesn't change. This is the single biggest reason why process improvements don't stand the test of time. We implement new structures, new frameworks, new ways of working.

We train people, we adjust incentives, and then six months later, we're back to the old dysfunction, just with a new vocabulary. Why? Because leadership is the one unwilling to change. Not the ground level staff implementing these patterns. The staff adapt.

Leadership defaults to old habits when under pressure. So let me be direct about what needs to stop. Stop sending urgent requests directly to IT that bypass the trios. Every single time you do this, you undermine the model. You're telling your, your organization the trio process is fine for normal work, but when something really matters, we skip it.

Which means everything that really matters, we'll skip it. Which means the trio process will only handle things that don't really matter. Which means the trio process is pointless. If every request is urgent, there's no way for IT to prioritize. You've essentially told them that the trio's decisions don't matter when it's inconvenient for you.

The business also needs to accept that sometimes deliveries will get pushed out. Legitimately urgent requests will come in that need to be actioned immediately. Security vulnera- v- security vulnerabilities, critical bugs, regulatory deadlines. These have a knock-on effect on everything else in the pipeline. The trio makes the call on how to handle the trade-off.

It's not IT being slow. That's prioritization in action. That's the system working. Stop letting business leaders commit to timelines without technical input, and I cannot stress this enough. If a sales team promises a feature by Q3 without talking to engineering, you've broken the system before it even starts.

There's no guarantee that the people doing the implementation can adhere to those timelines given their existing workload and delivery schedule. You're setting everyone up to fail. The team... The sales team who made the promise, the customer who believed it, and the engineering team who now has to either kill themselves to meet it or take the blame for missing it. The trio is where the timeline discussion happens.

Not in the sales calls, not in the executive off-sites. In the trio where all the relevant information exists. So protect trio time. I cannot stress this enough. If your 10-person IT team is running 15 trios, plus business as usual support, plus handling incidents, you don't have a trio model, you have a burnout model.

Research has shown that a survey of over 3,000 developers found that organizational culture, sense of belonging, and work satisfaction are directly associated with reduced burnout. When everyone is spread across too many trios, constantly context switching, trying to plan whilst also developing and supporting existing systems, you're creating the exact conditions that drive talented people out of your organization. If you care about retention, and you should, because replacing engineers is expensive and disruptive, you need to protect focus time. That means limiting the number of trios. That means giving people uninterrupted time for deep work.

And that means not treating every hour of every day as available for meetings. Finally, hold the business owners accountable for outcomes, not just the engineers. If a project fails, the business sponsors should be in that postmortem. They're part of the chain. It's not purely an engineering function that causes failure.

It can be a lack of specification, inaccurate s- scoping, changing requirements mid- midstream, or unrealistic expectations that were set before engineering was consulted. If we always assume that business is right and IT is wrong, you'll forever be in a spiral of finger-pointing with IT taking the blame, and good engineers will leave because they don't want to work somewhere that scapegoats them for failures they couldn't prevent. This is where you earn trust as a leader, not by telling your teams what to build, but by changing what you personally stop doing. All right. Let me give you something actionable to walk away with.

Don't try to roll out trios across your entire organization at once. That's a recipe for chaos. You'll overwhelm people, create confusion, and probably trigger antibodies for people who've seen too many transformation initiatives. Instead, pick one or two high-value, high-friction problem areas. Look for places where business and IT currently are butting heads.

Where there's visible frustration on both sides and where projects have stalled or failed due to misalignment, where the same arguments keep happening over and over. Form trios around these specific problems. And here's the process. Firstly, clearly define the problem that the trio is solving. Not vaguely, but specifically.

What outcome will indicate success? What are you trying to achieve and how will you know when you've achieved it? Second, assign clear roles to each trio member. Make sure everyone understands their responsibilities and decision rights. Write it down.

Make it explicit. Use the one tweet test. Third, establish specific metrics to measure success. Customer satisfaction, time to market, whatever makes sense for the problem. Make sure it's a shared metric that all three members are accountable for.

Fourth, schedule a review after one quarter to assess performance. Identify what's working and what's not. Make adjustments. Then run it for a quarter. See what breaks and iterate over it.

This isn't an overnight transformation. It's not going to suddenly fix your organization, but it will enable more direct communication and allow multiple groups to take shared responsibility for outcomes. Requirements don't just get chucked over a wall anymore and everyone has a stake. I want to acknowledge this is hard. It takes longer than you'd like and it requires buy-in across the organization.

And if you don't get that buy-in, particularly from senior leadership, you will not succeed. But the difference between a real fix and what I call shelf wear, where you try something for a week, decide it doesn't work and chuck it on the shelf, is sustained commitment. Real change isn't easy. It takes courage to step out of the comfort zone, to change your own behavior, to hold yourself accountable for enabling rather than undermining the new way of working. Let this be a call to that courage.

Here's my question for you this week. When in your organization is the business IT blame game most visible and what would it look like to form a trio around that specific friction point? I'm not asking you for you to overhaul your entire structure. I'm asking you to try it once, pick one problem, form a trio and just see what happens. And if you do try it, I genuinely want to hear how it goes.

Drop me a message on LinkedIn or send me an email. Tell me what worked and what didn't and what surprised you. These real world experiences help me make this show more useful for everyone. If you found this episode useful, please share it with another engineering leader who's dealing with that business IT tug of war. Word of mouth is how shows like this one grow.

And if you haven't already, subscribe wherever you get your podcasts so you don't miss what's coming next. Reviews always help more than you might think. They help other leaders in the messy middle find out what's going on in the real world. If you've got two minutes to leave a review, I would really appreciate it. Coming in the next episode, we're tackling the topic that's directly related to what we discussed today, how to run postmortems that actually lead to improvement instead of just becoming another blame game in disguise.

Until then, I'm Tom Barber. Thanks for listening to Engineering Evolved. Thanks for listening to Engineering Evolved with Tom Barber, where ideas meet innovation and leadership drives change. If you enjoyed today's episode, please leave a rating and review wherever you listen. It helps more leaders discover the show and keeps the evolution moving forward.

From idea to investor demo in weeks, not months. Concept to Cloud, world-class engineers accelerating startup success. ConcepttoCloud. com.