GitPrime elevates engineering leadership with objective data. In this interview series, Engineering Leaders talk about how to build high performing teams.
Reader discretion advised: We are going to use a dirty word a lot in this post. The one that starts with D. That’s because we’re here to talk about… deadlines.
“If we’re talking about setting deadlines, we’re talking about predicting the future, which is an inherently dangerous and scary thing to do in software engineering,” says Jeff Ammons, Engineering Leader at One Medical (formerly VPE and Product Management consultant at Blue Raven Consulting).
Not only can we not predict the future, but engineering requires a great deal of flexibility. We find stuff in implementation that wasn’t anticipated, and there’s business influences that aren’t even in engineering’s control. So how on earth are we supposed to set deadlines, let alone manage them?
Ammons, who was also previously a Senior Engineering Manager at Slack, has a dual perspective to understanding how to set and manage those ever-confounding and ever-moving deadlines.
“I’ve worked in both engineering and product roles, so I understand both sets of incentives, which has been valuable in being able to talk to both sides and translate between them,” he says.
In talking with us, Ammons offered three frameworks for thinking about deadlines: the levers involved in completing a project, the degrees of freedom in the process, and rallying support for deadlines on a human level.
Framework One: Levers
Ammons identifies three components baked into the concept of “deadlines.” These are – in interchangeable order – the deadline date, the scope of the project, and the resources available (in terms of both engineers and finances).
“As an engineering manager, there are three different levers that you can pull,” Ammons says. “They’re somewhat interdependent, so you couldn’t say, ‘Keep the date and keep the resources, but double the scope.’ I mean, you could say that, but probably it would lead to a missed deadline.”
“In most cases, if you’re not willing to adjust those levers, you will miss the deadline. Ideally, the deadline is being set in sane ways though, which means smaller adjustments.”
As an equation, the relationship between target date, scope, and resources are a lot like the ideal gas law, PV=nRT. You can’t alter one component without impacting the others, just like you can’t change the temperature of a system without affecting pressure or volume.
A realistic assessment of a project’s scope and resources can lead a project manager to set a realistic deadline date. And Ammons reminds us to view a deadline date as a flexible variable as the development is under way – because just as there is no “ideal gas” in the real world, there’s also always unforeseen circumstances in software development.
“Let’s say we’re 10 percent of the way through a project’s development and we’re now 33 percent of the way through our actual time,” he says. “The mismatch there sets off a trigger in my head that says, ‘Okay, we’ve got resources, we’ve got our actual date, and we’ve got the scope of work. Let’s go talk to the people who own those things and figure out if we can get help, or if we can change the date.’ As early as possible in the process is always best.”
And with his experience in both the business and development worlds, Ammons understands that deadlines are a conversation between those spheres.
Take the above example of a team running behind schedule on an original deadline. “Based on that, you can ask the business folks what choice they want to make,” he says. “Would you like to proceed forward on this path, knowing that certain downsides are going to occur, or would you like to spend the extra time and launch when the product is ready?”
“As long as we are able to voice opinions and the product team has heard us, that’s a healthy dynamic.”
If the engineering lead accurately gives those choices, it is ultimately up to the business to make a decision. “Obviously I will probably have an opinion on that and engineering will have an opinion,” Ammons says. “And I feel like as long as we are able to voice those opinions and the product team has heard us, that’s a healthy dynamic.”
The big idea to keep in mind here is that setting a deadline is a best-guess process at the outset of a project. These variables will inevitably change over time, and the best approach is to be nimble in addressing changing circumstances.
“In most cases, if you’re not willing to adjust those levers, you will miss the deadline,” Ammons says. “Ideally, the deadline is being set in sane ways.”
Often, because you’ll have a set number of people on the team and funding available, scope is the easiest lever to adjust. “We might realize new things, we might be able to cut some work out,” Ammons says. “The first piece I will look at is can we adjust scope in order to hit this deadline, or how do we lock down scope, how do we control that?”
Framework Two: Degrees of Freedom
Locking down the scope of a project ties into Ammons’s second framework for viewing deadlines: degrees of freedom.
“The more degrees of freedom you have, the more possible outcomes you have that can result in problems or surprises,” Ammons says. “Anytime you can lock down one of those, you’re going to be more effective. You’ll be able to predict the future in a better way.”
“It doesn’t need to be a hundred percent locked down, but even if you lock that down eighty percent, you’re better off.”
At the beginning of a project, you probably have a statement that says something like, We want to build a new enterprise product for this company. And there’s huge amounts of freedom there.
“What does that mean, ‘We want to build a new enterprise product’?” Ammons asks. “What features are involved? What’s version one look like versus version two, version three? Which customers are we trying to serve? Who’s our designer? What is the design going to look like? Each of those is a degree of freedom that has to be at some point locked down and decided on before engineering can fully participate.”
To lock down degrees of freedom, Ammons suggests picking the biggest thing that’s generating variability in possible end states. That’s likely some description of the anticipated needs of the product. “Lock that down,” he says. “It doesn’t need to be a hundred percent locked down, but even if you lock that down eighty percent, you’re better off.”
Ideally, you’re starting with the big picture and then going more granular across the board. To visualize this process, Ammons shares an analogy he stole from a sculptor he knows.
“When you’re sculpting, you want to keep all the levels of the sculpture at the same level of detail,” he says. “You don’t want to come in and detail the eye before you’ve gotten to the point where you know the head actually belongs here. You kind of want to rough it out: here’s the head, and here’s where the arms and the legs are going to be, and then you can come in and start adding a little bit more form. Finally at the end, then you’re going to detail the whole thing.”
“The more degrees of freedom you have, the more possible outcomes you have that can result in problems or surprises. Anytime you can lock down one of those, you’ll be able to predict the future in a better way.”
In software design, that applies when you have, say, ten chunks of features. You don’t want to break one down to extreme granularity when the rest of the product is still at the business level. Move them along in parallel to bring the entire product along for the ride. And as best you can, take each feature to as high a level of granularity as your deadlines realistically permit.
Framework Three: Rallying support for your deadlines
Of course, deadlines are one thing on a calendar. They’re another with real human beings, who respond differently to having deadlines imposed on them. So how do you rally support for your production schedule?
- For starters, acknowledge that the deadline itself is perhaps not the most valuable outcome of setting a deadline.
“I find that the process of estimating deadlines is often more valuable than the estimates themselves, because it forces the engineers to think through the project,” Ammons says.
“Nearly every product that I’ve ever worked on, I look at the surface level of a new feature and think, ‘Oh, yeah, that’s easy. That could take me a few days, it’s fine,’” he admits. “Then I ask myself, ‘Okay, what’s actually involved in that surface level?’ Suddenly I enter this rabbit hole of spiraling things and fabrications of problems that are going to occur. It’s optimism bias, where we look at the surface and we miss the rest of it. Having some process that encourages looking at the rest of it and trying to think of how it’s going to proceed is incredibly valuable.”
- Then recognize that deadlines are a target tool, and how your team uses that tool depends greatly on the individuals on the team.
“Part of deadlines is having a target,” Ammons says. “Some people really are motivated by that. Some people are stressed out.”
Oftentimes teams will have a mix of both of those types, so it’s helpful to remind everybody that the deadline is a tool: it exists because it’s performing a function. If the deadline is not helping you, then you can (and should) fix it. That may mean not having deadlines, so long as you’re still able to deliver results. And it may mean that you change the deadline to a more accurate or realistic time.
- To relieve do-or-die pressure from your team, consider giving different internal and external deadlines.
It can really help a team if a target isn’t a hard-and-fast, hit-this-no-matter-what date. “If my team hits their deadlines eighty percent of the time, I’m pretty happy with that,” Ammons says. “If I need to increase that to ninety-five percent, then that’s going to obviously skew how far out I’ll put a date. I like to communicate separate deadlines – internally and externally. That way, engineering has a target, but still has some breathing room.”
How you play the internal/external deadline game depends greatly on the culture of your company.
“If I work at a company that’s fairly trusting of their engineering, and they understand the engineering is hit-or-miss as far as deadlines, then I will oftentimes just communicate that,” Ammons says. “I’ll say, ‘Hey, we think it’s going to be six weeks.’ If I’m working in an environment where either there’s a lot of dependencies on that deadline, or there’s negative reactions when engineering misses deadlines, I’ll establish two separate deadlines. Internally, on my team, I’ll set a date that we keep amongst ourselves. Then I’ll add two more weeks to the date (or whatever the appropriate amount of time is) and communicate that target externally. Ultimately, I want to increase confidence at all levels by adding that buffer.”
- Be real.
No matter how you pull the levers and limit the degrees of freedom in a project; no matter how you set your deadlines, remember that your engineers can only do what they can do. Which sounds all Zen and obvious, but we exist in a world where businesspeople and customers want everything done perfectly, and by yesterday.
“I feel like engineering’s job is to represent reality in conversations,” Ammons says. “Not to say no, not to say, ‘We’re just not going to do this, this is ridiculous, this is impossible,’ but just to say, ‘Given this deadline and this scope and this set of resources, I believe we’re capable of doing this much.”
Because while we may not be able to predict the future, we can still set expectations for the present. And that’s a helpful and practical approach to setting and managing deadlines.