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.
Idea: If you do notice a teammate working unusually long days, consider reaching out to them. If you can take something off their plate, do it. If not, encourage them to speak with the team lead about it. Personally, some of the best things managers have done for me is to extend a deadline or lighten my workload.
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.
Idea: Build a culture where innovation weeks and the work that comes out of them are celebrated. Once their value is ingrained in the minds of managers and product owners, everyone will remember to account for innovation weeks in plans, estimates, and goals.
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.
Idea: Bake time for technical debt into all your plans, too. Even if it’s only a little bit each sprint, that adds up to a much healthier product over the course of months or years.
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.
Idea: Invest time in one or both of the following techniques: 1) explore projects and features thoroughly enough upfront that you have a highly-informed idea of what scope you can deliver and a reasonable date range; 2) agree on the trade-offs you’re willing to make (e.g., scalability over usability) at the start of the project so people can make decisions independently in the service of preserving scope.
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).
Idea: I could be vastly oversimplifying, but I feel we should weave some flexibility into our external messaging around what will be delivered and when in order to minimise everyone’s pain.
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.
Idea: I think the real goal here is for people to gain an appreciation of their colleagues’ craft. Within a team, pair programming is an effective way to do this. Across teams, shadowing and “lunch n’ learn” events can highlight where the two teams’ work intersects and the ways they help each other.
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.
Idea: Investing the time to get back to basics actually helps teams move faster and deliver more. I can’t speak for all teams of course, but for our team, retrospectives and standups are key.
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.
Idea: Make the most of little moments for socialising no matter where you are in the release cadence, even if it’s just a quick coffee. Waiting until after the ship date – especially when working with new people – is like cleaning up a fallen mug when you could have just moved it in from the edge of the table.
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.
Idea: Create a 90-day plan for new hires that guides them through all the ramping-up, but also builds in productive time, e.g., “Choose a bug from the backlog to fix in your first week, and ask plenty of questions along the way.”
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.
Idea: Spend a significant portion of your 1-on-1s developing empathy. Talk about what’s going on for each of you outside of work (to the extent you feel comfortable sharing). Express gratitude for ways you’ve helped each other. Ask what the other person needs to be more successful in their work right now. Even just venting about whatever is frustrating you can have a calming effect.
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.