When everything is urgent, it’s hard to get anything important done. Here’s what you can do about it.
It’s fashionable in the tech world to say that you’re cool with failing. But failure leaves a bad taste in your mouth. The only way to get it out is to prove you’ve learned from your mistake.
In that spirit, I recently kicked off a discussion amongst the engineering teams at Atlassian about setting deadlines for the sake of deadlines and, worse, prioritizing that deadline above customer value or the overall health of your product (and team, for that matter). Now, I’m no saint in this regard. In fact, I’m guilty on multiple counts. And although there’s no sense pointing fingers, let’s just say it’s clear this problem is not exclusive to my team or to teams at Atlassian.
It’s awkward to talk about because admitting you’re obsessing about deadlines is uncomfortably close to admitting you’re ignoring agile practices. But if we don’t face it head-on, we as a community of software makers will keep making this mistake. Let’s stop that from happening by sharing what we’ve learned and taking those lessons onboard.
Wait: what’s so bad about deadlines?
Whenever you commit to building something, the natural next question is “when will it be done?” And when you answer that question with a specific date – in other words, when you set a deadline – you put everyone’s reputation on the line. Managers, product owners, and developers all want to show how great they are by delivering what was promised on time and on budget.
The problem is that, chances are, you’ve just set a delivery date for a nascent project you haven’t even fully explored yet. You don’t have a reasonable basis for estimating how hard it’s going to be. Also, most projects also don’t exist in a vacuum. Projects that appear unrelated on the surface will have dependencies and conflicts at the lowest levels. And when they eventually come to light, the deadline is almost never adjusted accordingly.
At that point, all anybody cares about is getting something out the door so they don’t lose face. The polished, thoughtful feature that should have shipped doesn’t matter. Work-life balance is a fond memory. Now it’s all about not looking bad in the boss’s eyes.
What you’re left with is an environment where it’s nearly impossible to do the right thing, which hurts your team and your customers.
To be fair, urgency isn’t necessarily a bad thing. It just can’t be the mode you operate in all the time. Sometimes you’ll work full-out because shipping the project as soon as possible really, truly matters. But then you need to catch your breath – whether by taking time off, tinkering with an idea you’ve been noodling on, or shoring up a weak spot in your product. Balance matters.
Keep in mind that the following 10 signs of deadline-driven development are just that: signs. No single one is a landmine. When you find your team exhibits many of them, however, something is probably wrong.
1. You have to tell your teammate to stop working outside their usual work hours
Catching a teammate checking in code or commenting on a pull request after hours (or very early in the morning) isn’t much to worry about it if happens once or twice. But if it’s happening regularly and it’s not a situation where the whole team has agreed to put in extra time, then that person is probably stressing out and over-working. And we just don’t do our best work when we’re in that state.
2. Innovation weeks are delayed or canceled
Remember what I mentioned above about catching your breath after a big push, such as a major release? Innovation weeks are one way to do that at a team level. Developers get an opportunity to prototype new feature ideas or to test-drive a new open-source library, while product owners get a chance to recalibrate the backlog and flesh out requirements, and designers can sketch out concepts for the next round of work. Not every innovation week produces work that eventually makes its way into production, but a fair number of them do. (Fun fact: Jira Service Desk was born of an innovation week project. Now it’s a full-blown product.)
I realise I’m speaking from the privileged position of working at a place where innovation weeks are even a thing. So, with that said …
If innovation weeks are part of your engineering culture, they should be non-negotiable. Every time innovation week suffers, so does team morale. This is compounded when you have inter-team innovation weeks, which always generate the most exciting projects. If one team delays theirs or cuts theirs short, things no longer line up and the whole thing goes pear-shaped.
3. People suggest using innovation weeks to pay down technical debt
Building things properly and completing tasks related to engineering health should be reflected in your estimates and roadmaps from the start. Innovation weeks are about innovating. Not every idea will be successful, and that’s ok. It’s about the craft and teams learning new ways of doing things.
When innovation weeks get used for engineering health, it stifles innovation. And, you’ll start hearing things like “We just spent a week fixing bugs. Why are we fixing this one now? Can’t we wait until the next innovation health week?” Ignoring the inherent technical debt from past releases leads to outages and other incidents, crawlingly slow speed, and general engineering friction for the whole team.
4. Scope becomes non-negotiable; or, there’s no marketable scope left
You can just keep cutting scope to hit a deadline right? Yeah, no. Eventually releases become half-baked features that aren’t marketable. There are a lot of nuances to be considered here, but you can’t always stick with the originally intended ship date and the originally intended scope. So maybe you keep the ship date and release a smaller amount of customer value. Or, maybe you push the time a little bit to accommodate a larger scope. Either way, the sky probably isn’t going to fall.
What’s truly dangerous, though, is making scope non-negotiable. It destroys the idea that the team owns their work – do you really own a project if you’re not allowed to adjust the scope? In environments where “you build it, you run it” is the mantra, the last thing you want to do is erode the team’s sense of ownership.
5. The deadline is in the service of making a splashy announcement
I know marketing and PR teams feel a lot of pain when something has to be rescheduled and you miss the opportunity to announce something at a conference or other juicy point in time. Similarly, development teams feel pain when the schedule remains fixed. Customers feel pain either way – whether the software arrives late, or is on-time but of poor quality (in which case, they’ll have to wait for what they really want anyway).
6. People are unusually stressed and aren’t pleasant with each other
It’s no secret this slows things down. In a deadline-driven environment, people will over-extend themselves and dabble in areas outside their expertise in an effort to get ahead of the game instead of spending quality time making a contribution that plays to their strengths.
7. Normal practices are forgotten and responsibilities are neglected
Deadlines tend to steal focus away from your established team rituals and collaboration practices because nothing else feels as urgent. Sprint retrospective? No time! Team lunch? Not important! Fix the build? Later – I’m busy! This is compounded by sign #6: When people are over-extending themselves trying to get ahead of everything, they aren’t focusing on the important day-to-day things anymore.
8. There’s “no time” to socialise and build bonds together
This further compounds sign #6. It’s harder to empathise with people you don’t know since you need to be able to understand and feel their pain, which is near impossible when you maybe only know their name. Part of being pleasant to one another is enabling and supporting each other. When people are under time pressure, they tend to focus solely on their own work, then blame others when things go wrong.
9. New hires are focused on output and not learning
The first weeks should be a time for people to learn, get their bearings, and be welcomed. They shouldn’t have to feel the pressure producing at full speed within the first week (although this timeline is a bit different for interns). Conversations should be more focused on making sure they have the information and resources they need to be productive – not hounding them about when they’ll be ramped up.
10. Manager 1-on-1s become about the project and hitting deadlines
These meetings should be about growth, enablement, feedback, and all the big dreams. When these conversations change, everyone’s trajectory (including the manager’s) and the speed of the project slows down. When 1-on-1s start to resemble sprint planning – or retrospectives, or stand-ups, for that matter – there are probably larger issues at hand than why such-and-such user story isn’t done.
High-level ideas to fix things
The ultimate question we need to answer is this: Are we doing things based on urgency or importance? It’s alright to prioritize a few urgent things, but if everything is urgent then it’s unlikely that anything important is getting done. Not that we should let ourselves become complacent. Customers want features and fixes delivered yesterday, and competitors are nipping at your heals (or worse, eating your lunch). Here are two broad-brush ideas for achieving a better balance:
- Smaller releases. Most (if not all) product teams at Atlassian have moved to tighter release schedules where the scope of each release is relatively small. For one thing, it’s easier to estimate the scope of what you can deliver in two weeks vs. in two months. Also, customers can feel the momentum. So when we say a feature will be ready “soon”, they’re willing to put more faith in that. Plus we’re able to get feedback faster, which means better-informed engineering decisions and less risk that we’re building the wrong thing.
- Relaxed external messaging around features and dates. This is all about winning the game of expectations. It’s better to be a little vague about ship dates than to promise a date, then have to publicly revise it again and again. It’s also easier for our colleagues in marketing when they don’t have to repeatedly reschedule or tone down publicity when projects run behind or under-deliver.
Planning, estimating, and managing better is something software engineering has been trying to crack for 60+ years so we shouldn’t place high hopes on solving deadline-driven development overnight. But we should still try to improve. And we should be careful not to lay all the blame on project leaders. We all own this.