Why Startups Slow Down (and How I Can Help)

Every startup I’ve ever worked with wants to move fast. Founders want to respond to what they’re hearing from prospects. Sales wants to follow up on every opportunity with just the right feature. Engineers want to ship. The race is on, and no one on the team is satisfied with the pace—or else they wouldn’t be working with a startup.

In the early days, teams lament the lack of resources to get the work done. Then they grow the team, and counterintuitively things seem to move even more slowly. Founders long for the early days again.

What I’ve seen over and over again—both as an engineer and as an engineering leader—is that choices made in the name of speed have a cost. This cost is realized both in terms of long-term engineering velocity but also real American dollars.

What startups often lack due to their constraints is an ability to really understand the cost of their choices at the time they make them. Making a decision for short term gain at long term expense is part of the job. But understanding the opportunity cost of our decisions is crucial to prioritization. And for startups, deciding what to spend their limited resources on is paramount.

The beauty of marginal choices

I’ve been talking to my kids recently about the power of (and self-discipline required in) making marginal choices. See, I’m the kind of guy who doesn’t put his dish in the dishwasher right away. I prefer to let the sink fill up before loading it all at once.

Maybe I’m maturing, or maybe my life and responsibilities have changed, but this strategy no longer seems to be working for me. I dread that sink load of dishes (and my wife certainly hates it). I get completely stressed out trying to find things in a closet that needs to be organized. Then, I drop everything to organize it, even when there are much better things to do.

This sounds a lot like maintaining a software product. In the startup world, we often prefer making big, bold choices while neglecting smaller marginal choices that can be only made in the moment but will make us successful in the long run.

Continuous integration is a great example of how software teams have identified this problem and automated it away. It’s now a given that software will be built using version control, code will be reviewed by peers, and tests must pass before code ships. Using a combination of tooling and cultural buy-in, CI prevents needless confusion and code thrashing needed to solve self-induced problems, because it avoids them in the first place.

Now, what if we applied these same techniques to every level of the software building process? From receiving business requirements, to prioritization, to designing, to code review, to QA, to analytics and back again: all of these steps have opportunities to apply tooling and codify behaviors that will make the smart, meaningful, marginal choices easier to make.

But who’s got the time to find these gaps and build consensus around solutions when we’re so busy shipping?

What I Bring

This is where I come in.

I’ve seen some things. I’ve shipped code as an employee and consultant for 10+ startups at various stages. I’ve got a lot of code that’s still running in large scale applications, but I probably have even more that was shipped in support of ideas that missed the mark and thus no longer exists. It’s all part of startup life—but it’s really expensive.

As a sales person turned founder turned engineer turned engineering leader, I’ve also been responsible for all stages of the development process. I’m uniquely equipped to help teams see where they might be skipping valuable steps, and what the possible consequences of their choices could be (and whether it’s worth it).

I can sit with a software team and actually ship code alongside them, observing how they interact and support each other. With that insight I can help build a shared vision for velocity that teams will actually appreciate.

I can sit with business and product teams, analyze how they define, shape, and prioritize work for engineers, and show them how to optimize so that developers can actually ship fast.

I don’t come in with a prescribed set of tools or agile methodologies to get work done. The value I bring is helping you build consensus around habits that leverage the tools you already have in place.

It’s not glamorous work. It takes discipline. But it’s the stuff that helps teams stay fast—and that’s what matters.

If that sounds like something your team needs, let’s talk.