The no deadline boom loop

Urgency comes up a lot - Tim and I have talked about it an average of 5 times a year in our 1/1 notes. Often we’ve asked “should we increase urgency” and decided hell no, and this is about why.

Companies do a lot of things to increase urgency, but probably the most popular of all is artificial deadlines, which have a way of manifesting into meaningful deadlines.

This goes something like this:

• planning work - figuring out what to work on, task / t-shirt size estimation, sacrificing your first born to the ScrumAgileEtc Master
• set a deadline to “speed up” the engineers to build a feature
• sales team and / or product managers offer the deadline to customers
• interestingly, the sales team also work like this - it’s typical for salespeople to get paid a higher commission for deals sold “before the end of the quarter”, which incentivizes them to sell things earlier than they exist on silly terms (hello commercial debt - it’s like technical debt but for creating difficult customer situations!)

Seems an easy way to keep customers excited even when there are feature gaps today, right? Here’s the rest of the deadline doom loop:

• actually building the feature reveals it’s more complex than first thought, or the team get pulled onto incidents or other stuff (sales calls / exec whim things / stuff that has been missed from the plan, because plans die on contact with reality)
• the company realises it’s going to miss the deadline, and needs to rejig their promises with customers
• as a result, the company gets more specific still about progress and this generates more meetings and updates (with the engineers that need to be not in meetings to build it)
• engineers take shortcuts, creating technical debt
• they still miss, everyone is sad anyway
• and every time through this loop, the company gets slower and even less predictable due to the dangerous mountain of technical debt, and engineers that want to get stuff done get frustrated by all the meetings and slowness and quit for faster pastures elsewhere
• company eventually grinds to a halt and starts churning customers

Turns out those artificial deadlines were pretty meaningful after all. Sadly.

Deadline doom loop escape hatch

Why do you feel the need for deadlines in the first place? To build stuff faster. Or you’re a power mad psycho. To help with the latter, keep going!

If you want to build stuff faster, what are the first principles?

Engineers should mostly be writing code. They should be good engineers that can work quickly. You want to avoid building up technical debt if you want to be fast next year too (or if you want to sell the company next year, this doens’t matter, but you probabloy don’t).

But customers…

Customers seem frightening. You’ll run out of revenue or the ability to fundraise without them.

But here’s the one trick delivery managers don’t want to tell you…. You can tell customers that you don’t set deadlines because it means your team can ship more things. The customers that require set deadlines - in a long term focused world, you’d leave them to someone else.

Here’s what happens next:

• You work with customers that trust you
• Liberated from the shackles of meetings, you ship quickly, build an incredible product
• Hence more customers turn up
• You remain fast at scale since you gain a reputation as a great place for engineers to work and you don’t wind up with a ton of technical debt as a result of a strong, happily retained engineering team

There are things you can do to help customers accept this way of working - we use transparency to create trust. This looks like making our code open source or source available, so we can share with them the pull requests and issues so they can follow along. At the same time, so many new features are appearing in general that we show rather than tell them how they benefit from working with a company that runs like ours.

We haven’t yet lost a customer because we couldn’t promise dates but we aren’t 100% enterprise focused - maybe if we only cared about the biggest companies we should do this, but I’m doubtful. We do have a bunch of Fortune 500s as meaningful paid customers, but our core focus is getting in ahead of a complex stack of tools.

Some people should ignore this

If your customers just don’t get engineering at all and you can’t explain why this is better for you as a software company to provide more value to them, you probably can’t pull this off. I don’t think the juice from these contracts is worth the squeeze.