Your frontline communication problem isn’t a frontline problem

Surrealist painting: an empty wooden office chair floats in an electric-blue sky among white clouds. On the pale sandy ground far below, a line of small uniformed workers, including a nurse, a cleaner and a delivery rider, walk past in dark-blue silhouette without looking up.

Around 80% of the world’s workers don’t sit at a desk. That’s roughly 2.7 billion people, per Emergence Capital’s much-quoted estimate. They drive, build, nurse, serve, stack, fix and deliver.

And yet almost everything we call “internal communication” was designed for the other 20%. The intranet, the all-staff email, the leadership video, the Teams post: each assumes a screen, a login, a reliable connection and a working day with a few spare minutes in it.

We then describe the majority of the workforce as “hard to reach”, as though the problem were their working conditions rather than our design choices. The workers themselves have noticed: in Microsoft’s survey of 9,600 frontline employees, 63% said messages from leadership simply don’t reach them.

There’s a particular kind of organisational optimism that believes this can be fixed with another bit of tech.

Frontline employees aren’t reading the intranet? Give them an app. They’re not opening emails? Push notifications. They’re not engaging with leadership messages? Perhaps some gamification. A leaderboard, possibly. Everyone loves a leaderboard, particularly when they’re finishing a twelve-hour shift.

The frontline communication problem isn’t really a frontline problem, it’s a design problem. Specifically, we’ve designed communication around the convenience of the sender rather than the circumstances of the person expected to receive it. And the sender, almost without exception, sits at a desk.

It’s a pattern Jonathan Phillips and I kept running into while writing Digital Communications at Work, in hospitals, retailers, charities and manufacturers alike. The sector changes. The assumption doesn’t.

The desk is doing more work than you think

Most internal communication practices carry a set of assumptions that are so deeply embedded we barely notice them.

Employees have an email address. They have a device on which they can access comms. They can check messages during the working day. They can follow a link to the intranet, answer riddles three to authenticate, sacrifice a goat to the god of multifactor authentication, and spend a few minutes reading something that mattered enormously to the person who commissioned it.

For many office workers, these assumptions are broadly reasonable. Even if they don’t always have the inclination to read the latest leadership update, they have the ability to do so.

Now consider someone driving a bus, serving customers, working on a production line or halfway through a hospital shift.

“Check the intranet” is not a neutral request. Neither is “we sent an email”.

Both make assumptions about the employee’s device, access, connectivity, attention and, crucially, who gets to decide what they do with the next five minutes of their working day.

An office worker can usually glance at a notification between meetings. A nurse cannot necessarily interrupt a medication round because Corporate Communications has published an exciting update about the organisation’s strategic priorities.

And this isn’t simply a question of access. It’s also about what people actually need to get their jobs done.

The employee on the production line may need to know that a safety procedure has changed, that tomorrow’s shift starts earlier or that a particular piece of equipment is out of service. They may be less interested in a video of the CEO discussing the organisation’s transformation journey, however handsomely produced.

That doesn’t mean they are disengaged. It could just mean they’ve correctly identified which information is useful to them.

Utility, like beauty, is in the eye of the beholder. And we’re often too happy to mistake our own priorities for everyone else’s needs.

An employee app solves access, not opportunity

The employee app market has done a good job of recognising that traditional corporate channels don’t work equally well for everyone.

Mobile access can be transformative. It can put shift information, payslips, policies, operational updates and support services into people’s hands without requiring a desk or corporate laptop. For employees who previously relied on printed notices or information passed down through managers, that’s a genuine improvement.

But there’s a difference between making communication technically accessible and making it practically usable. In the same Microsoft research, a third of frontline workers said they lacked the tools to do their jobs, rising to 41% among those without management responsibilities, and more than half had been handed new digital tools with no training at all. The access problem hasn’t been solved, it’s just been handed to the employee.

You can give a warehouse employee an app. You cannot assume they are allowed to take out their phone while operating machinery. You can send a notification to a retail worker. You cannot assume they can read it while serving a customer. You can publish a beautifully accessible article for a care worker. You cannot conjure up ten spare minutes in an already overstretched shift.

