afontcu.dev

You say slow

3 min read

I've been told I was going slow in every project I ever participated in.

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