Dahlia Season Consulting

Originally published November 15, 2016 on cocktailmonkey.blog

You’re at an all-hands or in a staff meeting.  There’s a weird, tense feeling in the room. You know that nothing catastrophic has happened, else you’d be drinking whiskey straight out of the bottle with your newly minted ex-coworkers. But still, all is not entirely well.

And then, you hear it. The rallying cry of the slightly panicked executive or founder, “We must go faster!” Go! Faster! As if you’ve been taking a stroll in the park. As if you were a wind up monkey toy that could be wound up further to march faster. Clearly, if you work in a startup that is still burning venture capital, you already know you need to GO FAST!

And yet, you have succumbed to All The Things that creep in and slow you down. You have become immune to the dysfunction that drives you bonkers and distracts you from building the actual product. What are these things? What can we do to actually go faster?

After working at 10 startups, and sitting through numerous rallying cries to GO FASTER!, this are the things I’ve seen affect speed.

Humans are Expensive, so Optimize your System for Them!

• Make your build as fast as possible. (XP practices encourage the build to be under 10 minutes.)
• Get your automated test runs to be as fast as possible. And automate as much testing as you can. Focus on testing at the unit level all the time, and at higher levels selectively as necessary.
• Use your speedy infrastructure all the time. As in, check in early and often and get the feedback from your build and test pipeline right away. Hopefully you have a super obnoxious system that alerts you when something has broken so you can fix it fast.
• Don’t waste time building your own tools unless you absolutely have to.  Every time you build your own tool, you have to continue to maintain and update it. This cost is seldom calculated when you go down that road until it’s too late. Concentrate your development effort on building the product you actually sell.
• If off the shelf open source or commercial tools don’t quite do what you need, use a tool that allows you to create your own custom plug-ins, and limit your development effort to just the plug-ins. Make sure you can still upgrade the core of the tools you use.
• Choose a platform and stack that’s not obscure. The more mainstream these are, the more tools will be available for them, and the more developers will walk in the door knowing them. If you use an obscure platform or stack, every developer you hire has to spend time learning them. That lengthens the time between starting and being truly productive.
• Don’t cheap out on hardware or connectivity. If you want to go fast, make sure humans aren’t hamstrung by infrastructure that regularly fails, data they have to wait hours to download, or not being able to run tests and get fast feedback because there aren’t enough cores, hardware, whatever.

This is only the first category of several. Be sure to look at Part 2 of this post!