THE BRIEFING ROOM

Why the best digital projects involve more disagreement, not less

I want you to think about the last time your leadership team made a significant digital decision - a platform choice, a redesign brief, a go/no-go on a major initiative. Think about how that decision actually went. Was there a genuine debate? Did anyone push back hard on the prevailing direction? Or did everyone sort of... nod along, raise a few minor points, and move to the next agenda item?

If it was the nodding version, you probably left feeling good about it. Aligned. Efficient. United front. And I'd put money on the fact that whatever got approved is now either underwhelming in production, stuck in a painful delivery, or quietly being descoped because nobody challenged the assumptions early enough.

That's the thing about alignment. It feels wonderful. It's also, in my experience, one of the most reliable predictors of mediocre outcomes.

The alignment trap

We value alignment. Disagreement slows things down and creates conflict.

I hear this constantly. And I understand the instinct - genuinely. If you're running a firm with 150, 300, 500 people, alignment feels like the thing that keeps everything moving. Meetings finish on time. Decisions get made. Nobody leaves the room annoyed. It's tidy. It's professional.

But across more than two decades of working on digital programmes with professional services firms, financial services businesses, law firms, consultancies - the projects that produce distinctive, commercially significant results almost always involve more friction than the ones that don't. Not chaos. Not shouting matches. But genuine, sometimes bruising disagreement about what matters, what's realistic, and what good actually looks like.

The fastest path to mediocrity is universal agreement. When everyone agrees, it usually means one of a few things: someone with authority spoke first and nobody wanted to contradict them, the group defaulted to the safest option because it was least likely to cause an argument, or - and this is the sneaky one - the brief was so vague that everyone was agreeing to a different thing in their own heads.

I was in a design review last year with a mid-market consulting firm. The new homepage concept was on screen. The managing partner said, "I think this looks great." And that was it. Five other senior people in the room. Not one challenge. Not one question about why the hero section led with the firm's history rather than what clients actually cared about. I asked afterwards - privately, one-to-one - whether anyone had concerns. Three of the five did. Significant ones. They just didn't want to be the person who "slowed things down."

That homepage launched. Conversion rate dropped 22% against the previous version. And six months later, we were back in the room redesigning it - this time with a structured process that made disagreement not just acceptable but expected.

Destructive vs. constructive friction

Now, I'm not suggesting you turn every meeting into a free-for-all. I've been in rooms where disagreement has no structure, no purpose, and no resolution mechanism. Where the loudest voice wins, or where two senior partners use a design review as a proxy war for some unresolved argument about the firm's strategic direction. That's not friction. That's dysfunction wearing a creative hat.

So let me be specific about the difference.

Destructive friction looks like this: personal attacks disguised as feedback. Reopening decisions that were already made. Disagreement without alternatives. Status-driven overrides - where the most senior person in the room simply pulls rank. Passive resistance after the meeting, where someone agrees in the room and then quietly undermines the decision in the corridor. You know the type.

Constructive friction looks completely different. It's someone saying, "I think the brief is wrong, and here's why." It's a designer pushing back on a requirement because the data doesn't support it. It's a delivery lead saying, "We can do this, but not in this timeline, and here's what we'd need to cut." It's a CFO asking, "What happens if this doesn't work?" - not to kill the initiative but to make sure someone's thought about it.

The difference isn't the presence of disagreement. It's whether the disagreement is aimed at improving the outcome or protecting someone's position.

You know when you're renovating a house and the architect tells you the wall you want to knock through is load-bearing? That's friction. It's annoying. It changes your plans. But it stops the ceiling falling in. Now imagine an architect who just said, "Yeah, sure, whatever you want" to every request. You'd end up with a house that looks exactly like you imagined and also has a structural integrity problem that'll cost you three times more to fix later.

Digital projects are full of load-bearing walls. The question is whether anyone in the room feels safe enough - and has enough structural permission - to point them out.

Creating the conditions

This is where most firms get it wrong. They assume that if they hire smart people and put them in a room together, healthy challenge will happen naturally. It won't. Especially not in professional services, where hierarchy is deeply embedded, where partnership structures create complex power dynamics, and where "being seen as difficult" can genuinely affect your career.