An app can put information in someone’s pocket. It cannot put five spare minutes in their shift. So an app only succeeds if it’s designed for the ninety seconds someone actually has between tasks, not the fifteen minutes we wish they had.

This distinction gets lost when organisations measure the success of frontline communication primarily through downloads, registrations and monthly active users.

As we say in the book, there is no ROI in launch. It’s all in sustained adoption and use, and use only pays off when it helps people do something. So the question isn’t how many people have the app, but whether they can find what they need, at the moment they need it, in a form they can use. That changes what you measure. How long does it take someone to find tomorrow’s shift pattern? How many “where do I find…” questions still land on supervisors? Did the safety update reach people before the shift it applied to?

A million app downloads would be a magnificent achievement… unless the million people who downloaded it still have to ask their supervisor where to find things.

Those are useful measures of whether the technology is being adopted. They tell you somewhat less about whether employees can access the information they need, at the moment they need it, in a form they can use. It’s the distinction we draw in the book between outputs and outcomes. Downloads tell you whether people have adopted the technology. Outcomes tell you whether it’s made their working lives any easier.

A million app downloads would be a magnificent achievement… unless the million people who downloaded it still have to ask their supervisor where to find things.

Stop confusing communication about work with communication that helps people work

In Digital Communications at Work, Jonathan and I distinguish between broadcast communication and communication aligned with the work people actually do. We separate news from operational and reference content, because each has a different purpose, a different audience and a different lifecycle, and treating them as one undifferentiated stream serves none of them well.

Both have a place. Employees need to understand their organisation, its direction and the decisions that affect them. But they also need information that helps them complete a task, solve a problem, make a decision or respond to something happening right now.

Corporate communication tends to be organised around the former. Frontline employees often have much more immediate needs relating to the latter.

We have reached the peculiar point where an organisation can burn electricity, consume water and summon the full might of generative AI to ensure a warehouse worker receives a hyper-personalised video of the CEO explaining the company’s purpose, while remaining apparently unable to tell that same worker whether they’re on the early shift tomorrow.

The answer isn’t to abandon organisational communication. It’s to recognise that communication which helps people do their jobs can be an important foundation for everything else. A channel that reliably solves real problems earns a place in someone’s working day. A channel that primarily creates additional demands on their attention has a harder case to make.

Means, motive and opportunity: the Fletcher Test

In Digital Communications at Work, Jonathan and I introduce the Fletcher Test, borrowing the detective-story formula of means, motive and opportunity to ask three questions about any piece of communication.

Does someone have the means to receive it? A motive to engage with it? And an opportunity to do so within the reality of their working day?

Frontline communication is where the distinction becomes particularly important. Organisations have a habit of treating the first question as though answering it automatically settles the other two.

At Unily Unite recently, we put the test to work with more than 100 communications and digital workplace professionals. We gave them a fictional organisation, a week’s worth of internal communications and employee personas ranging from lorry drivers to head-office finance staff. Their job was to judge each message from the employee’s perspective, not the sender’s.

You can download the workshop toolkit and run the exercise with your own team.

Means: can they actually receive it?

Does this person have access to the channel? Do they have the right device, permissions, connectivity and language support? Can they authenticate without navigating a sequence of systems designed for someone sitting in front of a company laptop?

And does the format work in their environment?

A long article may be appropriate for someone who spends much of their day reading documents. It’s considerably less useful to someone who needs a short operational instruction between tasks.

Means is where technology can make a real difference. But it requires an understanding of the working environment before choosing the technology.

Motive: why would they care?

This is the question communicators sometimes find uncomfortable.

Not “why does the organisation want them to know this?” but “what reason does this employee have to engage with it?”

Those are not necessarily the same thing.

An update to a safety procedure has an obvious connection to someone’s work. A change to shift arrangements may affect their pay, childcare or journey home. Information about a new employee benefit may have direct personal value.

The announcement that the organisation has launched a refreshed set of corporate values may be very important to the people who spent six months developing them. Whether it deserves three minutes of a warehouse worker’s attention is another question. Particularly if the warehouse worker wasn’t consulted about the values, doesn’t recognise them in their own experience of the organisation, and has rather more pressing concerns about next week’s rota.

And motive is shaped by more than the message itself. It’s shaped by the relationship between the employee and the organisation.

