How to communicate in IT: Extreme Visibility

Have you wondered how to effectively communicate in IT?

Make it visible. Extremely visible.

Abstract

I’ve always felt under-communicated as a programmer. When I struggle with something, this is rarely a technical problem. Programmers love technical problems and I love them too. What’s more challenging is context. What designer had in mind? What are the requirements? Why is something done this way? Oh, I can do this easily another way, can I change it? Will it break existing architecture? How to test it? How to deliver it?

Once all the questions are answered – all tasks are easy-peasy.

I would even say more:

Communication is the bottleneck of IT.

If you want to improve your productivity, maybe you should start with communication. Unfortunately, this may require deeper changes than you think.

Traditional communication doesn’t work

Typically there are no rules and schemas on how to communicate, which is frightening if you agree that communication is the bottleneck (or at least a problem) of IT.

Therefore most companies I know and most developers I know follow natural communication, characterized by:

• inquiring – “I’ll do my job, but feel free to ask questions”
• meeting orientation
• shirking cooperation and communication outside designated slots
• doing “anything” and not caring about the outcome – “Did you forget? I told you about it” (once, a week ago, in a meeting full of various topics)

From my experience, this doesn’t work. Programming has too many moving parts. There’s too much to communicate about comparing to time we spend on doing it.

We can do this a different way.

Extreme Visibility (XV)

Consider the following: if you make a piece of information visible, there’s no need to communicate about it. The more is visible, the less need it is to ask, discuss and meet.

Take it to extremes and you’re in Extreme Visibility.

Extreme Visibility means making everything visible and transparent to (and between) the programmers. To achieve this, communication needs to happen all the time, not only when we decide to communicate up.

It’s not for free. It requires thorough changes in your everyday work, starting from mindset.

Mindset: Async-first

Async-first means that people should be able to acknowledge all the communication in their convenient time, in their own rhythm. This must be reasonably often, but generally – there’s no warranty that the acknowledgment will come soon.

Async-first mindset works best in IT. As developers, we need to immerse in deep work very often. This is where the magic happens. This is where the work gets done. We need long potions of work without distractions. Period. The world needs to adjust.

This mindset changes everything. It effectively undermines the ideas from sync world – meetings, face to face conversations, and video calls.

Having this mindset, you don’t want to think of your message as something temporary. Instead, think about how it will read in 1 month, when everybody forgets the context.

This mindset makes you focus more on how and where to send your messages. Because messages are sent only once but read by multiple people multiple times.

This mindset implies the other laws presented below.

Push information to avoid inquiring

One of the main points of XV: aim for answering questions before they are asked.

This isn’t what most IT companies I know do. They do it in more natural (I think) but less communicative way: “If you’ve got any questions, ask”.

This manner of communicating attracts shyness and mediocrity (I won’t bother the others, they must be busy). What’s even worse – this way promotes tribal knowledge. If all you have to do is answer questions, you’re encouraged to keep the whole context to yourself.

Remember. Tribal knowledge = extreme invisibility.

XV turns the communication around.

Whenever something interesting happens in your work, you push a message. For example: task started, task finished, code review started – such messages aren’t controversial. But this could also be:

• your thoughts, feelings, and impressions
• something interesting you have just learned
• assumption you made
• your hesitations, problems, and struggles – see Bring the pain forward
• you changed your mind
• improvements ideas
• things you’d do differently
• agendas, schedules, re-schedules
• small updates on READMEs, documentation, documents, permissions
• administration status – current availability, planned vacations
• in Pull Request – all the information like a screenshot, link to corresponding ticket, related tasks, historical context (even if you’re not asked)
• in README – all information as if you weren’t familiar with the codebase
• and so on, and so forth…

If you’re not used to pushing information like this, you’ll probably underestimate what’s worth pushing. You’ll discard many ideas on helpful messages “because others may feel spammed “. This is the wrong approach. You’ll learn to reject this feeling. You’ll learn over time to push more messages than you think it’s worth. It takes practice to be willing to push literally everything that may be of any use to somebody.

The rule of thumb – whenever you’re asked about something, think what and when to push to avoid similar questions next time.

