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

WEBVTT
1
00:00:00.380 --> 00:00:12.000
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.
2
00:00:12.100 --> 00:00:19.480
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.
3
00:00:20.960 --> 00:00:33.320
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.
4
00:00:34.280 --> 00:00:42.560
Today, I'm gonna introduce you to a collaboration pattern that doesn't require hiring more people, adding more meetings, or buying another tool.
5
00:00:43.300 --> 00:00:48.320
It's called the Trio Model, and it might be the structural change your organization actually needs.
6
00:00:48.860 --> 00:00:57.780
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.
7
00:01:01.860 --> 00:01:10.380
Welcome to Engineering Evolved, where business meets innovation and technology drives transformation.
8
00:01:10.440 --> 00:01:25.360
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.
9
00:01:25.400 --> 00:01:34.860
From scaling systems and leading teams to aligning engineering with business goals, this is where practical insight meets real-world experience.
10
00:01:35.560 --> 00:01:47.820
Engineering Evolved, guiding today's leaders through the evolution of engineering. Welcome to Engineering Evolved, the podcast for engineering leaders navigating the messy middle.
11
00:01:47.880 --> 00:01:54.740
Companies too big for startup chaos, too small for enterprise bureaucracy. I'm your host, Tom Barber, and this is episode number 14.
12
00:01:56.800 --> 00:02:06.500
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,
13
00:02:07.520 --> 00:02:18.380
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.
14
00:02:18.840 --> 00:02:31.900
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.
15
00:02:31.980 --> 00:02:39.000
And nowhere is that te-- And nowhere is that purgatory more painful than the relationship between business teams and IT.
16
00:02:39.860 --> 00:02:48.060
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.
17
00:02:48.940 --> 00:02:57.880
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.
18
00:02:59.440 --> 00:03:10.720
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.
19
00:03:11.000 --> 00:03:19.140
You just worked around it. Picture this. Requests sitting in backlogs for months because no one has the bandwidth to prioritize them.
20
00:03:19.200 --> 00:03:30.740
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.
21
00:03:31.820 --> 00:03:43.840
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.
22
00:03:44.440 --> 00:03:56.680
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.
23
00:03:58.200 --> 00:04:11.300
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.
24
00:04:11.880 --> 00:04:21.760
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.
25
00:04:22.340 --> 00:04:34.720
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.
26
00:04:34.820 --> 00:04:43.960
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.
27
00:04:44.000 --> 00:04:52.940
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.
28
00:04:53.400 --> 00:05:04.900
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.
29
00:05:05.780 --> 00:05:16.100
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?
30
00:05:17.680 --> 00:05:29.540
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?
31
00:05:30.080 --> 00:05:42.420
Concept Cloud's leading engineers build your startup's prototype without the overhead. Launch faster. conceptcloud.com. Okay. Back to the show.
32
00:05:42.500 --> 00:05:51.840
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.
33
00:05:52.700 --> 00:06:06.580
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.
34
00:06:06.620 --> 00:06:14.780
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.
35
00:06:16.960 --> 00:06:26.460
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.
36
00:06:26.520 --> 00:06:36.640
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.
37
00:06:39.380 --> 00:06:47.500
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.
38
00:06:48.300 --> 00:06:53.880
But there's a famous observation in software engineering that adding people to a late project makes it later.
39
00:06:54.740 --> 00:07:04.740
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.
40
00:07:06.700 --> 00:07:22.780
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.
41
00:07:24.720 --> 00:07:37.620
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.
42
00:07:38.480 --> 00:07:48.380
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.
43
00:07:48.400 --> 00:07:59.620
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.
44
00:08:00.700 --> 00:08:11.220
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.
45
00:08:12.040 --> 00:08:20.220
And because there's now a formal process, people feel less empowered to have hu- the human conversations that might actually resolve things quickly.
46
00:08:20.340 --> 00:08:30.820
The fourth fix, and this is my personal favorite, add more alignment meetings, leadership meetings, planning meetings, status updates, retrospectives,
47
00:08:31.760 --> 00:08:45.070
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.
48
00:08:45.900 --> 00:08:58.520
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.
49
00:08:58.580 --> 00:09:09.450
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.
50
00:09:10.250 --> 00:09:21.980
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.
51
00:09:22.300 --> 00:09:30.120
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.
52
00:09:31.020 --> 00:09:40.880
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.
53
00:09:41.820 --> 00:09:53.520
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.
54
00:09:54.100 --> 00:10:03.700
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.
55
00:10:03.760 --> 00:10:18.700
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.
56
00:10:20.220 --> 00:10:27.660
So what is the trio model? At its core, it's a collaboration pattern built around three roles working together on a defined problem.
57
00:10:28.140 --> 00:10:36.780
Not separate functions coordinating through tickets and meetings, but genuine collaboration. Same room, same goals, same accountability.
58
00:10:38.160 --> 00:10:48.500
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.
59
00:10:49.060 --> 00:11:00.610
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?"
60
00:11:02.940 --> 00:11:12.420
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.
61
00:11:12.460 --> 00:11:22.750
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.
62
00:11:23.520 --> 00:11:33.420
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.
63
00:11:33.720 --> 00:11:43.700
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.
64
00:11:43.900 --> 00:11:56.360
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.
65
00:11:56.480 --> 00:12:09.840
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.
66
00:12:10.952 --> 00:12:22.992
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.
67
00:12:23.192 --> 00:12:33.432
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.
68
00:12:33.472 --> 00:12:44.272
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.
69
00:12:45.592 --> 00:12:59.412
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.
70
00:12:59.852 --> 00:13:12.032
Instead, decision rights are explicitly assigned. The business owner has the final say over customer priorities, what problems we're solving, and for whom.
71
00:13:12.092 --> 00:13:18.652
If there's a question about which customer segment to prioritize or which pain point matters most, the business owner makes that call.
72
00:13:19.512 --> 00:13:28.632
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.
73
00:13:28.712 --> 00:13:34.492
If there's a question about architecture, technology choice, or delivery estimate, the tech lead makes that call.
74
00:13:35.292 --> 00:13:44.352
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.
75
00:13:45.082 --> 00:13:57.152
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.
76
00:13:57.352 --> 00:14:05.952
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.
77
00:14:06.112 --> 00:14:17.252
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."
78
00:14:17.892 --> 00:14:25.592
The tech lead can certainly raise concerns, suggest alternatives, or explain trade-offs, but the business owner is the one with the customer relationship.
79
00:14:26.252 --> 00:14:40.372
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.
80
00:14:40.492 --> 00:14:51.552
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.
81
00:14:52.692 --> 00:15:02.282
If they were, core work would stall because everyone would be in decision meetings instead of doing actual work. Trios are also not permanent.
82
00:15:02.722 --> 00:15:15.332
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.
83
00:15:15.342 --> 00:15:23.372
"We've got a trio for general stuff" is a red flag. What's the specific problem? And what does resolution look like?
84
00:15:24.152 --> 00:15:34.792
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.
85
00:15:35.392 --> 00:15:45.812
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.
86
00:15:46.172 --> 00:16:00.212
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.
87
00:16:00.612 --> 00:16:10.972
Now let's talk about how you actually implement this. First question is which problems warrant a trio? Not everything needs this structure.
88
00:16:11.032 --> 00:16:18.152
If every problem required a trio, you'd have more coordination overhead than actual work getting done, so you need to be selective.
89
00:16:19.832 --> 00:16:32.611
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.
90
00:16:32.932 --> 00:16:41.612
You just go and build it. There are problems with significant cross-functional dependencies where no single team can solve it alone.
91
00:16:41.652 --> 00:16:46.272
If engineering can handle something entirely within their domain, they should just do it.
92
00:16:46.932 --> 00:16:57.452
Trios are for problems that genuin- genuinely require business context, technical capability, and design or operational expe- expertise coming together.
93
00:16:58.912 --> 00:17:05.572
And there are problems of strategic importance, where getting it wrong has meaningful consequences for the business.
94
00:17:06.352 --> 00:17:20.212
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,
95
00:17:21.112 --> 00:17:35.752
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.
96
00:17:35.832 --> 00:17:47.972
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.
97
00:17:49.782 --> 00:18:01.272
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.
98
00:18:01.832 --> 00:18:15.352
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.
99
00:18:17.672 --> 00:18:33.012
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.
100
00:18:34.262 --> 00:18:44.532
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?
101
00:18:45.972 --> 00:18:54.672
If you frame authority as trust divided, you can show executives that granting decisional autonomy leads to fewer escalations and faster learning loops.
102
00:18:55.292 --> 00:19:03.972
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.
103
00:19:05.392 --> 00:19:13.632
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?
104
00:19:14.092 --> 00:19:21.292
This could be daily for high priority, fast-moving project where things are changing quickly. It could be weekly for something more measured.
105
00:19:21.672 --> 00:19:28.072
A long-running trio with a slower moving initiative might only need to m-meet once a month. There's no universal answer.
106
00:19:28.772 --> 00:19:39.872
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.
107
00:19:41.652 --> 00:19:50.192
Most organizational dysfunction stems from ambiguity about who can decide what. The business thinks they can set priorities.
108
00:19:50.752 --> 00:20:02.572
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.
109
00:20:02.692 --> 00:20:16.392
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.
110
00:20:16.992 --> 00:20:33.172
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?
111
00:20:33.812 --> 00:20:41.012
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?
112
00:20:41.312 --> 00:20:50.372
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?
113
00:20:50.812 --> 00:20:58.681
Can they adjust scope, shift timelines, change priorities among items in their domain? And lastly, what must escalate?
114
00:20:59.012 --> 00:21:12.772
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.
115
00:21:12.992 --> 00:21:25.372
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.
116
00:21:25.432 --> 00:21:39.592
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.
117
00:21:40.252 --> 00:21:50.532
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.
118
00:21:52.032 --> 00:22:06.932
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.
119
00:22:06.952 --> 00:22:20.892
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.
120
00:22:22.052 --> 00:22:28.952
The business wants features shipped fast because there's a revenue opportunity. IT wants to build it right because there's a stability risk.
121
00:22:29.452 --> 00:22:41.912
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.
122
00:22:42.092 --> 00:22:59.012
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.
123
00:22:59.262 --> 00:23:08.182
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."
124
00:23:08.332 --> 00:23:17.092
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.
125
00:23:17.292 --> 00:23:21.982
A trio needs at least one shared outcome metric that all members are accountable for.
126
00:23:23.232 --> 00:23:31.532
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.
127
00:23:31.572 --> 00:23:48.252
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.
128
00:23:48.822 --> 00:24:01.752
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.
129
00:24:02.332 --> 00:24:14.172
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.
130
00:24:14.672 --> 00:24:27.996
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.
131
00:24:28.416 --> 00:24:43.956
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.
132
00:24:43.996 --> 00:25:01.756
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.
133
00:25:02.316 --> 00:25:19.996
Concept to Cloud builds startup MVPs that perform. concepttocloud.com. All right.
134
00:25:20.036 --> 00:25:30.166
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.
135
00:25:30.646 --> 00:25:39.036
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.
136
00:25:39.196 --> 00:25:50.476
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.
137
00:25:51.016 --> 00:26:00.896
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.
138
00:26:02.116 --> 00:26:09.636
Stop sending urgent requests directly to IT that bypass the trios. Every single time you do this, you undermine the model.
139
00:26:10.376 --> 00:26:22.396
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.
140
00:26:22.436 --> 00:26:35.096
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.
141
00:26:35.176 --> 00:26:44.676
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.
142
00:26:44.816 --> 00:26:54.546
Legitimately urgent requests will come in that need to be actioned immediately. Security vulnera- v- security vulnerabilities, critical bugs, regulatory deadlines.
143
00:26:55.606 --> 00:27:09.336
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.
144
00:27:11.816 --> 00:27:17.276
Stop letting business leaders commit to timelines without technical input, and I cannot stress this enough.
145
00:27:17.496 --> 00:27:25.196
If a sales team promises a feature by Q3 without talking to engineering, you've broken the system before it even starts.
146
00:27:25.896 --> 00:27:36.016
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...
147
00:27:36.156 --> 00:27:45.016
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.
148
00:27:46.386 --> 00:28:03.136
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.
149
00:28:03.216 --> 00:28:17.296
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
150
00:28:18.856 --> 00:28:28.756
that a survey of over 3,000 developers found that organizational culture, sense of belonging, and work satisfaction are directly associated with reduced burnout.
151
00:28:29.996 --> 00:28:43.396
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.
152
00:28:44.416 --> 00:28:55.136
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.
153
00:28:55.696 --> 00:29:03.156
That means giving people uninterrupted time for deep work. And that means not treating every hour of every day as available for meetings.
154
00:29:04.716 --> 00:29:15.176
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.
155
00:29:15.596 --> 00:29:18.756
It's not purely an engineering function that causes failure.
156
00:29:19.456 --> 00:29:29.646
It can be a lack of specification, inaccurate s- scoping, changing requirements mid- midstream, or unrealistic expectations that were set before engineering was consulted.
157
00:29:32.676 --> 00:29:46.656
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.
158
00:29:47.576 --> 00:29:59.356
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.
159
00:29:59.516 --> 00:30:04.656
Don't try to roll out trios across your entire organization at once. That's a recipe for chaos.
160
00:30:04.696 --> 00:30:16.636
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.
161
00:30:17.036 --> 00:30:20.516
Look for places where business and IT currently are butting heads.
162
00:30:21.052 --> 00:30:32.632
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.
163
00:30:32.672 --> 00:30:42.752
And here's the process. Firstly, clearly define the problem that the trio is solving. Not vaguely, but specifically. What outcome will indicate success?
164
00:30:43.172 --> 00:30:54.772
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.
165
00:30:55.272 --> 00:31:07.592
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.
166
00:31:08.192 --> 00:31:21.032
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.
167
00:31:22.102 --> 00:31:28.472
Then run it for a quarter. See what breaks and iterate over it. This isn't an overnight transformation.
168
00:31:28.512 --> 00:31:37.032
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.
169
00:31:37.632 --> 00:31:51.152
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.
170
00:31:51.222 --> 00:31:55.872
And if you don't get that buy-in, particularly from senior leadership, you will not succeed.
171
00:31:57.992 --> 00:32:08.292
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.
172
00:32:08.912 --> 00:32:21.712
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.
173
00:32:23.272 --> 00:32:33.152
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?
174
00:32:33.872 --> 00:32:45.832
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.
175
00:32:45.912 --> 00:32:55.992
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.
176
00:32:57.692 --> 00:33:06.992
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.
177
00:33:07.892 --> 00:33:15.372
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.
178
00:33:15.852 --> 00:33:25.712
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.
179
00:33:27.532 --> 00:33:39.372
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.
180
00:33:39.912 --> 00:33:56.372
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.
181
00:33:56.912 --> 00:34:06.862
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.
182
00:34:10.332 --> 00:34:22.552
From idea to investor demo in weeks, not months. Concept to Cloud, world-class engineers accelerating startup success. ConcepttoCloud.com.