In the UK alone, 1.2 million people are on zero-hours contracts, close to the highest figure on record, and over half a million of them are under 25. Asking people in that position to demonstrate commitment to an organisation that has gone to considerable lengths to avoid committing to them is quite an ask. Particularly when the proposed solution is a push notification about company values.

This doesn’t mean every communication must offer an immediate personal benefit. Organisations have legitimate reasons to explain their strategy, culture and decisions. Employees also deserve to understand the wider business they are part of.

But attention isn’t something an organisation is automatically entitled to because it pays someone’s wages. And if the employment relationship gives people little reason to trust what they’re being told, no amount of channel optimisation will manufacture that trust.

We should be able to articulate why a particular audience needs a particular message, rather than assuming that because it matters to the sender it must matter equally to everyone else.

Opportunity: is there a realistic moment when they can engage?

This is the one I think we neglect most.

Even when someone has access to a channel and a decent reason to care, there must be an opportunity to encounter and act on the information.

That might mean building communication into shift handovers, team briefings, existing operational routines or the systems employees already use to do their jobs. It might mean providing paid time to complete essential training or read important updates. It might mean recognising that some information is best communicated by a manager in person, while other information should be available on demand.

And it might mean deciding that a message doesn’t need to be sent at all. As we put it in the book, the most powerful distribution decision is often not sending.

This is the awkward part of the exercise. Communications teams are usually asked to improve reach, increase engagement and make messages more compelling. Much less often are they given permission to question whether the communication deserves to exist in the first place.

Yet attention is a finite resource, and frontline employees have particularly little discretion over how they spend theirs.

If you’re asking someone to stop doing the job they’re paid to do so they can consume something you’ve been paid to produce, the burden of proof is very much on you.

Stop treating frontline employees as one audience

There’s another problem with the phrase “frontline workforce”: it describes a relationship to the organisation, not a coherent set of information needs. And given it covers most of the working population, it’s a remarkably unhelpful one.

A brain surgeon and the person cleaning the operating theatre are both frontline workers. So are an airline pilot bringing 300 people into Heathrow, the bloke delivering your Ocado order, the woman checking tickets on the 7.42 to Waterloo and the person trying to persuade a drunk man to leave Wetherspoons. Their working lives have almost nothing in common, beyond the fact that none of them spends the day sitting in head office being invited to webinars about employee engagement.

They differ in what they need to know, how often it changes and what happens if they don’t know it. They differ in skills, expectations and digital confidence. They differ in the devices they’re issued (or not issued), and in how much say they have over their own time.

And they differ in their relationship with the organisation, even when they work in the same building.

Take the surgeon and the cleaner. One may be a permanent employee with considerable professional autonomy, access to clinical systems and a well-established relationship with the hospital. The other may work for an outsourced facilities contractor, on a different set of systems, with different reporting lines and little access to the organisation’s internal channels. They may work on the same ward, encounter the same patients and be affected by the same operational decisions, yet belong to entirely different information ecosystems.

This is all extremely pertinent when you’re designing communication. Who is responsible for telling the cleaner that a ward has closed? Does the hospital communicate directly with them, or through the contractor? Can they access the relevant information without a hospital login? And if the answer is that their supervisor will tell them, what happens when that supervisor is off sick?

The surgeon needs the safety alert before the operating list starts. The cleaner needs to know which areas require enhanced infection-control procedures before beginning their shift. Both are operationally important. Neither is particularly well served by a generic weekly newsletter announcing that the hospital is delighted to unveil its new strategic vision.

Some frontline workers operate alone. Others are constantly surrounded by colleagues. Some work predictable shifts in one location; others move between sites or spend their days travelling. Some will download an app the moment they’re asked; others haven’t been issued an email address, let alone a login.

The opportunities to communicate are different. So are the consequences of getting it wrong.

A retail worker might receive information through a daily team briefing. A field engineer might need an update integrated into the job-management system. A driver might need something available at a depot or during a scheduled break.

Treating all of them as a single audience because they don’t sit at desks is about as useful as treating everyone who does sit at a desk as having identical needs. Nobody writes a communication strategy for “people with chairs”.

