Let teams talk to other teams
Internal comms in action

Before you dive in: this is thinking-out-loud. Some of this might need revising later. I’m writing this down to help me think it through.

In lots of large organisations, it’s hard for teams to broadcast their activity to other teams. I keep bumping into this, in project after project, with client after client. It sounds like a ridiculous problem, one that shouldn’t be hard to solve. But it keeps cropping up, and every time it does, it is hard to solve.

I’ve noticed what I think are some common themes:

Let’s delve deeper.

Internal comms as a tool for management

What is internal comms actually for? In some organisations, it ends up being a tool for senior management to send messages downwards. Internal comms people working in this context have the toughest of jobs: being the conduit for bad news from the management. Even worse, sometimes they end up being a conduit in the other direction: having to pass grievances back up the hierarchy from people further down.

So, back to my question: what is internal comms for ? What is its purpose – or, what should its purpose be?

I’d argue that part of its purpose should be enabling team-to-team communication. Internal comms should be about helping teams talk to other teams, helping teams broadcast their status, their progress, their backlog. Not everyone is a natural communicator, and not every team will find this task easy, no matter what tools they have at their disposal. So having some communication professionals on hand for help, guidance and encouragement sounds like a good idea to me.

I just mentioned the tools; let’s talk about the tools.

Having a platform doesn’t mean you’ve solved the problem

I’ve worked with a few organisations now who, when prompted to talk about the “let teams talk to other teams” problem, just reply with: “Oh we’ve dealt with that because we’ve paid for Slack / Microsoft Teams / Sharepoint.”

There are many tools out there that help with communication, but simply paying money for one of them doesn’t necessarily mean that you’ve fixed your internal comms problems.

Most of these tools do a good job of helping with day-to-day communication like meetings and calls and text chats. That stuff works pretty well.

But a recurring problem I’ve seen is teams who have nowhere to publish stuff in a way that their colleagues in other teams can easily find it and read it.

(Fine, some people say: publish everything on the open web. Make things open, etc. Believe me, I’m all in favour of this where it’s possible but I also recognise that it’s simply not always possible. Organisations can’t always say everything in public. They can often say more than they already do, but that isn’t the same as saying everything.)

So, how can Team A write and publish reference material about its work, in a way that’s available to all the other teams in the org but isn’t published on the web? They could use a wiki. A password-protected blog. Notion can work well, particularly for smaller teams. There are options; but finding the right one is a difficult task that requires thought, budget, and ideally attention paid to the user needs that must be met: those of the teams.

Even though it’s important (well, I think it is, but I would say that wouldn’t I?) few organisations make the effort to invest in people and money and user centred design just for the sake of internal communication. It is important, but it’s rarely seen to be important.

“No we don’t really do that here.”

So because the job of internal comms is defined to be something specific relating to hierarchy and control, and because no-one stops to think about investing in whatever’s necessary to create or buy or put in place the right tools to make it work, the culture required for teams to broadcast their work to other teams never gets a chance to grow.

With the result that teams don’t do it. Teams do their own thing, and report upwards as directed, but don’t – usually can’t, at least not easily – communicate about their work to other teams.

I’ve lost count of the number of times I’ve been working with an organisation that has many teams, and I’ve asked how they communicate with one another, and the answer is: “Well, um, they don’t.”

“It’s in last month’s progress report.”

Often, in circumstances like that, the main vehicle for team-to-team communication ends up being the governance reports that go up and down the chain of command. These are usually documents that teams have to produce to justify their existence, and to secure their next chunk of funding. Documents like this get prioritised, they almost exist by default. And once they exist, it’s easy to use them as a way of answering other people’s questions.

The upshot: documents intended for one purpose get used for another. When Team A wants to know what Team J is up to, they end up being sent one of these governance documents, because it’s a thing that already exists. Bung it over in an email, and problem solved, right?

No, problem not solved. The governance doc might say some helpful things, but it’s rarely the right thing to send. Something that meets this need: “As a manager, I need to know what Team A is up to, so that I can decide how to direct their work,” won’t be the same as something that meets this need: “As a colleague in Team J, I need to know what Team A is working on, so that I can learn from their successes and mistakes.”

Still searching for the right how-to

Like I said, I’m thinking out loud here. This is a problem I keep seeing, but I’ve not come up with any good solutions yet. Simply getting management to notice when it’s a problem, and think about things they could do to make a difference, feels like a good first step.

Filed under: work
(27 March 2021)