How to overcommunicate when everyone around you is overwhelmed

One of the puzzles that I’m still yet to crack is, if communication is so important, why is it still so hard? Isn’t “overcommunicate x3” as general advice enough to steer people towards that? Can’t simply talking more, or more frequently, just work? In this post, I’m trying to make sense of abstract process of passage of the information, and talk a bit about what I typically do (which might or might not be working).

People are overwhelmed

Let’s start with one assumption: people have so much stuff to do, they can’t follow anything else. Otherwise they would, right? That’s not how it works though: in almost every organization, every person reaches a point where they are at the attention limit.

Other times, people would like to follow, but they are out of context most of the time, and it’s hard for them to unpack the latest message that they see. “We’ve released the second beta, but, after receiving customer feedback, we decided to postpone GA release until critical bugs are fixed”, someone says. You’re certainly out of context on this one, so you mind goes, What’s second beta? What was the first one? Who are the customers involved in beta, and what makes us care more or less about their feedback compared to anyone else’s? The hell is GA even? I’m a designer, I’ve no idea what GA means, Google Analytics? Critical bugs — cool, how many? About what? What does it mean they’re fixed, who tells when they’re fixed? And finally, what other conditions are implied here, that no one talks about but kinda assumes people know? Like, if not all critical bugs are fixed by end of the year, are we still releasing? You end the stream of curious consciousness by asking silently: if we do not, in fact, release until end of year, is our team’s funding getting cut?

The problem with all that, is that unless people are fully immersed in making things, they are out of context — even if only a little bit. And being out of context builds up.

Can’t simply unoverwhelm people

It’s unlikely that you are in a position on the org chart where you can single-handedly lift the burden off the people who are overwhelmed. I mean, if you can, good on you, let’s go do that, I’m gonna watch. So far no one has invited me, so I kinda intuit things are a bit more complicated.

So, looks like you can’t simply solve the issue of people being overwhelmed. But you can do something to ease it up a bit. And you can do that in a way that people start mimicking you, easing it up even more. Who knows, maybe eventually you will, in fact, make a systemic change, and people will be less overwhelmed. I’m going to talk a bit about where I started.

Explain things

Say, you’re talking to a manager about the last two weeks of your team’s work. You have just explained what an amazing achievement for the team it was to have learned so much, but unfortunately they couldn’t make a release. You talk a bit about one person having been off for two days, which the team had known about, and another person for one day, which was unexpected. You briefly mention Kubernetes (still big in 2021) and how the team initially had trouble with it, but then got it together and configured secrets and deployments, so that now ops is a breeze. At some point you see the manager’s blank stare (pff, managers). It doesn’t take too long before you realize, they’re about to ask you some questions.

So the manager goes, “The goal of our sprint was to release, and it didn’t happen, why?” You try to recover: “But experiments, Joe got sick, Kubernetes...” You go deeper into what each of these things means, because it’s very important, but at the same time can’t shake off the feeling that you are being evaluated. That’s not a good feeling, because it’s right, and it’s based on one very simple change: instead of operating with facts, the conversation took a turn into the heuristics land, where everyone makes a few superficial observations and then, based on this utterly incomplete data, makes a very strong (and probably unproductive) conclusion. It sucks to be in heuristics land.

So it looks like brute force explaining things doesn’t really work. There are two alternative paths, that I know of, that lead out of this situation: either use the language of the recipient while keeping the same amount of information, or use a lower-level language with a higher amount of information. For the former, we can talk about it next time. For now, let’s focus on the latter.

Speak lower-level language and give more information

I found that a lot of people, not necessarily managers, are receptive to lower-level language: the language of facts and evidence, where your body language and confidence you exert don’t play into overall picture. You can be the most introverted person with the crappiest presentation skills in the world, and still deliver the message, because you speak data, and data doesn’t have emotion.

Here, I’m not proposing to slide into management-speak and say things like “our team’s capacity had been reduced by 5%”, that’s nonsense. Don’t reduce people to data. It’s okay to operate abstract units, like projects or even teams, and speak data and attributes, but people aren’t fungible.

Still, when it comes to operations (as opposed to vision), there’s usually data that is (or can be made) available. If you look at a project, it’s already a unit that can be taken as is, put together with other projects, and analyzed. If you break down that project into releases and work items, that’s also a collection of units that can be analyzed. Similar objects can be put together to form a metric, and that’s where lower-level language starts playing out.

Track metrics, put them on a dashboard, and show it to people

A good, well-crafted dashboard that shows a few important metrics is the first step towards successful overcommunication. If any person in your organization, regardless of the size, can open this dashboard and get at least a bit of insight they need, you effectively got part of your communication work done for free. Neat.

The challenge here is twofold:

