A Common Pattern in Successful Companies

I’ve been helping software teams accelerate and succeed with DevOps and Amazon Web Services for a few months now (See Phoenix DevOps), and one of the more rewarding parts of the job is getting to observe how multiple different companies operate.

I’ve seen high-performing teams in companies that are about to IPO, software teams in Fortune 100 companies, startups of about 10 engineers, and software-based companies of no engineers at all! It’s been incredibly enlightening for me to learn about how people organize themselves to get sh*t done.

One of the other cool things about my line of work is that it’s right when companies are about to scale to the next level that they call me. So, for the most part, the companies I interact with, are successful startups on the verge of fast growth.

Now here’s the interesting pattern I see. I have yet to work with a single software team that doesn’t suffer some level of “embarrassment” about the state of their codebase, the “amateur” methods they used to get the job done, the duct tape they used here, or the total-makeshift-not-scalable solution they used there. It’s a really…unexpected combination: a business whose growth rate and product-market fit looks awesome, and whose product is filled with shortcomings.

I’ve also been involved — as a team member, not a consultant — on teams where the opposite approach was taken. Where software quality and thoughtfulness was trumpeted as the #1 priority, even above moving fast. On that team, that software wasn’t perfect either, but the standard of quality that we held ourselves to sure was admirable.

But having seen both approaches, as much as the engineer in me wants to only do great things, the entrepreneur in me realizes that speed beats perfect programming every time.

Speed gives you fast feedback from real users. Speed prevents you from getting bogged down in a technical quagmire that may not matter that much. Speed means you can start adding value to someone faster. Perfection just means that you’ve built a great implementation of what is probably not exactly what someone wants.

Although this blog post was inspired from my in-the-field observations, I am pretty much just restating the Lean Startup mantra.

Lean Startup says that, no matter how brilliant your new idea, you need to validate it in the real world with real customers as fast as possible, and that “validation” hardly requires a finished product. Get out of the building and get feedback so that you know you’re building something people want.

But it’s one thing to read about, and think about those ideas, and quite another to see the a team of engineers put themselves down over the shortcomings of their product and completely disregard the speed, when the ugly-looking speed is the very hallmark of a fast-growing successful startup!

Someday, I hope to work on the next great project/product that will change the world, and when I do, I’ll take comfort in knowing that we’ll be focused on getting it done, moving fast, and making it “good”. If it doesn’t looks perfect and I’m a little embarrassed about it, I’ll know I’m on the right track.