Nobody sets out to have an entire day of meetings.
But then your team doubles. Half your engineers are working remotely. And you wake up to discover your calendar is completely blocked off before you’ve even sat down at your keyboard.
When it comes to productivity, it often feels like you’re presented with a no-win situation. We can get on the same page through meetings and other communication or we can do our work. But what if you could better balance both?
Your calendar is likely a source of tension because interruptions destroy a developer’s workflow. A study from the University of California Irvine showed that workers needed an average of 25 minutes to get back on track after an interruption.
Yet, the needs of your organization don’t have to be in conflict with the needs of your team. You can encourage communication without intruding on a developer’s deep work time. At Bytebase, we’ve built a schedule designed to foster collaboration without sacrificing the space required for individual focus.
Here are our 4 strategies for minimizing interruptions to deep work.
1. Build a schedule for developers.
As a manager, you can give your developers the schedule you wished you had when you were a developer. But building that schedule isn’t always easy because you need time to get aligned on priorities, and it’s easy to forget the mindset of a maker now that you’re a manager.
“As a leader, you’re no longer expected to write the most code, solve the hardest technical problems, or fix the trickiest bugs. Instead, you’re responsible for ensuring that your team can do these things,” writes Karl Hughes, a software engineer and the founder of Draft.dev, a content marketing firm that works with start-ups. “It’s hard for great engineers to move into management because they like being deeply focused on challenging technical problems, not hopping in and out of a dozen meetings every day.”
It may take time; but you have to switch your mindset to facilitate the deep work of others. Creating a calendar with distinct blocks of time devoted to particular types of work enables incremental change in your habits and the overall work culture you’re trying to build. Here, you might want to take a look at the Pomodoro Method, wherein your daily schedule is broken down into digestible 30-minute chunks known as a “pomodoro.”
At Bytebase, we have a daily stand-up meeting for 10 to 15 minutes. That’s our opportunity to check in and ensure we’re all on the same page. If we need to have a project meeting, we put it immediately after standup so that we don’t create more context-switching.
We do this for two critical reasons. It stops our team from having to switch contexts and it enables us to keep our deep work time free of interruptions. Time blocking helps cut down on the mental fatigue from switching gears so we can channel our energy into problem solving.
2. Design an efficient feedback system.
Our work is interconnected; but the challenge is that team members always have different priorities. Waiting on responses or being stuck in a liminal state is an easy way to build resentment and frustration.
How do we make sure we’re giving specific, actionable requests? All of our projects begin with a spec with high level needs outlined by the project lead and presented at the start of a meeting.
We then sit silently for 15 minutes with people offering notes in the comments. This is a key stage of our feedback process because writing can be more inclusive – whether someone on your team is an introvert or likes to process ideas internally before offering suggestions – and offers a quick reference for the project lead on how to tweak a given spec.
Those 15 minutes are incredibly valuable to our team. That writing time gives everyone a chance to voice their feedback and express their ideas. And we often discover issues that need to be addressed, which hadn’t been identified and could have been major headaches if they popped up further along in the process.
The written notes form the basis for a brief conversation out loud, where the project lead asks for clarification or uses a written note as a jumping off point for a quick brainstorming session. At the end of the session, the project lead then has a blueprint for how to update their spec with the benefit of the rest of the team’s experience and ideas.
By eliminating ambiguity, you can streamline your communication to reports and gain back time. Give a clear description of each project task. Make specific, singular requests and offer actionable advice when presented with problems by team members.
3. Create transparency around availability.
A developer-friendly schedule doesn’t only account for meetings, it also creates opportunities for sustained periods of focus. ‘No Meeting Wednesdays’ sound great until someone sees that open block of time and knows that everyone always has a few minutes in the middle of the week.
Instead, let your team know that you value communication about availability. Encourage developers to block out their calendar with focus blocks. Tell your team to set their Slack status to reflect what they’re currently doing. For us, this is a great shorthand to quickly see if someone is in a flow state so that we don’t interrupt a productive stretch.
This is also where you need to pause before you reach out to a member of your team. As Gergely Orosz writes on The Pragmatic Engineer, “you have to think twice before broadcasting information.”
Go ahead and draft a message because the act of writing might reveal something new to you. Then, build in a moment of pause to consider what happens when you fire off that message.
If there’s too many requests on Slack and people feel pressure to respond promptly, then the cost of context switching outweighs the value of answering a question. On the other hand, if you’re completely stuck – see our handy 30 Minute Rule below – you need to be able to reach out.
Before you hit send, think about the importance of the message. Is it worth asking someone to context switch? If you’re stuck and your team values velocity, then it’s worth it.
4. Offer pressure release valves.
Building a resilient committed team requires trust. You have to trust that your team members will be able to solve problems. And you have to trust that they’ll be open to acknowledging when they need help. But how do you build the right amount of runway?
At Bytebase, we use The 30 Minute Rule. If you haven’t made progress on a project for 30 minutes, then you simply post in a Slack channel what you’re doing and the specific challenge you’re trying to address.
This ensures that nobody feels isolated or like they have to tackle a problem alone. It can often help a junior developer or someone working on a project with an expanded scope get unstuck.
It also has the added benefit of strengthening connections among developers. Our team often gains unexpected insights and finds joy in helping colleagues. This is how you leverage the experience of senior developers without sacrificing the autonomy of junior developers.
This simple rule reinforces the feedback process we’ve built as part of our product development cycle. It also ensures that a particularly frustrating bug doesn’t derail an entire block of deep work time.
When you create systems that encourage independence while also making space for collaboration, your team will excel. That success will then naturally strengthen and reinforce a schedule which allows two seemingly conflicting responsibilities – regular meetings and deep work – to co-exist.
Photo by Gaining Visuals on Unsplash.