You have 1 article left to read this month before you need to register a free LeadDev.com account.
Scheduling, prioritizing, and context-switching issues may be getting in the way of your team’s productivity. Here are three approaches to overcome these hurdles.
Building software is a creative activity. It has a lot in common with other engineering disciplines, but bits and bytes don’t follow the same discrete rules as steel and concrete. Code is malleable and rules for organizing it are anything but hard and fast.
The creative problem-solving required to work within complex systems requires software engineers to hold a massive amount of context in their heads as they work. That context is like a house of cards, slow to assemble and easy to disrupt. A 2010 study from the Georgia Institute of Technology found that engineers take roughly 15 minutes to begin writing code again after an interruption. What’s more, the same study found that the average engineer only gets a single uninterrupted work block (of at least two hours) in a given day!
The problem here is that interruptions that crop up for engineers are seldom within their control. These sorts of disruptions may come from mandatory meetings, requests from other engineers for help or feedback, questions from their manager and others about project status, customer support requests, and more. Because of this, one of the most impactful ways you can support your team is to minimize the number of interruptions and context switches they have to navigate in their day.
1. Fix the calendar
In his classic essay Maker’s Schedule, Manager’s Schedule, Paul Graham talks about the cascading effect that even a single, poorly-timed meeting can have on an engineer’s schedule. Graham writes, “When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.”
The good news is that this is the easiest place to make improvements. Find out when each engineer is most and least productive on an average day. With this information, see if you can start to move your 1:1s with each engineer to a time when they’re typically in a productivity lull. Try to do the same with any standing team meetings to avoid interrupting as many productivity windows as possible. After that, ask each engineer if there are other meetings that regularly interrupt their work and see what you can do to move or get rid of them as well. A few small calendar adjustments can mean the difference between a focused afternoon and a wasted one.
As you do this, keep your own periods of high and low productivity in mind as well. It does your team no good if you give away your entire calendar to support them and don’t have time or energy left for your own focused work.
2. Reduce chatter
If you walk to somebody’s desk to ask a question, you may be able to read cues like posture, facial expression, and headphones to gauge if it’s okay to interrupt them. But as more of our communication has moved to online platforms like Slack and Microsoft Teams (whether you work in an office or not), we no longer have those cues to guide us. Direct messages and @mentions in group discussions carry a sense of urgency for the receiver that’s often completely disconnected from the actual importance of the message. Fortunately, there are some simple things you can do to improve this.
When you send a message, make sure you include information about urgency. This is especially true if you’re a manager or tech lead, as power dynamics only increase the perceived urgency of your messages. If you don’t require a response, make it clear that you only need an acknowledgment that they’ve seen your message. If you do need a response, but not urgently, consider prefixing your message with something like “at your next break” or “when it’s not interrupting your work”.
You can also encourage your team to make use of your communication platform’s built-in status indications to indicate when they’re focusing. My team uses the headphones (?) emoji to indicate when they’re focusing and the pear (?) emoji to indicate when they’re pairing, so someone doesn’t distract them for something non-urgent. We also make it a regular practice to mute notifications during focus blocks to make sure flow isn’t disrupted.
3. Do less to do more
Juggling too many projects at the same time can be the most insidious source of interruption for engineers. Let’s say there are six engineers on your team, each working on a different project. Even if everyone is fully capable of completing their project on their own, they’ll want other engineers’ input and feedback along the way. They’ll also likely need at least one round, maybe more, of formal code review before merging and deploying their code. It’s easy to see how quickly these interruptions can add up. What’s more, not only does the interrupted engineer have to put down their working context, they have to load the context of a completely different project in order to collaborate effectively.
Work-in-progress (WIP) limits can make a huge difference in this dynamic. Popularized by Kanban, WIP limits restrict the number of active contexts your team can have going at any given time. If your team of six sets a WIP limit of three, that means that every project has two engineers working together on it. They can bounce ideas off one another, pair if it’s helpful, and provide code reviews, all without having to pull someone else into their context. It also means that engineering and product managers have half as much context to juggle, helping them support the team more effectively.
Every team operates slightly differently, but I’ve found the number of engineers divided by two to be a good starting WIP limit for most teams. It’s important to remember that the figure is not a hard limit, but rather a cautionary measure to point out when you might be taking on too much. It’s also good to know that, in this case, WIP limits operate at the project level, not the task level. The two engineers working on a project will often be working on two different tasks in that project, and the project itself can sometimes be pretty broad (“Inbound Customer Requests” for example). There will still be some interruption, but it won’t result in having to move from one project context to another.
It’s difficult to understand just how much time your team is losing to context switching until you start looking for it, but you can hear it when people talk about feeling “frazzled” or that there’s “so much going on it’s hard to keep track”. Using WIP limits to reduce the number of projects your team is working on will result in an aggregate speed-up in delivery because engineers will be spending more time focusing and less time switching contexts.
More focus, more satisfaction
Most engineers are happiest when they’re shipping code. By tweaking calendars, mitigating chat interruptions, and reducing the overall amount of context they’re operating within, you can help your team have more precious focus time to do what they love. Your team will be happier and less fatigued because of it, and your organization will benefit from the increased pace and quality of delivery that comes from it. Though the changes may seem counterintuitive at first, the results will quickly speak for themselves.
