Can you accept that in the middle of a Roland Garros final Roger Federer takes out his phone to check an email that he just received? that's stupid you would think. because that email interruption can lead him to lose the championship. But for some reason, we come up to accept that a manager or a programmer can do just this: checking email/slack in the middle of doing something very important and going back to work.

Collaboration vs Communication

There is a reason why we feel unproductive after a day full of meetings, email, or slack. This type of tasks is not the thing that really fulfills a knowledge worker. Think of it this way, as a knowledge worker you're supposed to use your cognitive skills to solve hard and complicated issues in order to create some sort of real value, and communicating about these issues has nothing to do with actually dealing with them.

The fact that we need to tackle a good percentage of knowledge work collaboratively can lead us to make decisions either on the individual level or the collective level (when we have authority) in order to ease communication and remove any process that could slow it. The confusion between collaboration and communication hides the fact that removing processes to communicate can lead to short-term gains but can hurt each individual's quality of output in the long term. The reason behind these long-term side effects is that not all communication enhances collaboration.

Do just what you're supposed to do

Let's take an example to concretize this: let's say you're a college professor and you decide to be responsive on email and LinkedIn all day long, this decision can lead to short-term benefits: now you can answer any student in quasi-real-time style, you can interact with the work of all professors more often, you can participate in your department decision making even when you're out of work. But what is the long-term price to all of these benefits, to answer this question we should first answer a simpler question which is "What are you supposed to do as a college professor?", the quick answer to this is teaching classes and publishing scientific papers.

Now, how being on email and LinkedIn all day can help you accomplish these two goals? the clear answer to this is it can't, but worse, it will hurt your capacity to accomplish.

This applies to all types of knowledge work, but the example targets the individual impact, what about the impact on an organization that relies on knowledge work as the main tool to create value and make money: a tech company.

Let's say you're the CEO of a tech company that has multiple remote software engineers, the default tool of communication that will come up to your mind is Slack and Email, and the default requirement to your remote software engineers is to be responsive on Slack during the working hours. All of this has short-term benefits of course, the engineers will get updates about what's going on in the company very quickly and fix bugs as soon as they arrive. But what are the long-term side effects, again ask the question "What a software engineer is supposed to do?" the answer could vary from company to company but the main outputs of a software engineer are code and system designs, these outputs require multiple hours of uninterrupted focus.

How to fix problems without unscheduled communication?

In the example, an objection that could arise which cites that if we didn't require engineers (and employees in general) to be on Slack / Email all day, then we will increase the time gap between discovering a bug (and a problem in general) and fixing it (especially for companies that deal with a good number of bugs on a daily basis). The solution to this issue is to have a defined process for handling bugs, instead of having a slack or email list where support team share bugs with engineers, you can replace this with a ticketing system where support team create tickets for bugs and automatically the system notifies one or multiple engineers to handle them.

To protect the time of engineers, define a bug-fixer engineer from each team (or specialty) at the beginning of each week, like this, other engineers will be able to work on other projects without bothering themselves with bugs.

In this setup, you can limit asynchronous communication between the bug-fixer and other engineers by using just scheduled meetings or phone calls (in the case of remote engineers). As a result, the bug-fixer will think twice and rely on himself before turning to another engineer simply because most software engineers prefer dealing with code more than dealing with people.

In an ideal world, we can even eliminate this communication by adopting one of eXtreme Programming best practices which is Collective code ownership, following this best practice everyone knows almost everything about the code that is related to their specialty (for example every frontend engineer has an idea about every UI component and every backend engineer has an idea about every microservice that the company is relying on).

Collective code ownership is very hard to achieve in a startup when the headcount is low and time is not just money, it's everything,, and also in big tech companies where there is a lot of code. But to achieve it, Kent beck suggests in his book Extreme Programming Explained: Embrace Change to schedule pair programming sessions very often and also to move people around teams and projects (this requires open-minded engineers who embrace short-term discomfort).

What about managers?