On one hand, different categories of people require different insights. Say, a designer and a product manager would be looking for different information. Oftentimes the data is going to come from a handful of sources, and there’s often an overlap: if you collect runtime operational data for your digital product, a designer can get insight on how much one particular feature (or its variation) is used versus another one and a product manager can get insight on how much time (and clicks) users spend getting their job to be done successfully done. An engineer, in the meantime, would look at error rate per click. Still, it’s not easy to craft a dashboard that isn’t bloated and yet delivers to its consumers.

On the other hand, come on, dashboard? “I’m inspired by creating this dashboard,” said maybe the first seven people in history who did that.

Still, this overcommunication survival tactic, to communicate without spending time talking about things, pays off pretty well. The time you save, minus the time you spend maintaining the dashboard, is still likely to be worth it.

The problem with the dashboards is that they aren’t easily discoverable. In any moderately sized organization, the number of dashboard is so high, any individual can’t know them all. What’s worse, they are usually hosted in different locations, — which leads us to the next point.

Host all the dashboards (and data?) in one place

This one is hard, but I think it can work really well. That’s why data engineers in BI teams spend time setting up data lakes, I guess. The whole idea is to provide one place for everyone to go to, so that they could learn one tool and one URL, and learn to orient themselves and find the right widget on the right dashboard, — or even create one that fits their needs.

“But how is that related to overcommunication?” Yeah, I expected this question. It’s not directly related, because you don’t communicate by collecting the data. Of course there’s a few steps ahead, where the data is reduced to useful metrics, and where the software presents those metrics in human-friendly way.

But it discovers one interesting problem: people don’t check the dashboard, unless that’s part of their job. And checking dashboards is almost never a part-time job.

Say, you want to tell your team members that they need to stop what they are doing and focus on something else, because a drop in some product success metric is clearly showing the users are suffering while engineers are happily adding more stuff to a broken product. You probably can do that, but this decision won’t be immediately obvious to someone outside the team who still holds the stake and needs to understand the reasoning. Guess they need it in writing.

Make progress traceable, write things down

I’ve had officially one-sixth success rate at landing in a company that cared about documentation. Five out of six times, even if there were individuals who understood the value, in general committing thoughts and discussions to durable, persistent storage wasn’t recognized or valued. In some of those cases, I had managed to turn things around, but in others I had to capitulate and go with the (ephemeral) flow.

Why make things traceable? Because that’s how you not only retain a snapshot of organizational memory, but also one extra dimension: organizational learning process. With evidence like that, you have a good shot at avoiding going in circles, especially at team and org levels. People come and go, tribal knowledge distribution via storytelling works slowly, and the org might not be able to converge if the turnover is too high and the knowledge replacement frequency is also high.

How to make it traceable though?

I found that persisting documents and records is very important. Records are one-time and immutable, and the purpose is to not forget, while documents are supposed to be frequently edited and read by people.

On each team, there should be at least one person who cares to do that and who is skilled at that. If you’re a hiring manager and you can hire that person, do that. If you are a manager in the org where you can change things, such as make doc skills formally recognizable (in the formal job performance review framework and/or career progression), do that. That is, if you like to work on something that solves a big org survival problem, such as organizational memory loss, and requires lots of Sitzfleisch.

Once there is one person, and they’re given enough recognition for what they do, watch other people pick it up. They will probably fail, — and that’s because documenting things requires a skill that is different from verbal expression in a human language or writing characters in a programming language so that they compile, and people by default don’t have this skill. Unless you test specifically for that during the interview process, which is awesome.

The most important thing here is, you really do not want unqualified people evaluating unqualified people. You don’t want a junior software engineer to evaluate potential changes in the system architecture and tech stack, because they are not qualified, as in, their forecast is unlikely to be true unless due to a lucky coincidence. Same with writing: you really want to put people with strong writing skills in a position to evaluate other people’s writing skills. If you’re doing things right, at some point in time there will be enough of highly-skilled writers who write human language and who can provide meaningful feedback to other people. After that, it’s a flywheel.

Now, let’s put everything together.

When do data and writing pay off?

Here’s a few scenarios that I found to be perfect for tapping back into data and written docs.

A project went sideways, and the team comes together for a retrospective

Retrospectives are typically like this: the team comes together and talks about what went well, what went wrong, and such. The problem with that is, humans have this nasty last-minute bias. They give undue preference to events that happened just a few hours ago over those that happened a few weeks back. It’s good that we don’t focus too much on the pain of the past, but it’s not particularly helpful when we’re trying to deconstruct our progress and make a few changes in it for the future iterations.

It’s much better when all the evidence is already in place, as records and (optionally) documents. If they’re cross-linked and can be “walked”, even better. Now it’s not about trying hard to recall what happened last Thursday or in the middle of last month, but rather filtering the docs for only the relevant ones, taking key facts from them, and putting them together to form a timeline.