The number of questions and clarifications indicates how visible you are. The lower the number, the closer you are to Extreme Visibility.

At first glance, a huge number of messages may feel uncomfortable to you. Typical reactions include:

• This will result in complete chaos! – No, if you implement other techniques mentioned below. Pay special attention to “Tailor-made communication channels” and “Pub-sub”.
• Nobody will read it! – Not so fast. Remember async-first. You never know when your messages are useful. No immediate thanks don’t mean it’s useless. And yes, in the end, some of the messages may be thrown to nobody. I’m pretty sure fewer messages than you think will end up like this. Either way, it’s ok. It’s a price to pay for benefits.
• It takes much time! – writing takes very little time. More challenging is thinking what to write. It’s another challenging part – to word your thoughts. And it’s very useful! Do you want your team to hold back closely unidentified feelings of anxiety? Or would you rather them express their feelings? It’s very similar to rubber duck debugging. You’ll learn more or answer yourself many times, when you turn your thoughts into words.

Remember that people often don’t know what they don’t know. They can’t ask about something they don’t know. Pushing information addresses this problem too.

The premise behind lots of pushed messages is that eventually, you immerse into the stream of micro-communicates. That micro-communicates sum up to the point where you no longer need to guess or ask anything. Instead, you can easily see everything, because everything is visible.

Tailor-made communication channels

Disclaimer: we’re talking communication channels in a broad sense. Not to be confused with Slack channels, which are only one of many examples of communication channels.

In everyday development, programmers use many communication channels. Typically they are (substitute to your team’s equivalents):

• Email
• Slack
• Calendar
• Backlog on Jira
  
• Issues on GitHub
• Pull requests
  
• Documentation
• READMEs
• Code
• Code comments
• Commit messages
• Wiki / Confluence
• Company keychain
• Google Docs
• Offline / meeting / face to face

You should embrace them all. You should carefully choose where to write your communicate, not just do it “anywhere”.

However, you’re not limited to one channel. Typically if you send a message to a distant channel (PR, documentation), you should post a link to it on Slack. This could be useful to keep people in the loop even if they don’t check the original source every hour.

On the other hand, each channel has its destination and you should stick to it. If your message doesn’t belong anywhere, you should create a new channel (Slack channel, Google Doc) rather than abuse existing ones.

Pay special attention to Slack channels. There should be plenty of them – streaming everything in #general is an antipattern. Remember async-first. When you write a message, you’re in the loop. But when people read it, it’s useful to be surrounded by the context.

Being serious about message placement takes practice, and pays off in the long run in terms of self-explanation.

Pub-sub

You should allow other people to freely join and leave communication channels.

Any point in time everyone can join (subscribe) any channel immediately (ie. with no permission needed).

Imagine how useful it is when you join a new project, and you already have much information on #projectX channel. Or when you struggle with some kind of setup, but there’s related Slack thread in #projectY.

There are three types of “subscriptions” we need to differentiate:

• mandatory subscription to channels where everybody (from a group) is subscribed, therefore you can reach everyone at a time: #general, #it-team, email groups. Since this group is mandatory, there need to be a very few of such channels.
• optional subscription to channels where people come and go, depending on time and their interests (#interesting-links, ongoing pull requests, documentation). Most of the everyday communication should happen in this group.
• “sneak a peek” at a channel, when you’re in an unexpected need.

The last group can’t be neglected. The moment when you “sneak a peek” is when you discover the power of Extreme Visibility. The communication is “somewhere there”, waiting to be acquired, even if you don’t look at it at the moment.

In this model, much responsibility for communication is transitioned to the recipient. The recipient is the one who ultimately decides which channels to subscribe and why (or why not). Subscribed channels must be carefully read or scanned, depending or your involvement in the topic.

Developers need to calibrate their set of channels once in a while. If you feel overwhelmed by the number of needless messages, unsubscribe some channels or mute them. If you feel underwhelmed, subscribe to more. Feel free to send suggestions to each other!

Everything public

Being able to subscribe to any channel implies that those channels are public.

You should avoid direct messages, as they can’t be subscribed to. If there’s one piece of advice to take away from this post, that would be: Don’t write private messages.

Always send your messages to a properly labeled public place.

Let everybody know where a document is being prepared, even if it’s still in progress. Maybe they can help you with it? Maybe it’s already useful?

“Everything public” relates to the code too. Things like configurations (linters, code sniffers, etc.) should be committed to the repositories. Bash scripts, dockerfiles that you made and are useful only to you – probably should too. Seeing them by others is the first step to make then useful to everybody.

IT world realised how important is visibility in case of instracture – hence Infrastructure as code movement.

Not to mention tests! Think about it. Automated tests are extremely visible specification of your code.

Bring the pain forward

One thing that misses in async work is those micro-expressions, complaining and small talks in the kitchen:

– Gosh, this is a nightmare. I don’t know how to set this up.

– I can help you, I did it 2 days ago for myself.

In order to not be chained by async communication, you need to mimic this behavior. Whenever you’re in trouble, communicate about it.

Don’t sweep it under the carpet. The worst what can happen is wasting 2 days of work to only find out that your problem is already solved.

There is nothing wrong with sharing your pains. In mature IT environments, people help each other.

Bringing it forward that you struggle with something that you shouldn’t be struggling is the essence of Extreme Visibility. After all, if the IT world was easy and simple, we could let people discover everything on their own. Since it’s not, we need to find ways to cooperate.

This is also useful whenever you’re uncertain about something. You write your assumptions and carry on working. Whenever someone spots you were wrong, they will correct you – and you’ll know.

Sharing your hesitations, struggles and ideas on potential improvements help your team to question status quo. Compare it to “natural” communication, when voicing your doubts is rare, spoken, and can easily perish. This is cargo cult-friendly environment.

Written trumps spoken

Avoid spoken communication. This include:

• meetings
  
• video calls
• face to face conversations

Instead, use written communication. Benefits:

• it doesn’t require immediate attention (async-first)
• it’s more friendly to people who need more time to think or structure their response
• it allows discussion in smaller groups before answering
• it can be read multiple times
• it can be copy&pasted (see Repetition is OK)
• it can be easily sent to more people or more channels
• it can be referred to
• it’s immune to sync communication issues: bad connection, finding time slots, “I have to step out” etc.
• Ask your team if they like meetings. You can learn more reasons.

Treat spoken communication as a last resort.

But please don’t bring written communication to extremes! I don’t mean “no meetings at all”. Meetings are good for a certain kind of communication. I only ask to think twice if you want to make a meeting. Read the benefits above are be aware that you’ll lose all that.

After every relevant spoken communication, you can make a written summary. This way you could achieve benefits from both spoken and written worlds. Unambiguously state 1) who 2) does what 3) when (written in a mail or Slack). You’ll be surprised how many times other people got it different.

The same strategy of summary notes can be used in longer Slack discussions and PR wars.

The Pyramid of Communication is a framework that can help you with judging the right proportions.

Repetition is OK. Repetition is OK.

The spirit of XV is repetition friendly. Remember that people subscribe to the channels at their will. Remember that people read the messages on their time.

If you want your communication to be visible, repeat it.

On the reception side, you should be permissive for repetition too. The fact that you have already acknowledged the message doesn’t mean that everybody has. You can even help by sending a link, complete the message with your own thoughts, suggest how to avoid such repetition, etc.

Feel free to duplicate your message:

• to different channels. Remember this pattern – after you push a message in PR, documentation or whatever else, you post a link on Slack.
• about deadlines and other important dates. Those tend to change. Confirmation that nothing changed could be nice too.
• to more recipients. The people involved people know, the better. Why don’t you tell everybody? Indirect communication may be invisible to some relevant people.
• if it’s retrievable “somewhere there” but you have it at hand (hyperlink!).
• if it’s convenient and easy to achieve. Who said people are the only source of information? Leverage Slack integration, so that the project channels are updated on the fly about tasks status.

Close the loops

“Closing the loops” is the idea from Getting Things Done book. If you’re not familiar with GTD, I strongly recommend reading it.