In July 2009, Paul Graham wrote an essay that went viral, the title was Maker's Schedule, Manager's Schedule. Paul argues that most powerful people operate on a manager's schedule that can accept meetings and it is more flexible to accept interruption, in the other hand, people who make things (like programmers and writers) are operating on a completely different schedule that is called the maker's schedule. The maker's schedule requires big chunks of time to produce valuable output and doesn't tolerate interruptions.

In the essay, Paul said that even the top management of Y Combinator was operating on the maker's schedule but he didn't mention why.

But is it correct that managers' job is to be interrupted all day long? managers can argue that their real-time responsiveness can save their business, and this argument seems legit until again you try to answer the question "What a manager is supposed to do ?", this question is difficult to answer because it has multiple answers and I think none of them includes being interrupted all day or not using your cognitive skills to deal with complex issues.

In the professional world, we don't think about this, most people think about management as "Do less, delegate more and make more money" and guess what? a great percentage of companies reinforce this idea by rewarding their managers for responsiveness and communication rather than making breakthroughs and dealing with big issues, which explains why a lot of knowledge workers try to transition to management to consciously or subconsciously stop doing challenging work while making more money.

We can clarify our thoughts on management by looking at a domain where managers can literally be killed and get other people killed if they didn't do their job well: Military operations. What do managers (generals for example) in the army do for most of their time, do they communicate all day long with every soldier? do they use the phone all day long?.

The answer to these questions can be found when you read about General George C. Marshall who was the US Army chief of staff during World War II, this manager could have lost the biggest war in human history (and probably his life) had he communicated without any structure with his collaborators, but instead, he limited access to his time so that he can focus on the global picture and make strategic moves. He reduced his staff from 300 people to 12, and if you were one of those 12 lucky people, there was a process for communicating with Marshall, as Cal Newport mentioned in his latest book A world without email:

"you were instructed to enter his office and sit down without saluting (to save time), At Marshall’s signal, you would begin your brief while he listened with “absolute concentration.” If he discovered a flaw or something missing, he would become angry that you hadn’t noticed and resolved the issue before wasting his time. When you finished, he’d ask for your recommendation, deliberate briefly, then make a decision. He then delegated taking action on the decision back to you."

What does this tell us? As a manager, if you communicate without any structure with your team and other collaborators, maybe you're procrastinating on the real work. The price of this procrastination can lead to killing you professionally or killing your company literally. Having a 2 seconds response delay on Slack can be effective in the short term but in the long term, it will push you to make big decisions without taking the time to consider all the details. The same thing with meetings, it might be a socially acceptable way to procrastinate the real work, (just like reading a huge number of books or making fancy plans without taking any practical action).

What is the alternative?

But if we limit our usage of tools like Slack and Email, what would be the alternative? the alternative can be deduced from all the examples that I cited above which state that you should have a process for communication that doesn't involve back-and-forth unscheduled communication. For example instead of bug slack channel, use a ticketing system, instead of back-and-forth slack messaging, use scheduled time-bound meetings (make sure you don't abuse it), instead of real-time email notifications, check email once or twice a day, instead of long phone calls, use something like Trello.

So the pattern is simple (but not easy), the most important thing is to do it collaboratively, if you're the CEO of a company, instead of telling everyone "Hey guys, we will stop being on slack all day, you know why? because I'm the boss and I said so" this is a terrible approach. But instead, you can explain to everyone what are the bad effects of unscheduled back-and-forth communication and discuss with everyone the alternative. If you stop responding to your boss's messages overnight, you might get into trouble, but instead, you can sit with your boss and explain to him that you get paid to do X and that back-and-forth messaging is preventing you from doing that X effectively.

Last thought

As a knowledge worker, you don't want your resumé to display how many meetings you have attended or how much slack messages you have sent, but in reality, most of us are seduced to spend a great percentage of our time doing just this.

Remembering that distraction has nothing to do with collaboration can help us deal with these tools while getting the most out of them.

Disclaimer: This opinion is valid on July 21st, 2021. I can change my mind in the near future, so check other fresh articles that could disagree with what I'm saying here, if that's the case it doesn't mean I'm contradicting myself, it means that I learned something new.