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.
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.
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.
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 that’s 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.
Uninterrupted time is critical for teams to meet deadlines, so we try to be thoughtful about the meetings we use. For example:
Generally, Mondays and Fridays have the most meetings and the middle of the week is better for focused time.
We keep a pulse of what’s going on with teams using perceptual data so we can know whether deadlines are realistic — and if not, what may be going on that’s 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.