You say “slow”

Photo by Nick Abrams on Unsplash

Every. Single. One.

You end up developing a hard skin on the subject. It is not easy, though. It requires time and strong convictions.

The truth is, “slow” is a big word.

It is also a facade.

You say slow

But this is all I hear:

“We’re fighting against unrealistic expectations ( and you told your boss about them, so now we’re both fucked)”.

“We’re measuring outputs over outcomes “.

“We’re doing too much at once”.

“We’re trying to please everyone at once”.

“We’re overloaded with reworks”.

“We’re waiting for handoffs”.

“We’re switching context too often”.

“We have a poor infrastructure to develop, test, and deploy”.

“We need to fight against knowledge silos”.

“We don’t know what we’re doing “.

“We don’t know better”.

Take a break

and read the list above again. Do it slowly (heh).

How many of these situations apply to your team? Some of them? All of them? That’s possible — been there, done that. I encourage you (and your team) to come up with your list.

You must understand that each of these sentences looks like slowness from the outside.

Notice that each item hides other underlying issues and limitations. You won’t find a root cause, because a team is a system, and it behaves like one. Sadly enough, this means that there are several actors it comes to “speed”. It is not about a single metric or KPI.

Your team has to call these blockers by its name and fight the “slow” label — one issue at a time. Then, rinse and repeat.

I stopped trying to go faster

The bright side of the story is that you become immune to the slowness complain — eventually.

So I stopped trying to go faster. Now I try to go less slow instead.

To do so, I went back to basics and tried to think in terms of Cost of Change. The time required to fix errors increases exponentially the later they are detected in the development lifecycle.

If you missed something while sketching the requirements of a feature, that’s cheap to fix.

If you missed something while developing a feature, that’s still cheap.

But, if you fuck up something in production, cost skyrockets. Opportunity cost + rollbacks + database migrations… a nightmare.

This is why shorter feedback loops shine: they help you flatten the cost of change by finding errors as soon as possible.

Too Long; Didn’t Read

Slowness is a perception. Sometimes it is an excuse, too.

Try to uncover what hides behind that label. It’s usually a sum of factors.

You can’t go faster, but you can focus on going less slow.

Originally published at on July 24, 2020.

NOTE: This post was first published in my newsletter. Subscribe to receive my posts a week earlier, right to your inbox 🚀




Words matter – Software product development, Front-end, UX, design, lean, agile and everything in between.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Redis Zero Downtime Cluster Migration

The “Guts” of Swift: Toolchains, Internals, and Intermediate Representations

Excellent Challenge — H@cktivity Con CTF 2021

Spring Cloud Gateway Pre and Post Global Filter || Global Request And Response Filter

Hacking your Next Hackathon !!!

SoSimple 1 CTF — Vulnhub walkthrough

Autoscaling in AWS with Memory metrics.

Project OWL announces new release of ClusterDuck Protocol

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Adrià Fontcuberta

Adrià Fontcuberta

Words matter – Software product development, Front-end, UX, design, lean, agile and everything in between.

More from Medium

Agile Software Development: Back to Basics — Part 1

An opinionated guide to agile

Using Scrum for “Agile” Software Development

Agile Methodology used in Software Engineering