A typical retrospective is focused too much on the recollection step, where people try to remember things. People sit there, in the meeting, try to remember things and feel awkward. Some think they’re wasting time. Some have poor memory and can’t remember important stuff. It’s messy.

A retrospective where all the content is effectively prepared in advance and simply needs reduction to a meaningful insight, — now that’s a productive one. That’s where teams can focus on action, on improvement, without feeling bad about the past and trying to manipulate facts by downplaying evidence that doesn’t feel particularly good to them personally. As much as blameless retrospectives are praised, people’s behavior is much more complicated, and there’s just too many factors. Removing those factors by having all the evidence in advance makes a discussion much more productive.

Someone wants to get a promotion and needs to provide evidence of job performance

You feel very confident and you claim to be at the next level on your career path. Cool, now it’s time to convince people who are responsible for examining your performance to give you a “yes”.

That’s one of the cases where absence of evidence is considered evidence of absence. If you have nothing to show for your claim, you’re not getting it. No promotion if no one can confidently tell why yes.

A typical scenarios is, people start scraping for bits of evidence in different admin tools (it’s almost always unmistakably Atlassian), ask for peer reviews, the whole process is stressful and has a sense of urgency beyond manageable.

What’s better is when each achievement has a record of events, decisions, plans that can be traversed back to the origin. A chain of proof. When it’s in place, the job turns from collecting data into reducing data: given all the traces that are available, rephrase them in a way that will fit for the purpose (getting promoted) while omitting unnecessary details.

Existing team member leaves the team, and there’s no one to replace them immediately

Unless it was a team of one, there’s always one or more people who are going to stay on the team and who, in some combination, can take over all the things that a person who’s leaving has been working on. In theory.

In practice, there’s a lot in each person’s head. They might not be able to — or willing to — serialize that into docs and/or transfer that to another person. That’s because listening comprehension is pretty low, and because you have to speak exactly the same language the other person speaks, and to be able to do that, you have to know majority of the things they know, and that’s just not possible. Also, it’s not practical, because they’re leaving, it’s probably gonna happen soon, and you’re just short on time.

Getting things that the person who’s leaving the team has been working on and that require a handover is always hard. It’s much harder when it’s done “just in time”, during a short time between the words “I’m leaving” are said and the moment it actually happens. You know what’s better? Keeping the trace continuously. This way, the handover work is going to reduce to compiling a sequence of links to docs. Considering that the entire team participated in writing or editing of these docs, it’s not as lossy as people keeping information in their heads or private notes.

A new person joins the team and tries to make sense of what’s going on

I’ve been there a couple times. I join the team, and people are energetically working on a sprint. In some cases, someone from the team or the org would talk to me about what’s going on there, what’s beyond that sprint, what’s the big goal. Such onboarding would fit into two or three hour-long sessions, and that be it.

For me, being able to traverse the history of decision-making of the team I just joined, to relive their discussions and understand what led the team to be in its current state, is a real time saver. Above all, it makes me believe that the team got it together. I’ve seen other folks, especially ones with not so much industry experience get into the team’s daily business quickly when they realized that, at some point in the past, no one on the team knew how to do things they’re doing now, — until they did, and the path towards that is also documented.

Bonus: how not to overcommunicate

A brute force approach to overcommunication is to just talk to more people, longer. That’s bananas! I mean, creating alignment is important, but you know what’s even more awesome? Creating value. It doesn’t matter whether you’re a leader or a manager on the team, and whether the organization that surrounds the team is 20 or 20,000 people, — this approach can make you lose your mind at some point.

I’m not a big fan of meetings, and I think that trying to overcommunicate this way, via meetings, is going to be fun for some time and it’s definitely going to, short-term, open up some good opportunities to learn and maybe even win some professional growth and career progression in the company, but it might as well clash with things that are more important. Like, making sure people on your team are sane and healthy. Going too proactive and head-on with communication, usually focused purely on work aspect, leads to losing human touch with people. That’s especially dangerous when everyone is working from home.

Finally, trying to teach people skills they don’t want to learn is unlikely to work. If you’re stuck in a conversation with a product manager, and they ask something like “what’s Kubernetes and why is it blocking us?”, you might fall into a trap of answering the first part of the question as much in depth as you would the second part of it, but hey, that’s probably not of their most concern! A product manager might be even genuinely curious, but at some depth level will reject the idea of learning a deeply technical skill, — if that was motivating for them, they’d probably have chosen a different profession. Trying to teach someone something they have no interest in learning is usually a waste of time, — but the flip side of that, the side where you communicate just right amount of info, is a great exercise for communication skills!

---

This one turned out to be long. If you found it interesting, feel free to join a discussion on Twitter. Share your story, and happy overcommunicating!