Why We Don't Do Daily Stand-Ups at Supercede

The engineers at Supercede don’t do daily stand-ups, and we have no intention to start. There are a few reasons for this, some practical and some philosophical, but in the latter case by no means divorced from the reality of how it feels to work effectively with smart people every day.

Supercede has been a distributed team from day zero. We’ve had people working not only from all across the European continent, but also from Canada, the Caribbean, Vietnam, China, Thailand, and Siberia. It has been of tremendous business value for us to not limit our talent pool to people local to our registered office address in the UK. Not only do we get access to an infinitely wider array of brilliant people, but also it makes Supercede a more attractive place to work for those people.

Our engineers don’t have to displace their lives to go and live in London or Silicon Valley. They don’t need to face those soul-crushing daily commutes. They can sit at home, or in the garden, or wherever makes them happiest, and get the uninterrupted focus time they need to do the real work that underpins our business.

This is critical.

We are a technology company after all, and it would be utterly moronic for a business leader to not prioritise the productivity and workplace satisfaction of exactly the people who do all the real work.

Given that our team are distributed across several time zones, it is logistically infeasible to hold a daily synchronous meeting. Which timezone should it occur in? Which employees deserve to sacrifice the regularity of their Circadian rhythm to appease the whim of a manager who can’t be bothered to read the status of work-in-progress on the team’s Kanban board?

If you run a software startup, you probably like to think you hire the best people. The smartest people. The rock stars. The A-players. Effective software engineers are in high market demand, and it’s rather paradoxical to view a software engineer as both smart enough to solve the hard problems in your business domain and make you rich, and simultaneously stupid enough to settle for a toxic work environment when greener pastures are aplenty.

Proponents of daily stand-ups — at least those that are real engineers — argue that these synchronous meetings can indeed be a valuable ceremony for the sake of alignment. The engineers need to be co-located and ours aren’t, but we can set that fact aside to entertain this argument. If you read the literature, it is argued that for this to work it is absolutely forbidden for project managers to join these meetings. This is, however, a utopian view. The status of in-progress work is the remit of project/product managers. Why else would those people exist?

It is the managers who insist on holding this ceremony, and so it naturally follows that the managers will expect to be able to attend these status meetings. Inevitably (and in my experience rather quickly), the ceremony becomes a monotony of disengaged developers who trot out the same canned lines.

Yesterday I worked on the widget.

Today I will work on the widget.

I have no blockers.

Are you asleep yet? The developers are. You promise them an intellectually stimulating work environment and what they end up with is drudgery.

What value can be had from these meetings anyway? Using “alignment” for justification is so nebulous that it is essentially meaningless. Engineers align themselves. They talk. Especially if you hire good ones (which, you know, you’ll struggle to if you have a culture of coercing them into this kind of busywork). Where does the real discussion happen? It’s written down. Go and read the discussion in the pull requests. Read the commit messages. Read the email threads. Read the chat. If your engineers are working on anything non-trivial (which they would be if your business is worth anything), then the technical discussion needs to be written down so that it can be cross-referenced and reassessed, now and in the future, by both current and future colleagues.

The other nebulous buzzword typically wielded by people pushing this on an engineering team is “scale”.

We’ll need to have a real process like this as we scale the team!

Bullshit.

There are countless large software projects all throughout the past several decades involving hundreds or even thousands of collaborators who not only have no shared trust or cultural background, but are from opposite ends of the planet and have never met.

Any guesses as to how they continue to be effective in such a chaotic organisational structure? Ding ding ding! They write everything down!

The final line of our traditional wonky Haiku deserves special attention.

I have no blockers.

Really? There needs to be time set aside in the day for an engineer to announce that something is blocking their work? What were they doing for the rest of the day prior to the status meeting? Twiddling their thumbs? Office chair jousting tournament? When effective engineers get stuck, they ask for assistance immediately. Not tomorrow because PHB solicited that feedback. Immediately. Now.

And somehow daily stand-ups are meant to make a software development team more “agile”?!

Hilarious.

If daily stand-ups really are so awful, why do some managers insist on them? Hard truth: it’s because they’re lazy, incompetent managers. It might be the way it’s done at several companies, but that certainly doesn’t make it a good thing. It’s an opportunity for managers to micromanage. We all know that micromanagement is bad, and yet we all know that bad managers continue to do it.

Daily stand-ups are not only a waste of time and make software development more expensive, but they demoralise developers and make them want to change jobs. And you know what? They will. Ask any tech company founder what their biggest challenges are. I guarantee that “hiring” is going to appear at or near the top of that list. You know why it’s hard? It’s because of bad culture like this.

Daily stand-ups?

Thanks, but no.