Jack Beaton

Stop Shipping Broken Stuff

You're not a startup anymore.

I was recently asked this question by someone in customer support for a major tech company:

"So [company] has a habit of releasing things that are kind of broken with plans to fix them later. I know you've said this is sort of an expected thing with startups and experimental projects where you just want to get something out as quickly as possible. But [company] is a bit past the startup phase, I feel like we should be taking the time to do things right the first time to give the customers a better experience. What do you think?"

One of the problems you see in the tech field is low standards in software because "we're a startup" by companies that sure don't look like startups.

I once worked with a company that wanted our help with its bug reporting, because they had too many bugs and too much downtime. They were over 10 years old and had hundreds of engineers across a vast office space, and the founding CEO was long gone. Nonetheless, they took great pride in calling themselves a startup, and cited that when making decisions. There was a guy who watched YouTube all day in line of sight of the CEO, who the CEO let do that because "we can't lose that startup culture."

I've always wondered if the original founder would've put up with that excuse, but who knows what he wanted? He was never spoken of.

But more importantly, they had too many bugs, because you'll have worse code quality than a startup if you keep calling yourself one for too long. After a point, it's just an excuse not to adopt mature processes.

What's the point where you're no longer a startup?

There's a lot of benchmarks you could use. Here's a few of mine:

• you have a separate customer service dept
• you have a separate QA dept
• you don't know all your customers personally anymore

But what do all these have in common?

It's that your engineers can now externalize their failures to someone else at the same company. If there's any temptation to be sloppy, they'll do it and ship a bad product. Deep inside their heart, they will always know they can blame a missed bug on QA, and the angry customer will be talking with someone else than them. And there's no such thing as an open temptation that isn't eventually acted on.

Everyone has the temptation to be sloppy, but at startups it's automatically countered because you can't externalize your failures when it's just you. Startup engineers know they'll be fixing their own bugs and placating the angry customer themselves - and it may be seen as a personal betrayal. That fear keeps them up at night, when big company engineers can sleep soundly.

A startup counters temptation to be sloppy with heightened personal responsibility. A big company has to rely on process.

Should you ever be shipping buggy software because "you're a startup"?

Sometimes!

If you're so close to your customers that you know their priorities, this may make sense. You may know your customers will accept the tradeoff of a high-priority use case working while a low-priority use case picks up a flaw. If your customers will consider that a net gain, it makes sense to give them earlier value and ship fast.

If you're close enough to your customers to know their priorities and give them a heartfelt explanation, they may accept a "Two steps forward, one step back" argument from you.

But that won't last forever. Eventually even a net gain will be questioned because a) you don't know all your customers well enough to know your choices still match their priorities, and b) they don't personally know YOU well enough to trust your explanation. They won't think you made a tradeoff for their sake, they'll just think you're bad.

There will come a point where "we're a startup, we can be sloppy" becomes just an excuse for sloppy work.

Don't cling to the "startup" label to justify sloppy work: adopt process instead

Process is a downer. But bureaucracy needs to be a downer because it blocks temptation - the temptation to ship sloppy work. Bureaucracy's cumbersome nature is a feature, not a bug. The tradeoff of agility-for-stability becomes worthwhile as companies grow.

A real startup doesn't want to ship sloppy work, but will when it's best. They don't need cumbersome big-company bureaucracy to stay on the ball, so they can push the envelope sometimes. But as they grow, that won't last.

The reason a big company needs big processes is to counter the temptation to coast that comes from knowing you can externalize your personal mistakes on someone else under the same corporate umbrella. A guy at a mature company saying "we don't need process, we can be sloppy, we're a startup" is as painful to watch as a mature person trying to be a hip teen. It just won't work like it once did.

Once you're large enough for anyone on the team to externalize a problem on someone else, you're not a startup anymore - at least not in that department. You'll have worse code quality than a startup if you keep calling yourself one for too long. Mature gracefully, implement process, and get disciplined.

Jack