In short, it means that we should aim for no “open loops” – cases which aren’t decided what to do with. “Loops” in broad terms can mean projects, cases, discussions, tasks, questions…

We should remember to “close the loop”, whenever a case screams to be taken care of, for example:

• an open question in PR
• email to everybody
• request from another team

Remember async-first! People who read it should be able to safely assume what’s happening with the loop. Otherwise open loops drain people’s attention and energy.

There should be perfectly clear from the message what’s coming next. If there is no response, I assume that I’m as new to the case as everybody else. I’m supposed to close the loop or at least bring the closing closer.

There’s a few options available how to close the loop:

• do it at once (and write “done”)
• start doing it (and write “I’m on it”)
• initiate collaboration (and write “Let’s cooperate on this one here: <link>”)
• add to your backlog (and write “added to backlog”)
• point someone to make the decision (and write “@bartek will decide”)
• delegate (and write “delegated to @bartek”)
• eliminate (and write “won’t do”)

No communication ping-ping

Being blocked on synchronization between people is what we want to avoid in XV world. Remember – async-first. Waiting for other’s people response is the worst kind of waste – if you’re able to avoid it.

Aim for providing the whole algorithm what you think should be done in either case. This may feel uncomfortable (what if the other person thinks otherwise?) but in reality, is a relief. You make the decision. The loop is closed. There is a huge difference between the wrong algorithm and no algorithm.

Writing quickly such brain dumps is a very useful skill. Unfortunately, few people communicate this way. Usually what happens is “ping-pong” (asking one more question and open one more loop) whenever there’s some information gap at any side.

You’re free to throw your feelings and opinions left and right. But in the spirit of “no communication ping-pong”, please suggest what we could or should do with it. Acknowledge? Comment? Vote? Schedule a meeting and talk about it?

Lower your expectations

The reality is that you always have to assume some knowledge. You can’t write documetations for absolute beginners (absolute meaning they don’t know how to turn on the computers). The same applies to all communicates. People work in their own loops and have different levels of familiarity with projects, frameworks, codebases etc. You always expect some level of knowledge.

However, what helps in XV is lowering those expectations. Writing a piece of information omitting the whole context, you risk that reception will miss.

This is the best idea for writing documentation or README. The same applies to every message. Remember that you are in the loop and they may not be.

What makes this piece hard is curse of knowledge. Consider lowering your expectations even more than you initially thought.

Optimize for number of clicks

There will be lots of channels and lots of messages. We’ll need to fight for recipients attention. Especially if you work in a collective ownsership-friendly environment.

Therefore it helps if a message contains every piece of information that could be in use.

It doesn’t matter if the information can be found on Jira. Jira is a Slowpoke. Have you ever had to relog from one Jira to another? This takes like 1 minute, and all that provided that you know where the information is. If you force someone to look for the information on Jira, you may discourage them from helping you.

Another example, already mentioned above, but can’t be stressed enough: leverage hyperlinks when talking about something linkable.

Remember async-first. You’ll find yourself as the recipient of your own message more often than you think.

Refine it

Some channels require refining. Duplicated or conflicted entries in keychain may be a good example. Also, READMEs invalidate more often than they are updated.

People should patch incorrect or duplicated information on the fly, whenever it’s spotted.

If it gets messy anyway (it shouldn’t), maybe schedule a time for refining and cleaning up. One a day, week, month, or whenever is convenient in your case. Given that you will be mostly removing or migrating information (most information is already pushed), this shouldn’t be much work.

---

Takeaway

If you want to start implementing Extreme Visibility in your team, I’d suggest the following steps:

1. Change your defaults. Make all communication public by default. There’s very little information that fits private messages – only cases related to our privacy. Other messages should fall into the proper channel(s). If there’s none, create one.
2. You can scan your recent private messages and think where would you put those conversations if you wanted to make it extremely visible. Also, contemplate situations where that information could be useful to someone who can’t read your private messages.
3. Allow your team to point mistakes to each other and correct them. Be allergic to private messages – if you receive one, ask to move the communication to a public place.
4. Embrace that it will take time to make it perfect. Suggest changes, listen to suggestions, and iterate.