The Fallacy of “Nimble”

It’s one of my favourite perks of being a small (one programmer, one manager/business guy) tech company: we’re “nimble”. What does nimble mean? Nimble means when you have that niggling annoyance, I can fix it in front of your eyes. Nimble means that when we figure out our product is wrong and we need to pivot, we don’t throw too much away. Nimble means that the time between a decision getting made and palpable effects of that decision being visible to users is minimal, sometimes non-existent.

Nimble is a waste of time.

That’s really over-simplifying it, though. Nimble can be useful. Nimble is great when your idea is unproven, you’re unsure of your market, and you’re rushing to get a minimum viable product out the door. Nimble is necessary and an advantage in those situations.

2cloud has been going strong for almost two years now. I validated its idea on accident and the market has proven itself over the last couple of years. It has been given great reviews by not one but two of the most respected publications in the industry.

And yet, we’re still nimble.

That’s not something to be proud of. That’s us doing it wrong. We’re not going to pivot. We know our product, we know our market. We’ve spoken to customers (excessively). We need to focus on execution now, not whether or not we’re on to something. Being nimble is hurting us now, in subtle ways.

Not having an automated deployment system.

Not having enough test coverage.

Not having enough processes and check-lists and double-checking and all those things that make nimble-advocates cry out in terror. Because those things exist for a reason.

Nimble is great when you need to figure out what you’re doing, fast, and with as little expense as possible. But nimble leads to duplicated effort, mistakes, and, ironically, wasted time when you know your niche and just need to fill it.

Time to be less nimble.