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

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…

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
• 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.

Making this work in practice - people and principles

At PostHog, instead of telling people what to build or ship, we give principles for how to think about this. These go into our handbook.

For example, we have this guidance for our engineers:

Good product engineers:

• Ship quickly so they have a fast feedback loop
• Understand the company strategy, and prioritize based on this and what they believe users want
• Can easily propose ideas for what to build
• Make sure the things they've built are being used
• Follow up after they've built something to improve it if needed
• Are good at descoping things and getting products or features into people's hands quickly
• Have users that they're friendly with
• Manage to build things without lots of internal meetings

Bad product engineers:

• Consider research something that takes two weeks rather than two hours
• Can't explain our company strategy
• Can't explain who their product is built for
• Don't know their product's competitors
• Only work on things they've been told to work on
• Don't know the names of any of their users
• Never challenge why they're being told to work on something
• Don't talk to users about what they're going to build, or what they've built
• Don't track if the things they've built are being used
• Spend 6 months on a huge feature before a user can try it
• Never remove features or complexity, often by shipping features that aren't used and leaving them
• Focus on internal alignment over company strategy and what users need

But, 'lo, how do you know the team are doing this? What process do we implement? You do not! The moment you start implementing a process for the above, you've added the meetings you were avoiding (so you could ship faster, remember).

We have a value "Trust and feedback over process". Culturally, we want our team to push each other on the above. Frequently you'll hear our engineers asking each other "what's stopping us from putting this into a user's hands?", amongst other things, such as the latest in mechanical keyboards or what the M(n) chip is like and how to convince us to upgrade them to it, I imagine.

Getting the people side to this right is key. We expect a wider skillset from our engineers than just writing code - and so we hire people that have wider skills. Lots of ex founders, or ex CTOs that just want to build stuff, for example, or people with more experience. We don't like hiring people that have just worked at huge companies (this and startup experience is fine though).

As I tell people during interviews, being an engineer at PostHog is like driving a car. If you like driving, and being actively engaged in what you're doing, feeling the feedback from users as you go like the corners in a road, it's fun. But you can't take a nap - you must stay switched on as no one will spoon feed you product requirements.

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.