The distinction between desk-based and deskless work matters, but it is only the beginning of segmentation.

Good communication design starts with the work: what people do, where they do it, which systems they use, who they interact with, who actually employs them, how much control they have over their day and what information helps them make decisions.

Only then should we start discussing channels.

Your managers are not a free distribution network

When digital channels struggle to reach frontline employees, organisations often fall back on managers.

“Cascade this to your teams.” Corporate shorthand for making someone else responsible for the bit where communication has to work.

Managers are expected to receive corporate messages, interpret them, decide what matters, translate them into something meaningful for their teams and deliver them consistently, usually alongside the small matter of running the operation.

This assumes a great deal about the people we’ve made managers. Many got there because they were excellent at their previous jobs. The best engineer became the engineering manager. The most experienced nurse became the ward manager. The person who could keep a warehouse running through a minor apocalypse was rewarded with responsibility for twenty other people. Whether any of them could lead, coach or communicate effectively was sometimes a secondary consideration, if it was considered at all.

Some turn out to be excellent managers. Others are indifferent, inept or actively dreadful. Plenty have never received meaningful management training. Yet we construct elaborate communication cascades on the assumption that every one of them possesses the judgement, confidence and interpersonal skills to translate corporate strategy into something useful for their teams. This seems an optimistic foundation on which to build anything, let alone an organisation’s primary means of reaching its workforce.

Even the good ones are stretched. Gartner puts it bluntly: the average manager has 51% more responsibilities than they can effectively handle. And in Microsoft’s frontline survey, 69% of frontline managers said their own leaders don’t communicate with them effectively, which rather undermines the idea of the cascade before it has started. Information is expected to flow effortlessly down a management hierarchy in which the people halfway down don’t know what’s going on either.

Managers can be an exceptionally effective communication channel because they provide something an app cannot: context, interpretation and the opportunity for a conversation. A good manager can explain what a decision means locally, answer questions and spot confusion before it becomes a problem.

But that is precisely why they should not be treated as human forwarding services. In Digital Communications at Work, we treat managers as a channel with its own requirements, including briefing, timing, capability and the authority to adapt the message, rather than the default fallback when digital reach runs out.

If a message requires local interpretation, give managers the information, training, authority and time to provide it. If it simply requires employees to know a fact, consider whether making that fact directly accessible would be more reliable. And if the same information must pass through four management layers before reaching the person who needs it, perhaps the problem isn’t that managers need another briefing pack.

Perhaps it’s that you’ve built a distribution model which only works if every manager is a competent communicator, despite having done remarkably little to ensure that they are.

What a frontline communication strategy should actually do

Before commissioning another platform, I’d suggest establishing what problem you’re actually trying to solve. An unfashionable approach, admittedly, but cheaper than discovering afterwards that you’ve solved the wrong one.

What information do different groups of employees actually need to do their jobs? Which messages require immediate action, which need to be available for reference, and which are primarily intended to build understanding or connection?

Where does information currently move successfully? Where does it get stuck? Which informal routes have employees developed because the official ones don’t work?

What access do people genuinely have during paid working time? What constraints are imposed by safety, security, location, language, devices and working patterns?

And perhaps most importantly, who has the authority to decide what gets communicated, through which channels and how frequently?

These are the questions discovery is meant to answer, which is why Digital Communications at Work opens with discovery rather than with platforms. I’ve also written about how to start with discovery, including a real example of why giving frontline workers access to an intranet isn’t the same as making it useful.

Because a communication strategy that doesn’t make choices about volume isn’t really a strategy. It’s a distribution plan.

The answer may involve an employee app. It may involve digital signage, improved intranet access, operational-system integrations or something as unfashionable as a well-placed noticeboard. It may mean investing in the communication skills of managers and supervisors, giving them proper training, support and time to do the job, rather than another briefing pack and a cheery instruction to cascade.

Most likely it involves a combination, because different information needs call for different approaches.

The important thing is that the channel follows the need, rather than the organisation buying a channel and then searching for enough content to justify it.

There is a particularly expensive form of organisational self-deception in which a new communication platform becomes successful because people are persuaded to use it, rather than because it makes their working lives materially easier.

