From Finger-Pointing to Shared Ownership
Making product trios work when your engineering team is undersized and underwater
A Familiar Dysfunction
In many organisations, a core issue is the persistent misalignment between business objectives and IT capabilities. Picture a business racing ahead so quickly that no one has time to tackle bigger-picture problems. Imagine, however, if those efforts were channeled toward creating shared customer value, not just managing internal efficiencies. IT often becomes a bottleneck, overwhelmed by competing requests and tasks, making prioritization nearly impossible. The result? Frustrating finger-pointing all around when that energy could be harnessed to enhance essential work and improve alignment across the organization. By focusing on a cohesive path to meet customer needs, the Trio model can transform frustration into collaborative success.
In several organisations I’ve worked in, requests stay in backlog for months due to a lack of prioritisation bandwidth. Frequent urgent escalations, often self-serving, derail progress and force immediate attention. Business teams bypass IT using shadow solutions, lacking confidence in IT delivery. Meanwhile, IT feels reduced to an order-taking role rather than an autonomous, decision-making organisation.
Not all organisations operate this way, but high-pressure environments can slip into these habits unnoticed. Recovering requires both awareness and courage to rebuild effective, aligned collaboration.
Why the Usual Fixes Fail
The core issue: business and tech are structured as separate entities that hand work back and forth, rather than solving problems together.
So, of course, what you then end up with is a list of things you’ve probably already tried:
Hiring more managers
Hiring more engineers
This approach doesn’t fix misalignment; it adds more people who lack context and increases salary costs without resolving core issues. Extra alignment meetings often waste engineering hours through ‘status theatre.’ Quantifying this lost productivity can underscore the urgent need for change.
Next comes the problem of ticketing and prioritisation. This helps some symptoms and increases visibility if managed properly. But it does not address the chaos itself.
You then add more alignment meetings with leaders, developers, product managers, and engineers. These meetings become status theatre, with participants seeking to outdo one another, leading to team-wide frustration and problems.
This repeated separation of business and tech creates recurring misalignment and unresolved problems instead of joint solutions.
The Trio Model - What It Is and What It Isn’t
Today I want to talk about the Trio model. For anyone who doesn’t understand what this is, it’s a collaboration pattern about three different parts of the organisation working together. In an engineering light organisation, you may end up having a slightly different trio than the general trio, but let’s take, for example, a light org where you might end up with:
• A business owner (this person would own the problem and the customer relationship)
• A technical lead who owns the feasibility and implementation (probably working as an IT engineer)
• A designer or an analyst or an ops lead (it sort of depends on the problem type)
These people are expected to work together to enable co-ownership of outcomes, not just a hand-off of tasks. The Trio should rally around customer-centric metrics such as customer satisfaction, net promoter score, time-to-market, or defect rate—tangible goals all Trio roles can collectively strive to improve, translating shared outcomes into concrete action.
Of course, the Trio isn’t a committee or approval layer. It’s not there to oversee but to bring the right people together before decisions are made—not after. It’s also not consensus-driven: three people don’t mean three votes. Instead, decision rights are explicitly assigned: the business owner has final say over customer priorities, the technical lead makes the call on feasibility and implementation, while the designer, analyst, or ops lead decides how to optimise the user experience, business process, or operations, depending on the issue. The tech lead cannot be vetoed by the business owner on technical feasibility, nor can the business owner be overruled on customer needs. Clear assignment of decision rights prevents gridlock and ensures each key area is covered. It is important to note that the trio is not the entire delivery team. They make directional and trade-off decisions—they do not execute all the work themselves. In a 10-15-person IT organisation, not everyone can be in a trio; otherwise, core work would stall.
Trios are not permanent—they form around defined problems and disband when those problems are resolved. Assigning people to trios without clear problems only recreates unnecessary committees, which this approach avoids.
A warning: ‘the trio owns it’ can quickly become ‘no one owns it.’ Each role still has distinct accountability. While there is a shared outcome, each person has specific responsibilities.
Making It Work: The Structural Stuff
So, of course, the question is: which problems actually warrant a TRIO, and which should just be dealt with in the usual manner? This normally falls into several categories.
Often, the projects warranting a TRIO are ones where you’ve either got high ambiguity, cross-functional dependencies, or strategic importance, or maybe a combination of all three.
What often doesn’t require a TRIO are well-defined requests, business-as-usual work, and pure technical debt that can be dealt with via a single stream.
Because what the leaders also need to figure out is how to prevent every business stakeholder from demanding their engineer in a TRIO, because that then ends up, as mentioned earlier, with a lot of people in TRIOs and no one to actually do the work.
Too many Trios spread technical people thin; too few create confusion and inertia. Balance isn’t a one-time fix. Leaders should make trade-off decisions a regular practice. A lightweight quarterly review of Trio assignments and resources helps sustain balance and builds leadership strength, ensuring strategic and operational goals are met.
Finding balance here is challenging.
The next question is about meeting cadence, but the real question here is authority. C-Suite execs tend not to really care about meeting frequency, except that it gives the optics of productivity without necessarily being productive. What they actually care about is: “Will this create more meetings that waste time or fewer escalations that waste their time?” By framing authority as a trust dividend, you can link decision autonomy to fewer escalations and faster learning loops. This perspective encourages executives to see granting authority as a strategic investment rather than a risk, fostering a more efficient and responsive organisation.
The answer depends on whether the Trio has the authority to decide. If every call goes up the chain for approval, the Trio becomes just another layer. The real cadence question is what the Trio can decide without asking permission, and how often they need to meet to exercise that authority. This could be daily, a few times a week, or weekly. The Trio’s priority matters, too. A long-running Trio may only need to meet once a quarter, and that can work.
As we talk about decision rights, this is the load-bearing section of making it work. Most organisational dysfunction stems from ambiguity. The business thinks that they set priorities. IT thinks they’re drowning in competing priorities with no clear ranking because everything comes in super urgent. IT thinks they’re empowered to push back on bad ideas. The business thinks it’s IT’s job to execute whatever ideas come in and that IT’s being obstructionist on purpose. No one knows who can say no to the CEO’s pet project. The trio model only works if you can explicitly answer these questions: Pose the ‘Who says no?’ test. Challenge your team to summarize their trio’s escalation rules in one tweet. For instance, ‘Only the Tech Lead can veto based on feasibility; Business Owner has final say on customer priorities.’ This brevity test often exposes lingering ambiguity that fuels dysfunction.
Who can green-light work entering the trio’s scope?
Who can kill or descope work that’s not feasible?
What trade-offs can the trio make without escalation?
What must escalate? (Things like budget thresholds, timeline changes, scope changes beyond X)
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.
Of course, this then gives you the ability to define success metrics. The real question is shared accountability. Because the classic setup measures IT on delivery velocity and system uptime, and businesses on revenue and customer outcomes, these can point in opposite directions. If the metrics aren’t shared, the trio becomes adversarial: the business owner pushes for speed, the tech lead pushes for quality, and the third person picks a side or checks out. Which is, of course, very suboptimal. A trio needs at least one shared outcome metric they’re all accountable for, not IT delivering on time and the business adopting it. But this problem got solved, and here’s how we’re measuring it as a team, as a trio that can then be reported up the chain to their C-suite execs.
What Makes It Actually Stick: The Leadership Part
This is the pivot where you tell them the uncomfortable truth: the structural stuff will fail if leadership behaviour doesn’t change. Be direct but not preachy:
Stop sending “urgent” requests directly to IT that bypass the trios. Every time you do, you undermine the model.
Stop letting business leaders commit to timelines without technical input. If sales promises a feature by Q3 without talking to engineering, you’ve already broken the system.
Protect trio time. If your 10-person IT team is running 15 trios plus BAU support plus incidents, you don’t have a trio model - you have a burnout model.
Hold business owners accountable for outcomes, not just engineers. If a project fails, the business sponsor should be in that post-mortem, too.
This is where you earn trust by not just telling them what to build, but what to stop doing.
Moving on to what actually makes this type of design pattern stick in an organisation, the real truth is that the structural stuff will fail if leadership behaviour doesn’t change. This is a big part of why many of these processes just don’t stand the test of time: leadership is the one unwilling to change, not the actual ground-level staff who implement these patterns.
As an organisation, you need to stop sending urgent requests directly to IT that bypass the trios. Every time you do, you undermine the model. If every request is urgent, there is no way for an IT team to prioritise requests.
Equally, the business needs to accept that sometimes deliveries will get pushed out because legitimately urgent requests will come in that need to be facilitated and actioned, and that will take time and have a knock-on impact on the delivery of other stuff.
We also need to stop letting business leaders commit to timelines without technical input because we’ve seen this time and again. If the sales team promises a feature by Q3 without talking to engineering, you’ve broken the system because there’s no input from the people doing the implementation. It’s just a guarantee that those people will actually adhere to those timelines to understand their existing workload and delivery schedule, and whether that is even feasible.
Also, it is important to protect Trio’s time. If your 10-person IT team is running 15 trios, plus BAU support, and an instance, you don’t have a trio model; you have a burnout model. (Trinkenreich et al., 2023) Everybody is knee-deep in trios trying to plan for the next bit of work, trying to understand what’s going on, and, of course, trying to do that whilst supporting existing systems and developing new ones is nigh on impossible just due to the nature of the scale of the requirements and the requests coming into that organisation.
The last point that actually makes this stick is holding business owners accountable for outcomes, not just engineers. If a project fails, the business sponsor should be in that post-mortem too because they are part of this chain. It is not purely an engineering function that causes the failure of a specific plan. It can be a lack of specification or accurate scoping, and it takes more than two to tango. Ensuring that the business is also held accountable for its side of the bargain is important when running post-mortems to understand where the failures actually occurred. If we all just always assumed that the business is right and the IT organisation is wrong, you will forever be in a spiral of finger-pointing, with the IT organisation taking the blame.
A Realistic Starting Point
As we reach the end of this post, it would be nice to offer some actionable pointers people can work with.
So what I’m saying to you is: pick one or two high-value, high-friction problem areas inside of your organisation and form trios there. Begin with the following steps: First, select and clearly define the problem areas where a Trio can bring substantial improvements. Second, assign clear roles to each Trio member, ensuring everyone understands their responsibilities and contributions. Third, establish specific metrics to measure success, such as customer satisfaction scores or time-to-market metrics. Finally, schedule a review after a quarter to assess the Trio’s performance, identify challenges, and make necessary adjustments. Run it for a quarter, see what breaks and iterate over it. It’s not an overnight change that’s going to suddenly transform your organisation, but it will enable more direct communication and allow multiple groups to take on responsibility for ensuring that requirements are defined and that everybody has a stake in the outcome. It’s not just chucked over a wall, and the IT team are expected to pick it up and run with it.
It’s also important to acknowledge that this is hard and takes longer than you’d like. It’s a difference between a real fix and another process that becomes what I call shelf-ware. We try something, we try it for a week, we decide that it doesn’t work, and then we chuck it on the shelf and pretend that we’ve never done it. We continue doing the same things over and over again, leading to significant employee dissatisfaction, churn, and project delivery failures. (Costa et al., 2024) But remember, real change is not easy, and it takes bravery to step out of the comfort zone. Let this be a call to courage for leaders—be the catalyst for change and sustain the momentum to truly transform your organisation.
Of course, it takes effort to make this work; it takes buy-in across the organisation. If you don’t get it, you’ll never succeed.