Enterprise communication is hard.
On one hand, companies want to achieve good levels of transparency and alignment. Encouraging communication works towards this goal.
On the other hand, leaders rightfully don’t want to share half-baked opinions or on going strategic conversations to avoid creating noise and distraction. Holding up information, in this context, is probably sensible.
Over the past 10 years or so I’ve been in the business of enterprise software development, I observed over-communicating has become an acceptable pattern. The benefits of sharing information most often outweighs the risks.
But, over-communicating paired with emails being used as the preferred tool to broadcast information is working against the original intent.
To protect their mental health and productivity, people are running away and not towards information. In a colleague words, sometimes it feels like “drinking from the fire-hose”.
And more levels you’ve got in your org chart, more this gets exacerbated (entropy).
Depth VS breadth
In his Maker’s Schedule, Manager’s Schedule article, I believe Paul Graham gives us clues to understand why over-communicating can be counter productive.
To get things done, people in the Individual Contributor (IC) track often need to go in depth on a topic and work at a detail level. This requires loading and keeping a fair amount of context in their heads. From a cognitive perspective, this is demanding and time consuming.
When a person in an IC role also has to go through a reasonable amount of information that’s thrown at them on a daily basis, it can be challenging to spare enough mental cycles (or simply time) to focus on something for a couple of hours straight.
This can be, however, less of an issue for those in the management track. Because of the breadth nature of their work, context switching is arguably less painful.
Emails have been abused
Emails, by design, work like a push system. When you send someone an email you are pushing something onto them. The ball is now in their court.
Until not long ago, I was of the opinion that having a good enough set of mailbox rules was the answer. After changing companies a couple of times and playing different roles, I had to recognise I never came up with something that effectively sorted out my incoming emails. Quite the opposite, I felt I was fighting to maintain an ever growing list of rules. The effort was just not worth it.
This made me realise we should maybe repurpose how we use emails.
Defaulting to a pull system
I am now experimenting with only sending emails if:
- either something has a direct impact on people, a team or the company, examples are “you are getting a pay rise” or “we are about to become a public company” or “new rules to get into the office”;
- or when action is needed, such as “please fill out this form by” or “make sure you opt-in to X” or “feedback request” or even “can you please send me this doc”.
For all the rest, I believe we should default to a pull system. This can be achieved by making information available somewhere, like an internal blog post. People who feel concerned or interested can subscribe and engage with.
At work, before I could connect the dots and articulate this idea, some colleagues had already started writing internal blog posts to share their thoughts. I’ve been enjoying this pattern as I know I can delay or even skip reading them. It depends on how interested I am, how much work or head space I have at the moment.
I am now advocating for people in the org to experiment with this idea. I am approaching this as an experiment as, even tough this looks like a more flexible and less invasive pattern to me, I don’t have data to share at this point.
If you feel like you are seeing a similar pattern, and you ever decide to talk to your team about what should be pushed and what can be pulled, I’d be curious to know more.
Diego's notes 