You have to build the conditions deliberately.

Psychological safety is the foundation. I know that phrase has been done to death in management literature, and I slightly wince using it. But the principle is sound. People won't challenge a decision if they believe doing so will cost them politically. That's not cowardice - it's rational self-preservation. So you have to make it explicitly, repeatedly clear that challenge is valued. Not in a poster-on-the-wall way. In a "the managing partner just said 'I think this is wrong, change my mind' and then actually listened" way.

One of the most effective things I've seen a senior leader do is open a review meeting by saying: "I want to hear what's wrong with this before we talk about what's right." Simple. Takes five seconds. Completely changes the dynamic. Because now disagreement isn't something you have to summon the courage for - it's what's been asked of you.

Clear decision rights matter more than you'd think. Half the toxic friction I've seen in digital projects comes from ambiguity about who actually gets to decide. When decision rights are unclear, disagreements become territorial because the stakes feel existential. If I don't know whether I have the authority to make this call, I'm going to fight harder for my position because losing the argument might mean losing my influence entirely.

Before any significant piece of work, agree who decides what. Not in a 40-page RACI matrix that nobody reads - just a clear, spoken agreement. "The design lead decides the UX approach. The partner signs off the messaging. The delivery lead owns the timeline. If there's a conflict, here's how we resolve it." That's it. Takes ten minutes. Saves weeks.

And then - this is the one firms most often miss - build structured review points where friction has a home. If you don't create specific moments where challenge is expected, it'll either happen at random (usually at the worst possible time) or it won't happen at all. We build formal review gates into every programme we deliver. Not progress updates. Decision points where the explicit purpose is to stress-test what's been done and what's planned. You come to the table with your concerns. That's the job.

Where friction matters most

Not every decision needs a debate. If you're choosing between two shades of blue for a button, just pick one and move on. But there are moments in any digital programme where suppressing disagreement is genuinely dangerous.

Requirements definition is where the damage usually starts. If nobody challenges the brief, you end up building something that reflects the internal politics of the firm rather than what customers actually need. I worked with a financial services business last year that had a 60-page requirements document for a client portal. Beautifully written. Comprehensive. And about 40% of it was features that internal stakeholders wanted but clients had never asked for - things like a custom reporting module that three people in risk management had requested and approximately no client had ever mentioned. Nobody had pushed back during requirements gathering because the requirements came from senior people. The portal launched eight months late, 60% over budget, and within a year the usage data showed that most clients were logging in, not finding what they needed, and calling the account team anyway. The expensive portal had become an expensive detour back to the phone.

Design review is where the most dangerous phrase is "I like it." Because "I like it" isn't feedback. It's a personal aesthetic response. What you need is: "Does this solve the problem we defined? Does the evidence support this approach? What are we assuming about user behaviour, and have we tested that assumption?" Those questions create productive friction. "I like it" creates a false consensus that falls apart the moment real users interact with the thing.

Prioritisation should be uncomfortable. Every digital programme has more ideas than budget. If your prioritisation session ends with everyone happy, you haven't prioritised - you've just agreed to do everything and hoped for the best. Real prioritisation means telling someone their initiative isn't making the cut this quarter. That requires a conversation, not a spreadsheet.

Go/no-go decisions are when the pressure to agree is at its peak. Everyone's invested. The deadline is real. Nobody wants to be the person who says, "Actually, I don't think this is ready." But that's exactly when the most expensive mistakes get made. We had a situation a couple of years ago - a law firm, mid-market, about 200 lawyers - where the delivery team wanted to push back the launch by three weeks to fix a performance issue on mobile. The partners wanted to go live because they'd already told clients about the new site. In a room with no culture of constructive friction, the partners would have won and the site would have launched slow. Instead, the delivery lead presented the data, the partners asked hard questions, and they agreed on a compromise: soft launch to a limited group, fix the performance issue, full launch two weeks later. Better outcome for everyone. But it only happened because someone felt safe enough to say "not yet."

When friction turns toxic