Adoption is not the same as value. A launch is the starting line, not the victory lap.

Design around the work, not around the sender

An employee can be brilliant at their job, trusted by colleagues, knowledgeable about customers and proud of what they do, while remaining blissfully unaware of whatever the CEO had to say about the organisation’s exciting transformation journey last week.

This is not an engagement crisis. It may simply mean they’ve got a job to do, and are getting on with it. Which, given that you’re paying them to do precisely that, seems a peculiar thing to hold against them.

We’ve spent years measuring whether employees engage with our communication, and less time asking whether our communication engages with their work. When the numbers disappoint, we reach for another platform, another campaign, another nudge. Anything, apparently, except the possibility that what we’re asking people to pay attention to isn’t worth the interruption.

Perhaps the problem isn’t that your frontline employees are hard to reach. Perhaps it’s that you’ve designed communication around a working day they don’t have, priorities they don’t share and time nobody has given them. Then, when they fail to respond as expected, you’ve diagnosed a problem with their engagement rather than your assumptions.

Your frontline employees aren’t hard to reach. You’ve just spent an extraordinary amount of time, money and effort trying to reach them where they aren’t.

A note on interests, and an invitation: this post is part of a paid partnership with Flip AI. I’m working with them as a creator partner around People Connect Club Paris and UNLEASH Paris next week. Flip AI reviewed this piece before it went live, but the argument is mine, including the bits about apps. I’d have written it anyway; the subject has been on my mind for years.

If you’re an in-house communications professional, come and join the argument on the Seine on 20 October, where I’ll be in conversation with Flip AI’s Luke Talbot. I’m particularly interested in hearing where you think I’ve got this wrong. Writing is how I work out what I think; finding people prepared to disagree with me is how I find out whether any of it survives contact with reality.

And if you’re at UNLEASH, come and find me at Flip AI’s booth on 21 October, where I’ll be signing copies of Digital Communications at Work from 14.00-15.30

Start with Discovery: how to find out what’s actually wrong with your internal comms

A surrealist painting of a bowler-hatted man examining an open refrigerator with a magnifying glass. The brightly lit fridge contains nothing but a grey four-drawer filing cabinet. The sparse, muted room and the man’s solemn attention make the absurd scene feel entirely ordinary.

“We need a new intranet.”

I get this brief a lot. Sometimes it’s an app. Sometimes it’s “we need to reduce email volume” or “we need to do something about Teams.” Occasionally someone has already got as far as choosing the product and would now like some research to confirm they were right.

Unfortunately none of these things is actually a problem. They’re solutions somebody has already chosen, usually in a meeting I wasn’t in, and my job as briefed is to go away and build the thing.

Jon and I spent an hour with IABC members this afternoon making the case for not doing that. The session was billed as how to find out what’s actually wrong with your comms, which is a better title than we’d have come up with ourselves because it names the gap rather neatly. Most organisations know something isn’t working. Far fewer can tell you what. And the distance between those two states is Discovery.

The audit trap

When comms teams do decide to look before they leap, they nearly always reach for an audit. Catalogue the channels. Count the newsletters. Map the publishing calendar. Produce a spreadsheet with 400 rows in it and a slide saying WE HAVE 17 CHANNELS, as if the number itself is the diagnosis.

Audits aren’t useless. They’re just usually the wrong place to start. For one thing, an audit tells you what you’re serving, not what anyone wants to eat. It’s a stocktake of the fridge. You come away knowing you own a lot of yoghurt and no bread, but not whether anyone in the house is lactose intolerant.

Everything you learn is bounded by what already exists. Which means the thing that might actually help — the channel you don’t have, the moment in somebody’s day you’ve never designed for, the workaround everyone uses instead — is structurally invisible.

The second problem is slightly more awkward. If your team publishes the channels, your team is now auditing its own homework. You will discover that the newsletter is broadly fine and the intranet could do with a redesign, because those are conclusions everyone can live with. I’ve watched very capable people do this in complete good faith. It isn’t dishonesty; you just can’t see the water you’re swimming in.

Discovery starts at the other end. Not “what have we got?” but “what are people actually trying to do, and where does it go wrong?”

What Discovery actually is

