Three Things My Dev Team Does To Minimise Distractions
How my software development team has taken meetings, communications, and unplanned work under control.
Meetings, communications, and urgent requests are well known productivity detractors for software engineering teams. In this article I’d like to share how my team maintains high productivity by carefully designing the team meeting schedule, optimising team communications, and taking distractions under control to maximise uninterrupted time that each developer and designer can spend on actually doing their job.
First of all, I should tell you a bit about my team so you could get an idea how similar or different it is from yours. My team is building and maintaining the online and mobile banking apps for one of the Australian banks. We are an integrated team of software engineers and designers and we closely collaborate with several teams and stakeholders at the bank: Product, BA, Testing, and other engineering teams. We work in two-week sprints. We have fortnightly sprint planning meetings, daily stand-ups, weekly retrospectives, weekly all-company demos, and regular 1–1s, weekly for some team members and fortnightly for others.
Let’s now talk about how specifically we schedule our meetings, organise communications, and deal with urgent requests to remain highly-productive.
Taking Team Meetings Under Control
Most software engineers don’t like meetings. What they value is uninterrupted time when they can get into flow and actually build something useful. So, to minimise the time we spend in meetings each day and maximise uninterrupted time our team decided to evenly distribute our meetings throughout a sprint.
In addition, we moved most of our recurring meetings (stand-ups, retrospectives, sprint planning, 1–1s) to mornings — right after or before the standup. That freed the rest of the day for most of us to focus on “real” work.
Let’s take a closer look at our recurring team meetings.
Our stand-ups are scheduled at 9:30–9:45 on Monday, Tuesdays, Wednesdays, and Thursday. We use that time to not only update each other on progress but also to resolve simple issues and to socialise as we’ve been working remotely for months and haven’t seen each other much.
Sometimes team members raise an issue at the standup that requires a longer conversation. In that case people involved in that usually stay on the call after the standup to discuss the matter further. That saves time for the rest of the team and helps us keep most of our stand-ups under 10 minutes.
If someone needs to skip a standup — that’s okay. They can post an update in the team Slack channel.
On Fridays we have all-company retro and demo at 9am which may take from 45 minutes to 2 hours. Because of that uncertainty our team runs Friday stand-ups 10–15 minutes after the all-company meeting so everyone could have a short break. Friday stand-ups are optional. They are also more about socialising than about work. To emphasise that we call them “catch-ups”.
We run retrospectives every week on Thursdays right after the standup. However, on the first Thursday of a sprint we have Team Retrospective, where we discuss topics related to teamwork. This is the “regular” team retrospective that your team most likely runs too.
On the second Thursday of a sprint we have the Code Retrospective. There we discuss purely technical topics: technology roadmaps, suggestions to start or drop using specific libraries and tools, practices, and architecture patterns, tooling, CI, technology spikes, etc. This is part of our continuous improvements process for our technical stack. Thanks to Code Retrospectives, we almost never need additional meetings during the sprint to discuss a technical topic.
Sprint Planning Meetings
Our sprints start on Wednesdays and we normally do sprint planning at 4pm on the second Tuesday of the sprint. This is the last meeting of the day and the last thing we do during a sprint.
I run most of my 1–1s either before the team standup or just before lunch time, so they stack conveniently with team meetings or the lunch break. As a result, developers at a minimum have entire uninterrupted afternoon during that day.
We rarely have ad-hoc team meetings. If we have to, here are our typical options for scheduling them:
- have a discussion right after the standup with only the required people
- schedule a meeting right before or after lunchtime to avoid disrupting the afternoon
- schedule a meeting at 4pm or 4:30 — close to COB
- only if those options don’t work we use the time in the afternoon.
To sum up, here are our team’s informal rules for scheduling meetings:
- run team meetings early during the day right before or after the standup or right after lunch
- distribute recurring meetings through the sprint to maximise uninterrupted work time for the team
- keep afternoons free of meetings.
Taking Team Communications Under Control
We typically work in temporary streams of 2–3 people. We expect stream members to support each other: answer questions, review design and code, be a rubber duck, share domain or technical knowledge, etc. Stream members are the first points of contact for each other and they rarely need to escalate their question or issue to the entire team.
To keep team comms even more focused we use a separate Slack channel for each initiative. That way we not only keep all the chat history for a specific project (i.e. building Foreign Exchange functionality in our banking app) or topic (like Accessibility, Design, etc.) in a single place but we also don’t distract our colleagues who don’t need to be involved in a specific initiative.
For example, an Android developer doesn’t need to be distracted by a discussion between infrastructure engineers in a shared channel and vice-versa. Information is still there and available to every team member, it is just if a team member wants a quieter environment — it is easy for them to mute or leave most channels and still be up to date on relevant stuff.
If our team members need quiet time with zero distractions — they are encouraged to turn off Slack, email, and any other form of communication to avoid distractions from other team members. If something urgent happens, we can still reach out to them via phone. However, we’ve never needed that.
Once we tried a “silent day”, when only I, as the lead, was available in case someone outside our team had an urgent question. The team productivity on that day peaked — developers did so much work. I would be happy to do days like that at least once a sprint but most of team members preferred to keep comm channels open.
Shielding (Most Of The) Team From Distractions
Let’s now look at how we minimise distractions such as urgent production issues, unplanned work, customer facing bugs, technical questions from Design and BA, issues with CI, urgent security patches, etc.
Most of those distractions are external, so in our team we have the shared “sweep” role introduced to deal with random distractions and shield most developers from them.
Sweep is a small Slack group of three people who are most familiar with the codebase and the business logic behind it. Those people are responding to external requests and shielding the rest of the team from distractions. I’m one of the members of the sweep group. I handle about half of those requests.
Sometimes sweep has to delegate requests to developers but nonetheless we manage to handle maybe four out of five external requests and help the majority of the team maintain focus.
To sum up, here is what our team has done to maintain high productivity:
- to reduce the impact of meetings on our performance we are evenly spreading them over a sprint, run most meetings in the morning before or after the standup, and avoid scheduling meetings in the afternoons to maximise uninterrupted time during the day;
- to minimise the impact of team communications we have several Slack channels dedicated to specific topics to shield team members from the information that is mainly “noise” for them, while still keeping it easily accessible should they need it;
- to minimise the impact of urgent requests from other teams and stakeholders we have a special “sweep” role to shield most team members from such interruptions and let them focus on their tasks.