Quick tips for setting and hitting deadlines from drone deploy

This interview is part of our Fieldnotes series, where we share how industry leaders are improving different dimensions of the developer experience. In this interview, Olya Royall, Senior Engineering Manager at DroneDeploy, shares tactics she uses to set realistic deadlines and help her team meet them.

Olya: I joined DroneDeploy as an individual contributor over five years ago, and moved into management since then. So some of what I focus on in my role now is a result of having experienced different management styles so recently. One of those areas that I focus on is making sure my team has realistic deadlines. 

Today our team consistently rates “realistic deadlines” highly in DX — it’s an area the team is satisfied with. So here are a few things I think about when setting deadlines and making sure our team’s processes aren’t getting in the way of us delivering. 

1. Get to know the team and the codebase       

It’s especially difficult to estimate for the first quarter of starting a new team. You can use your previous experiences as a manager to set estimates, but you still have to audit how the team does for that first period to see what their velocity is. 

It helps to know the codebase too: if there’s a particularly complex part of the codebase, we can add buffers in our estimates to account for the extra time it may take to work in that area. You don’t have to be “in” the codebase to gain that knowledge; managers can gain that knowledge by paying attention to projects that were delayed or slower than usual. 

Getting to know the team and the codebase can help managers check the team’s estimates. We do t-shirt sizing ahead of the quarter for every project, for example, so we set small, medium, large, or extra large for each project and then see what we can do with our capacity. If my colleagues think something is a medium project, but from my experience I know that working in this area of the codebase tends to take longer, I can push back on their estimates. And as a general rule, we try to set an upper limit of an estimate versus being overly optimistic about what we can accomplish. 

2. Limit projects in flight       

Things move slower when the team is working on a bunch of projects in parallel. We try to limit the projects in flight during any given sprint to one or two projects — even three or four projects is too many. And the team really appreciates this. It helps them stay focused and finish projects faster. 

3. Put engineers on a support rotation

It’s easy to fall into a reactive mode with fixing bugs and ultimately miss deadlines. Our engineering team is around 60 people, and we previously only had one engineer fully dedicated to support engineering. We made the decision to put engineers on support rotations — we have several clusters of engineering teams, and each cluster has its own support rotation schedule. This enables each team to be effective at triaging issues in their team’s domain and frees up the rest of the group to focus on feature delivery when they’re not on rotation.

Each rotation is one week long, and the frequency which engineers go on rotation depends on the size of the team: I have seven engineers on my team, so each engineer goes on rotation once every seven weeks. 

4. Make space for deep work with no-meeting days, short standups, and async status updates

Uninterrupted time is critical for teams to meet deadlines, so we try to be thoughtful about the meetings we schedule. For example: 

1. We have no-meeting Wednesdays. Team members can pair with one another during this day, but otherwise team members don’t have to worry about getting interrupted or making it to meetings.
2. We keep our standups to 15 minutes. These aren’t status updates: we have a chatbot that helps us with status updates (it asks “what are you working on today?” “Anything you’re blocked on?” and “Anything you’ve been particularly proud to work on?”). Standups are for raising concerns, questions, or to discuss blockers. Also worth noting is that we do standups on Tuesdays, Thursdays, and Fridays. 
3. We also have team pairing hours, which are essentially office hours, two to three times a week. Team members block time on their calendar where they know they can pop in and ask each other questions. 
4. Every two weeks we do a Friday fun day, where we hang out for an hour as a team and play games. It’s a way to close out the week and relax with the team. 

Generally, Mondays and Fridays typically have the most meetings and the middle of the week is better for focused time. 

5. Keep a pulse on team sentiment

We keep a pulse on what’s going on with teams using perceptual data so we can know whether deadlines are realistic — and if not, we consider what might be causing teams to miss their deadlines. (Is it the deadline itself, or is the problem other things that are getting in the way?) 

As a leadership group we also meet quarterly to discuss our OKRs, and we always include initiatives to improve areas of the developer experience within our objectives.