You have 1 article left to read this month before you need to register a free LeadDev.com account.
Navigating deadlines is a challenge for every engineering manager.
In my experience, the majority of deadlines set by businesses don’t actually matter. Particularly in the world of continuous delivery, strict deadlines can be difficult to justify because the costs of releasing software are cheaper than ever, and anything that needs to go out today can just as easily go out tomorrow. So, what’s the big deal?
Although in spirit I’m a ‘no deadlines’ person, I’ll admit that there can be a lot of value in them – if they’re set at the right time, for the right reasons. In this article, I’m sharing my playbook on the topic, explaining why strict timelines are often unnecessary, while also highlighting the benefits of setting the right deadlines, to help you build happier and more creative engineering teams.
Most of your deadlines are malarkey
Having worked in a number of industries I have found that outside of the cadence of a particular industry, most deadlines are imaginary. What do I mean by industry cadence? When I worked in education, the cadence was governed by the academic school year. When I worked in sports, our shipping schedule revolved around the starts and ends of professional sports league seasons. When I worked in e-commerce, Black Friday was basically the one true deadline.
But outside of those important dates, any additional deadlines tend to be arbitrary, self-imposed, and lacking any tangible repercussions. In other words, they ring with false urgency often born more out of fear and anxiety than anything else. At this point, your problem is twofold: Firstly, your team is probably pretty good at sensing these things, and secondly, there is perhaps no faster way to shred your credibility as a manager than to create these types of deadlines.
So, tip number one is that it’s completely reasonable to use deadlines where there is true urgency for your company. Trust that if the stakes are indeed high and you’ve done your job well, your team will rally. If you do find that you’re freaking out about something and your team is not displaying an equal amount of concern, there is usually some information you know that they don’t around why the deadline matters. Figure out what this is and share it with your team.
This might be an uncomfortable conversation; it might mean revealing that your funding is running out or that your leadership made ill-advised promises to the board or your clients (you will only get to use this excuse a handful of times before people start walking), but that’s what you owe your team in exchange for asking them to run faster. Otherwise, know and accept that many times, the deadlines you’re setting are just made up.
How deadlines can benefit your team
Now that we’ve established deadlines are largely imaginary, we can agree it’s not wise to use them as a whipping stick to motivate your team to perform. But that doesn’t mean deadlines are useless altogether. In fact, there are two key ways in which deadlines can benefit your team:
1. Place helpful constraints on creativity
Deadlines are also known as the good ol’ timebox. Timeboxes are useful because software development is a creative endeavor, and creativity benefits greatly from constraints. Some of our most revered creators and artists benefited from imposed constraints – everything from strict schedules to exercising restraint to, yes, self-imposed deadlines. Particularly in the stages of innovation and seeking out product market fit, deadlines can be very effective in preventing us from overthinking or overbuilding. Given that learning generally happens in production when real customers get their hands on what you’ve built, in those initial phases, you want to get the product out the door as quickly as possible to facilitate that learning.
During my time running infrastructure teams, I found timeboxes to be extremely useful. Infrastructure development has this interesting quality of having longer timelines than product work and generally a larger quantum of work necessary in order to prove out viability. Additionally, some of the truly great infrastructure projects are those that deliver new capabilities beyond their initial intended purpose. These factors make for a particularly difficult cost-benefit benefit analysis. As such, I have found that there are an abundance of infrastructure teams trying to convince their leaders to greenlight a two-year rewrite of their entire platform – a proposal that’s almost always impractical unless you are sitting on a mountain of cash and can underwrite burning two years of development effort without concern.
To overcome these dynamics, I had a general rule that teams looking to undertake fundamental rewrites had to work in six-week increments, and at the end of each six-week period, they needed to demonstrate something that worked. It didn’t have to be fully functional, but it did have to convey some confidence that it was the proper solution to pursue.
2. A mechanism for managing ‘giving’
The second category comes from the book Give and Take by Adam Grant. Grant posits that there are three types of people in the world. The first are givers – people who do things for other people without thinking about how they would benefit themselves. The next group is takers – folks who do things only for themselves without thinking of others. And, the third group are matchers – folks who have a very balanced sense of giving and taking; if they give they take, if they take they give.
Not to give away any spoilers, but the book talks about how givers are overrepresented in the bottom quartile of performers at companies. The research showed that these givers often overcommitted themselves to work, both their own as well as helping out others. This often led to missed deliverables and burnout. However, the research also showed that givers were overrepresented in the top quartile of performers. The question was: What separates the top givers from the bottom givers? Part of the answer was that the givers at the top found ways to manage their giving. And this is where deadlines become a useful tool.
I think most of us want to work with givers. Especially in the current climate of the Great Resignation, we’re seeing that companies that are values-driven aren’t experiencing as many departures, and those organizations are usually filled with givers. So, if you work at a company filled with givers, employing mechanisms to help your employees manage their giving is crucial in avoiding underperformance and deadlines are one tool you can use to help folks do just that.
Conclusion
Navigating deadlines is a challenge for every engineering manager. For software development teams, missing deadlines is more a case of when than if. But while you have probably missed deadlines as an engineer, as a manager it hits a little differently. It’s now your job to bridge the differences between your team and company leadership. In the never-ending struggle between team pro-deadline and team anti-deadline, it can be hard to acknowledge that the answer is probably somewhere in between. By using deadlines with true urgency and understanding that they can be a helpful, positive tool to enable creativity and manage giving, you can help steer your team towards successful software delivery.
