Hidden misalignment: How to spot it before it derails delivery

Agreement in the room doesn't guarantee shared understanding. Discover how project and product leaders can surface hidden misalignment before it puts delivery at risk.

The single biggest problem in communication is the illusion that it has taken place.

George Bernard Shaw

Whether or not Shaw said it, this quote captures a problem I’ve seen over and over again: people leave the same conversation with different understandings of what was agreed.

That’s what hidden misalignment is, in a nutshell. It’s rarely a dramatic disagreement. More often than not, it’s two people (or two teams) walking away from the same conversation with completely different understandings of what was agreed. At its root, it’s a communication problem, and it’s the biggest culprit when projects or products go wrong.

I started out as a developer before moving into project management, consultancy, and pre-sales. For the last few years, I’ve been running ways-of-working workshops for product teams. The context might change, but the causes of misalignment remain remarkably consistent. In this blog, I’ll lay out the practices I return to again and again to surface misalignment early, before it derails delivery. You’ll notice a common theme across all of them. Each one is really a communication practice: a way of turning what people might quietly assume into something they say out loud, and most importantly, making sure it’s been heard.

Set the ground rules before kick-off

Teams often skip a formal kick-off, and sometimes even realise they’re halfway through a project without having established a baseline. Setting some ground rules isn’t the most glamorous process, but it pays off. Take some time to agree on and document which communication channels you’ll use, the escalation path, and how the team(s) will work together. Keep it simple. Something as basic as “we’ll keep all our documents here” saves you from having to monitor multiple systems.

I also run an exercise I call a “team contract”. It covers the hard skills of communication (what you’ll use and when), as well as the soft skills (how you prefer to communicate and what you expect of others). It helps you to start out with a clear picture of how your teammates like to communicate.

Ground rules are simply communication about communication. Agreeing on them upfront means that when misunderstandings do happen, you can focus on the problem itself rather than on where the conversation should have taken place.

Map your assumptions, starting with the riskiest

Assumption mapping works best when it’s done from the customer’s perspective. Begin by mapping the problems you understand them to have. Where I see many teams go wrong is that they jump straight to solutions. They build a roadmap of solutions before validating the problems behind them.

Here are a few techniques that can help:

Test your riskiest assumption first: Validate the assumption that would hurt most if it happened, and keep going until you hit something that tells you to stop. Getting rid of your biggest assumptions first gives you the most return for your effort.
Ask about problems, not preferences: People like to be helpful. If you ask them “Would you buy this?” they’re likely to say yes, even if that isn’t true. Instead, ask about their problems and look for commitment behind an idea, rather than opinions about it.
Shorten your feedback loops: If you’re waiting more than a couple of weeks for feedback, your loops are probably too long.
Run a risk workshop: If you map out every risk you can identify, very little afterwards can genuinely surprise you. The format doesn’t need to be complicated. A simple risk log assigns each risk a description, an owner, an impact, a probability, a criticality score, and a response: mitigate, transfer, accept, or avoid.

Every assumption is something that hasn’t been communicated yet. It’s a belief one person holds that nobody has said out loud or tested. Assumption mapping brings these quiet beliefs to the table where the whole team can see them.

Make dependencies visible

Dependencies are effectively queues. When one thing gets held up, everything behind it gets held up too. Use a Gantt chart, Jira issue links, or a board on the wall, the goal is to see all dependencies clearly. Even better if you can reduce them.

When using a waterfall approach, you tend to have lots of dependencies and manage them as best you can. In an agile approach, you try to remove as many dependencies as possible so deliverables can be treated independently. You’ll never achieve full independence, but it’s better than managing long chains.

Every dependency is a conversation waiting to happen. Making dependencies visible shows you exactly where those conversations need to take place and who needs to be in them.

Listen out for red flags

There are a couple of key patterns to watch out for. The most telling signs of misalignment are often found in what people don’t say, rather than what they do.

A false sense of certainty: The more certain people are about achieving a goal, the more likely it is to go wrong. Certainty can mean someone has stopped considering their assumptions and risks. When certainty is high, questions stop being asked. Misalignment thrives in silence.

Over-investment in process: It might sound counterintuitive, but following a process doesn’t necessarily guarantee results. The thought put into the work, the management of risk, and the understanding of the problem do that. Processes can make things faster and more repeatable, but that’s about it. A process can also create the illusion that communication has taken place. A signed-off document can look a lot like agreement, without anyone checking that they understood it the same way.

In my own experience, a “minimum viable process” can be enough. Put in place what you need to get where you need to, and add more only if it turns out not to be enough. Don’t overdefine it. Otherwise, everyone can become paralysed in the weeds of the process itself.

Give a confidence vote

If you live in the Arctic, you can say it’ll be below freezing tomorrow and be almost 100% confident you’re right. If you live in London, you can say it’ll rain tomorrow, but your confidence level might only be 40-50%. A good estimate depends not only on knowing what the estimate is, but also on how much you actually trust it.

Some more structured techniques, like decision sprints, build confidence voting in explicitly. Whatever method you use, remember to pair every projection with a confidence level. A low score from someone is a signal worth exploring further. Confidence votes give people permission to say what they might otherwise brush under the carpet. Someone who might not openly challenge a plan in a meeting would give it 3/10 in a vote, opening up the door to conversation.

Check in regularly, but keep it fresh

Regular check-ins are great at surfacing misalignment, but they can also go stale very quickly. Check-ins are your team’s communication rhythm, and, like any routine meeting, they can quickly slip into autopilot. Here are some tips to keep things fresh and honest.

Daily stand-ups: Insist that people only talk about problems. I don’t need to hear about what someone did yesterday. I need to know what’s blocking them, then get the whole team thinking about how to get around it. Having a shared team communication channel on Slack or Teams can take a lot of the pressure off the stand-up by covering any day-to-day discussions.

Fortnightly retros: These are the team’s chance to stop and ask what went well, what didn’t, and what to fix next time.

Start every meeting with the objective: Begin with what the meeting is about and what you’re trying to achieve. It sounds so simple, but it stops meetings from meandering until people turn their attention elsewhere.

Even the best check-in processes can go stale. When this happens, bringing in a fresh pair of eyes can work wonders. On one team I worked with, a product manager arranged for the other product managers across the business to run each other’s retros. Different formats and an outsider’s perspective were enough to get everyone thinking again. An outsider also won’t share the team’s unspoken assumptions, so they naturally ask the questions everyone else has stopped asking.

My biggest piece of advice: complete the circle

If you take one thing from this blog, don’t assume what you’ve said has been understood.

Consultants do this instinctively. Listen to a customer, then play it back: “So what you’re telling me is X, Y and Z, is that right?” We rarely do this internally, and that’s where problems crop up.

Complete the circle. Don’t just tell people what you need from them. Ask them to tell you what they’ve understood, and correct any assumptions there and then. Communication is always two-way: you deliver the message, then listen for feedback to make sure it landed how you intended. Ten minutes of playback at the start could save you months later on.

Every practice in this blog is a version of the same idea. Ground rules, assumption maps, visible dependencies, confidence votes and check-ins all exist for one reason: to replace the illusion that communication has taken place with the real thing.

Want to improve communication in your team even further?

Find out how to prevent psychological contracts with better communication, confidence levels, and stakeholder alignment.

Read Adam's blog