In our world of rapid communication, it’s easy to forget how disruptive our communication practices can be. We seldom stop to think about how we interrupt others. I’m no exception.
Lately, I’ve been trying to consider the golden rule for time: treat others’ time as you like yours to be treated. In practice, I find that means paying the cost up front with my time instead of distributing it to others.
What do I mean? Let’s look at these cases:
Meetings
Can you still remember the times when someone would tap you on the shoulder and ask to chat “really quick”? Nothing like an impromptu meeting to stop you from finishing the task you were working on. What was the meeting about? Who knows. But we were there anyway, so why not grab a room? Now we do “quick calls”.
Those meetings weren’t always bad. Neither are the quick calls. But too often, they are our first reaction to uncertainty. Our day is soon consumed with “quick calls” and “brief meetings”, and our real work becomes the glue between them. Or maybe something worse happens — we get your actual work done outside of work hours when calls and meetings don’t get in the way.
What if we paid the cost up front and planned the meeting ahead of time?
No meeting should be scheduled without a clear goal — a way of knowing when the participants meet the meeting’s purpose. Who knows, you might realize you can send an email with questions and avoid the meeting altogether — what a victory!
And if you still need a meeting, have a goal for the meeting, a plan, and a hard stop. All the preparation will likely shorten the time it takes to meet.
Pay the cost up front by planning. Don’t spread that cost to the people you invite to the meeting and compound the cost to your company.
Messages
Have you ever been focused on solving the toughest problem in computer science, when a Slack notification pops up saying, “👋 hi”? You quickly open Slack — the solution escaping your thoughts — only to realize it was a direct message, and the person is just now typing a question.
Someone is giving your their stream of consciousness without regard for what you were doing. Oh, and that solution you had in mind, it’s long gone.
It’s good to be a team player, so be kind if you receive that message. But be a good team player and don’t send that kind of message.
When considering sending a direct message, ask yourself, is it urgent? If so, go ahead with it. Synchronous communication directly wired to people’s brains is there for that reason. But direct messages should be the exception.
If you need to ask a question, ask it on a public channel. Others might know the answer to your question (happens surprisingly often).
And when you write the question, take the time to state it fully. Include what you have tried and why it didn’t work. When you do that, you might:
- discover you already have the answer, or
- realize haven’t done enough digging on your own, or
- prepare a great question with all the context needed so that someone can help you.
Pay the cost up front by thinking through the question. Don’t spread the cost to others by interrupting their concentration.
Pull requests
Have you ever been requested to review a 1000+ line pull request (PR)? Say good bye to your plans for that day, right?
The time trade-off is evident with pull requests. Time saved by the author of a large pull request directly translates to extra time spent by reviewers.
If you’re the author of that work, don’t open that monstrous PR. Spend some time trying to split it into independent commits and separate PRs. But be warned: it could take a significant amount of time.
Creating small, independent PRs is challenging work, and it takes a lot of your time. You could spend an extra 4 hours reorganizing the code! You might think it wasteful. But what if that saves each reviewer 4 hours of their time? Well, you just saved your team a whole lot of time and effort. Pay the cost up front. Don’t distribute it to others.
Work tickets
What about work tickets that have single-line descriptions without any context? They’re useful placeholders, but it’s tough to start work like that.
When writing a description for a ticket, spend some time to write out what needs to happen, why it needs to happen, and potential pitfalls you’ve already considered. It can save the person taking the ticket hours of their time, and in this case, probably yours too.
If things are unclear, they’ll probably send you a direct message and say “👋 hi”. They’ll then ask you what the ticket is all about, or more likely, they’ll ask if you can hop on a “quick” call with them and another developer to figure out what the ticket is all about. Avoid that by paying the cost up front. Don’t distribute it to others.