The idea isn’t ours, and it isn’t new. It grew out of agile and user-centred design, after enough expensive digital projects had failed for people to notice a recurring feature: teams kept leaping enthusiastically towards solutions before they’d properly understood the problem. The UK Government Digital Service made Discovery standard practice, and the discipline has gradually seeped into adjacent fields ever since.

Internal comms has been slower to catch on, partly because we’ve never really thought of ourselves as builders of things. But we are. A channel is a product. Content is a service. And the failure modes are remarkably similar: eighteen months, a six-figure budget, a great deal of stakeholder excitement, then launch day arrives and everybody else carries on with their lives.

At its simplest, Discovery means swapping assumptions for evidence. It’s the shift from “what do we want to say?” to “what do people need, and what would have to be true for this to work for them?” That is more mindset than methodology, and it can be uncomfortable because it asks you to slow down at precisely the point everyone is desperate to demonstrate momentum.

One leader I worked with used to say “facts are friendly”, usually just before somebody put an extremely unfriendly number on a slide. It’s the right instinct. The point of Discovery isn’t to prove your gut right. It’s to find out, early and cheaply, which bits of your gut are wrong.

Why slowing down makes you faster

This is the bit that gets pushback, because Discovery looks like delay. Four to six weeks of research before anyone builds anything appears on a Gantt chart as four to six weeks in which nobody has changed the colour of the homepage and everyone’s still complaining about it. When budgets are tight and a sponsor wants a launch date, it’s therefore one of the first things to disappear.

But the cost of being wrong rises sharply the later you find out. Fixing a misconception on a whiteboard costs an afternoon. Fixing it during build costs a change request. Fixing it after launch costs the change request, the migration, the rework and some portion of the credibility you’ve just spent telling everyone the shiny new thing was going to make their working lives better.

Software engineering learned this decades ago, largely by making all these mistakes first. There are various neat rules of thumb suggesting defects become ten times more expensive at each stage. I’d treat the exact multiplier with suspicion; the underlying point is less controversial. Finding out early is cheaper than finding out late.

But there’s another failure mode that matters more than money. Look at why large internal projects go wrong and it’s rarely because somebody couldn’t make the technology function. It’s unclear requirements, unexamined assumptions, teams building competently and diligently towards a destination nobody properly agreed. You cannot engineer your way out of having solved the wrong problem, and no amount of change management will persuade people to adopt something that simply doesn’t fit their day.

Discovery is cheap insurance against building the wrong thing beautifully.

Start with what you already know

The first move isn’t research. It’s an inventory of belief.

Most organisations are sitting on years of potentially useful material: old comms surveys, engagement data, post-implementation reviews, research from the last intranet project, a strategy deck from three restructures ago. Some of it is gold. Some of it is actively misleading. Old research is like milk: check the date and give it a sniff before pouring it over anything important. A survey run before a major restructure tells you a great deal about an organisation that no longer exists.

Then write down what you think you know. Not vague impressions, but specific claims that can turn out to be wrong:

  • Frontline workers don’t see HR updates because they don’t have email access.
  • People ignore the intranet homepage because it’s cluttered and irrelevant.
  • Managers are quietly rewriting key messages before they reach their teams.

Put them on a board with four columns: to test, partially validated, validated, disproven. Then move them as the evidence arrives. Trello, Planner, Notion, spreadsheet, sticky notes: it really doesn’t matter. What matters is committing your assumptions to writing before you start looking for evidence, so you can’t quietly retrofit the story later. Academics call this pre-registering your hypothesis. In comms, I prefer to think of it as making it harder to mark your own homework twice.

It does something else useful too: it stops Discovery sprawling. You’re not setting out to research absolutely everything anyone has ever thought about internal communication. You’re pulling on named threads. And when a stakeholder asks why you’re recommending something, you can show them the belief, the evidence and how your view changed, which is a significantly better answer than “trust me, I did some interviews.”

Means, motive and opportunity

The most useful frame I know for understanding user needs is borrowed from every moderately competent television detective.

Means: can people technically access the channel? Login, device, email address, permissions. This is where comms teams tend to stop, because it’s the bit we can see and the bit IT can report. But access is table stakes. It tells you what’s technically possible, not what anybody actually does.

