Deadlines: healthy motivator or sick game?

In my first software job out of school, green as hell, I had explained to me the essentials of running a good meeting.

“Every action item gets an owner,” said my manager. “One owner, and a due date. Never have multiple owners. And don’t leave without getting a commitment to a date.”

Sound enough. Although in the years since, I’ve sometimes wondered whether deadlines have become a little too all-encompassing—the main thing, maybe the only thing, people use to gauge how engineering is doing.

Being accountable to dates is part of being a professional. As we acknowledged while exploring the [uselessness of traditional estimating](https://socraticworks.com/methods/post/Stop-estimating.-Start-shipping.), there aren’t many “dateless” organizations.

But using deadlines as the main measure of engineering accomplishment is like adopting a health plan that cares only about weight loss. There are lots of tricks to shed pounds; few of them will leave you actually fitter.

Dead. Line.

On-time, on-budget, on-quality: pick two, runs the old joke. But in a world where software powers everything, we’re driven less by budgetary nickels and day-one defect counts, and more by responsiveness and speed.

Aren’t dates an important part of this? That depends.

Certainly timeboxing (sprints, etc.) helped change the way we manage to deadlines. Rather than looking to some far-off date for an as-yet undefined body of work, we set much shorter deadlines, focused on what we could credibly build in the time available, then rinsed-and-repeated until the entire body of work was done. We ate the elephant a bite at a time.

But all these sprints are often still connected to some bigger deadline: the “real” date published on a plan and shared with stakeholders. Timeboxing helps to attack risk—we’re building as early as possible, and learning as we go—but we’re still confronted with the idea of some impatient end user, checking their watch.

It’s also an open question as to whether planning in shorter timeframes helps us hit deadlines more reliably. Let’s look at some data.

Across all Socratic customers in 2021, a body of time representing hundreds of sprints, teams delivered an average of 40 percent of sprint plan. In other words, more than half of planned work was pushed to later sprints. Even within the short window of a sprint, hit-it-all-by-the-deadline isn’t the norm.

Deadlines can help to focus the mind, yes. They can also trigger some familiar gamesmanship— chucking scope overboard, revisiting what “done” means, etc. Are these productive, healthy actions? Do we emerge from the latest sweaty push, having burned weekends and whittled scope, feeling good? Does doing it again and again make us stronger?

(Re)defining what matters

Coming back to the fitness metaphor… Weight loss was once the measure of a health plan because we had little else. Longevity, metabolic conditioning—these were future aims, born of better data. Similarly, deadlines suggest a lack of any better way to understand what engineering is doing, and how it’s doing it.

From the engineering side, we bear responsibility for this. It’s our job to show that what we do, and how well we do it, isn’t reducible to a deadline.

Start with flow. Ideas come into the engineering team, and exit as working software. The aim of flow is to make this transition, from idea to shippable product, as smooth and frictionless as possible. Flow is measurable. You want to know—and as importantly, be able to show—how efficient your flow is, and how it’s changed over time.

Join flow with a good measure of workload balance. Set a limit for the amount of active work any one person should have at a time. Let people finish what they’ve started, before throwing more onto their plates. This is much easier to do if you can see changes to workload in real-time. Workloads rise and fall for all of us; the aim is to smooth it as much as possible. If you graph it over time for your team, it shouldn’t look like an EKG.

Flow and workload balance are about improving the health of the body. What about the results? If it’s not just deadlines, what’s our scale? In addition to the aforementioned flow efficiency, we like throughput and speed.

A team that works well, gets lots of ideas instantiated as software, at good speed? That team is Olympic-ready. You can kick the scale to the attic.