You’re probably familiar with the notion of technical debt and how it affects your team and the software you’re building. It’s a list of shortcuts in the codebase that you know you’ll need to address eventually, like functionality that won’t scale up, a known bug, or the reliance on an old dependency. Technical debt is easy to track but not always easy to pay down. Competing priorities are the difficulty there.
There’s usually an organizational process for acknowledging and cataloging technical debt.
Communication debt is a different beast: it’s all of the knowledge-sharing, messages, and notifications that need your attention, and in some cases, a response. You’re accumulating communication debt right now as you read this. Emails are hitting your inbox, texts are dinging your phone, shared documents are being edited, and discussions are happening in chat rooms you belong to.
You’re accumulating communication debt right now as you read this. Emails are hitting your inbox, texts are dinging your phone, shared documents are being edited, and discussions are happening in chat rooms you belong to.
Communication debt is self-cataloging in some form of a queue. Acknowledgement and processing it is generally a personal matter rather than a team process.
Unlike technical debt, there is no realistic way to avoid communication debt. Perhaps you’re managing it using a deliberate tactic, like “inbox zero,” or maybe you just respond to or ignore messages as they arrive. But that’s you.
What about your team? How are you helping them manage their communication debt?
If you haven’t thought about it, then the implied policy is that everyone triages on their own and possibly responds to everything in every communications queue.
That’s not going to work.
Obviously collaboration and progress require communication, but too much of it in the form of accumulated communication debt will absolutely kill team morale and productivity. There’s simply no way to keep up with all of the messages flying around. In a modern, collaborative software development environment, a glut of systems, dependencies, and other people generate tons of messages across a myriad of channels.
Without deliberate management of communications, your team either gives up and ignores potentially critical stuff (even ignoring stuff takes mindshare, by the way), or tries to deal with it all, leaving little energy leftover to build things.
How Communication Debt is Created
The Never Zero Inbox
When a person joins your company and team, they are usually added, by default, to a bunch of distribution lists. Generally, the bigger the company, the greater the number of lists. Your IT department might have an automated process to add all new developers in your office to DL:Engineers, DL:Boston, DL:Northeast, and of course the highly abused DL:All. Over time, this list never shrinks; it only grows as developers contribute to different projects or functional areas in the organization.
DLs are often a good way to share knowledge, but just as often they fill your inbox with distracting stuff your team can ignore. Things get really noisy when DLs are hooked up to Ops/Devops systems. On the surface, sure, it’s a great idea for all of engineering to know when response times are abnormally high, but the reality is that all of engineering will not be addressing the issue, and each of these messages are just one more bit of debt to manage.
Meeting requests are a subset of the email problem, especially when they are also hooked up to DLs. Meeting culture varies from organization to organization, but asking for an hour or two out of someone’s life span is not a process to be left without guidelines, especially with new hires who don’t yet have a good sense of which ones they need to attend.
Furthermore, the developers on your team known to have unique areas of expertise are especially vulnerable to unsolicited meeting requests, likely without your knowledge, right from day one on the job.
So new hires are deep in communication debt almost immediately. The IT person hands them their laptop, and the notifications from your various build and monitoring systems start to pour in, along with the meeting requests, HR process stuff, and other organizational rabble.
The Endless Chat Scroll
Team chat apps (MS Teams, Webex Teams, Slack) are where communication debt gets completely out of hand.
If you’re lucky, your company has a deliberate approach to setting up and managing channels/rooms, and has enacted some sane defaults for notifications. Or maybe you’re smart enough to tweak the notification knobs into something manageable. But straight out of the box, you’re going to get a messaging mess.
As Jason Fried aptly put it, “Group chat is like being in an all-day meeting with random participants and no agenda.” Imagine how much worse that “meeting” gets at a large company with hundreds of participants.
Not only that, but now you can hook up pretty much any tool your team uses into your chat app. Bot and app notifications can double or triple the volume of messages. The “meeting” just became a riot.
Chat has been around for decades, but company-wide adoption as a business communication tool is still pretty new relative to traditional channels like email and phone calls. The consequence is that there is still no established etiquette for chat, so unless you’ve some clear guidelines in place, it’s an engine for generating communication debt, firing away 24/7. (The bots never sleep.)
Your team members will have to scroll through and parse everything to separate signal from noise.
Two big problems surface pretty much immediately: 1) It takes a lot of time and energy to scan all of these messages, and 2) The person or bot that creates the highest volume of messages will also occupy the most mindshare among your team.
Limiting Communication Debt with Force Fields and Protocols
It’s the modern manager’s job to shield the team from all of this distraction and noise. No one is going to be productive and happy when their communication debt is overwhelming.
It’s the modern manager’s job to shield the team from all of this distraction and noise. No one is going to be productive and happy when their communication debt is overwhelming.
There are two main ways you can help your team with this issue: 1) Filtering the noise before it hits them, and 2) Making sure there are explicit expectations for what and when they need to respond to communications. Call these tools force fields and protocols.
Force Fields
Start by making sure your team’s default setups are as distraction-free as possible. That means interfacing with functional organizations in your company at both the source of the messages and with whomever configures the communication tools.
Other team managers: Set expectations with other managers that they need to go through you to set up meetings with your team members or invite them to chat channels. Let them know you are guarding your team’s time and energy. Reciprocate and do the same for their teams. Be open to making reasonable exceptions, but set a precedent for this if you can.
HR: Get a rough idea of all of the necessary communications from HR to your team members. Document it all and put it in your team runbook (more on that below.) Offer to disseminate HR information to the team yourself if possible. Get involved with the process behind company-wide educational programs and team-building – it’s the best way to ensure your team members don’t have their time wasted with this stuff.
IT: Curate and ruthlessly cull the list of email distribution lists each team member is on. Put yourself on any questionable lists instead, and then decide if your team needs the emails or you can filter for them. Offer to administer some of the lists yourself, which is usually appreciated and a good way to get this process started with the folks who manage this stuff. If your IT folks also run your chat app, cull and curate the list of channels/rooms your team is invited to. If possible, default all notifications in your chat app to “off”, and turn on only the critical ones. (You may have to do this on behalf of your team members instead of tweaking a global setting, depending on your chat app.) For paid plans in Slack, you can also set up default “do not disturb” hours. Get that turned on and configured, and align it with what you’ve got in the runbook.
Marketing/PR/Sales: Sure, all hands on deck to get the word out and make a sale! That’s what keeps the lights on. Just stick yourself into the process before overtures to help are made to your team. After all, you’re the person who best understands who from your team would be a fit for these kind of things.
You: Watch out what you email to the whole team and post to a team chat room, and make it count. You, the team lead, posted it, so everyone is likely going to think they need to pay attention to it, and that means their attention will be diverted from something else. For relevant articles or videos that you want the team to see, use email, not chat. (Chat apps tend to unfurl articles into big, distracting messages with an image.)
Protocols
In the Ops/IT world, a “runbook” is a living document used to outline the steps a system administrator needs to take to deal with certain scenarios. Need to add a new user? See page 4. Want to swap out an app server in the load balancer? See page 10. And so on.
Something like this can work for communication debt as well. The idea is to categorize and list out scenarios team members will encounter when it comes to responding to communications, and to document how you expect them to be handled.
Bigger companies will probably have some kind of HR-furnished employee handbook; this is different. It’s customized for your team and shouldn’t have much overlap with the handbook
A wiki of some sort is best, because you’ll want to update it as you continue to encounter scenarios where your team members are distracted by messages. (We store ours as a bunch of markdown files in a git repo.)
Ultimately, your runbook boils down to this:
Hey valuable team member, I realize you are going to be subject to more messages and notifications than it is humanly possible to deal with. I’m always going to do my best to stem the tide, but here are the reasonable expectations we have set up for the team to respond to it all.
Final Thoughts
Context switching is costly for software developers, particularly when it comes to complicated features and defects. In other words, little notification pings interrupt the flow of your team and ultimately reduce both the quality and velocity of their work. Take time to set up force fields and protocols to limit these interruptions. It’s going to take some effort, and possibly some politicking within your company to do so, but the investment on your part is well worth it.
Most importantly, an effort to stem communication debt conveys a powerful message to your team: your time and focus is valuable.