Opportunity: when, in the real shape of someone’s working day, can they engage? Five quiet minutes at a desk? Thirty seconds on a phone between jobs? Nothing until they’ve clocked off and would rather be literally anywhere else?

And then motive: why would they bother? Does this help them do the job faster, better or with fewer headaches? If not, attention evaporates regardless of how lovingly somebody has written the CEO update.

We worked with an organisation employing hundreds of maintenance staff who spent their days out on the road. Adoption of the intranet was dismal. Leadership’s diagnosis was that the site needed to work better on tablets. On paper, means looked fine: everyone had a login.

Then we went and watched people work. There was one device per vehicle, not per person, so access meant sharing a tablet behind a clunky login. Opportunity was worse. They spent most of the working day driving, and unsurprisingly were not allowed to use a device at the wheel. Their main window for checking the intranet was therefore at the end of a shift, parked up, when its principal competitor for their attention was going home. And then motive: why wrestle with a slow site to read generic organisational news that had nothing whatsoever to do with the job in front of you?

A tablet-optimised intranet would have solved almost none of this. What helped was removing friction, designing properly for mobile and introducing audio content people could listen to hands-free while driving. None of that is especially clever. It is, in retrospect, painfully obvious — but things often become obvious once you’ve bothered to look.

Mix your methods, and skip the focus groups

Surveys and analytics tell you what is happening and, roughly, at what scale. Interviews, observation and diary studies help tell you why. Treating these as competing methodological tribes is a category error: you need both.

Analytics have one particularly important blind spot in internal comms: they can only show you the behaviour of people who are already using your channels. The employee who gave up six months ago leaves no trace. Neither does the colleague who never had access in the first place, nor the team who have quietly moved their entire working life into a WhatsApp group you know nothing about.

Those shadow channels are often the most revealing thing Discovery surfaces. They show you precisely what the official system is failing to do, because somebody has already gone to the trouble of building a workaround.

One method I’d generally avoid for diagnosis is the focus group. They’re seductive: one meeting, lots of voices, apparently faster than doing a load of individual interviews, and senior leaders love them. In practice, people are much less likely to admit in front of colleagues that they don’t understand something, dislike something or have abandoned the official process altogether. Add hierarchy to the room and it gets worse.

To run one properly you need two researchers anyway, which rather eats into the supposed efficiency. You also have to find a point when eight busy people are free at once, so good luck with that. Focus groups are useful for co-creation and testing ideas. They’re a fairly poor way to diagnose what’s actually going wrong.

Knowing when to stop

Research is not an endurance sport. When the same hypotheses keep getting reconfirmed and new interviews stop surprising you, you’ve hit saturation. Stop. More research at that point won’t make you more certain; it will mostly consume money you could be spending fixing the thing you now understand.

For most comms Discoveries, a part-time project over roughly eight weeks is a reasonable rule of thumb. Larger and more complicated organisations may need longer. Genuinely unexplored territory may need longer.

Then you synthesise: cluster the findings, name the themes, show the patterns and be explicit about what your evidence cannot tell you. Every research method has biases and gaps. The mistake isn’t using imperfect evidence — there is no other kind — but presenting it as complete.

And finally, triage. What’s a quick win? What’s structural? What needs a year? What would require an entirely different operating model? And, crucially, what isn’t yours to fix?

A good Discovery will surface things that look like communication problems but aren’t: a broken process, an unpopular policy, a manager who doesn’t manage, a workload problem, a system designed around a neat version of the organisation that has never existed outside PowerPoint. Being able to tell a leadership team “this is not a communication problem, and no new channel will fix it” is one of the more useful outputs of Discovery, even when it isn’t what they hired you to say.

Do this properly and you arrive at the business case with something surprisingly rare: a clear account of what is actually wrong, evidence that it is wrong, and a defensible view about what to tackle first.

Which seems a considerably better place to start than “we need a new intranet.”

Discovery is Chapter 1 of Digital Communications at Work, the book I wrote with Jonathan Phillips. It covers all eight steps in full, including stakeholder interviews, ethics and synthesis. The research methods toolkit that wouldn’t fit in the chapter is free to download. And if you’d rather not run one on your own, that’s what we do.