There's a line, and you need to watch for it. Healthy friction is about the work. Toxic friction is about the people. And the transition between the two can be surprisingly subtle.

Warning signs I've learned to watch for: the same objection being raised for the third time after it's been addressed. Feedback that's about the person, not the output - "Well, that's typical of the marketing team" rather than "I think the messaging misses the mark." Side conversations after meetings where the real opinions come out. People going quiet - not because they agree, but because they've given up.

And the big one: when disagreements start getting relitigated outside the room, in corridors and on email threads, rather than being resolved in the structured spaces you've created for them.

When you see those signs, you have to intervene quickly. Not by shutting down disagreement - that just drives it underground. By naming what's happening. "We've discussed this point twice and made a decision. If there's new information, let's hear it. If not, we need to move on." Or: "I'm noticing that the feedback is getting personal. Let's reset and focus on the output."

God, it's not comfortable. But then, that's rather the point.

The real cost of being too polite

Firms that suppress disagreement get polite compliance. People do what they're told, deliver what's been asked for, and don't rock the boat. The output is safe. Predictable. And almost always a bit... beige. The website that looks like every other website in the sector. The portal that technically works but nobody loves. The digital strategy that says all the right things but doesn't actually commit to anything bold enough to make a difference.

Firms that channel disagreement - that create deliberate, structured spaces for people to challenge assumptions, push back on briefs, and argue about priorities - get something different. Solutions that have been stress-tested before they hit production. Designs that reflect what clients actually need, not what the HiPPO (highest-paid person's opinion) assumed they needed. Delivery plans that are realistic because someone had the guts to say "this timeline is fiction."

We've seen this play out dozens of times. A professional services firm we worked with - about 300 people, consulting and advisory - had a culture of what I'd call "aggressive politeness." Everyone was unfailingly courteous. Meetings were pleasant. And every digital initiative they'd launched in three years had landed somewhere between "fine" and "disappointing." When we started working with them, we introduced structured challenge sessions at each review gate. The first one was painful. People were visibly uncomfortable pushing back on the CEO's preferred approach. By the third session, the CEO was actively inviting it.

I should be honest: it didn't transform overnight. There was one session - about four months in - where a senior director challenged a decision that had already been signed off, and the whole thing nearly unravelled. We had to stop the meeting, reset, and have a fairly direct conversation about what constructive challenge actually meant. Not the most comfortable afternoon I've had. But the platform they eventually delivered was, by their own admission, the first digital project in the firm's history that partners were genuinely proud of. And the usage data at six months showed a 34% increase in client self-service tasks - which, for a firm that had been haemorrhaging account management time on routine queries, was the number that actually mattered.

That didn't happen because they hired better designers or chose a better CMS. It happened because they stopped being so bloody polite about the things that mattered.

What this looks like in practice

Pick one upcoming decision, a design review, a prioritisation session, a requirements sign-off. Before the meeting, explicitly tell the room that you want to hear objections. Not suggestions. Objections. Frame it as: "What's wrong with this? What are we missing? What assumption haven't we tested?" And then - this is the bit most people get wrong - don't react defensively when someone actually does it.

The first time will feel weird. People will hedge. They'll couch their challenges in qualifiers. "This is probably a stupid question, but..." It's not a stupid question. It's probably the most important thing anyone's said all meeting. Reward it. Publicly. "That's exactly the kind of challenge we need. Thank you."

Do that three or four times and you'll notice something shift. People start coming to meetings prepared to challenge, not just to listen. The quality of the discussion improves. The decisions that come out of those rooms are sharper, more considered, and more resilient - because they've already survived the scrutiny that would otherwise have happened after launch, when it's too late and too expensive to change anything.

I'm not pretending this is easy. It requires a kind of leadership confidence that goes against every instinct most senior professionals have. You've spent your career building credibility and authority. Inviting people to disagree with you feels counterintuitive. Almost reckless.

But the alternative - the polite, aligned, efficient meetings where everyone nods and nobody challenges - is how you end up with another digital project that's technically competent and commercially forgettable.

And honestly? You've probably had enough of those.