Good, fast, cheap, pick three

I’ve started a new job! It’s kind of hush-hush at the moment. We’ll be in stealth mode for a few months while we build this thing out, and then we’ll see what happens with the business side of things – nobody ever knows, right? But we’re absolutely going to ship a solid, well-built piece of software. I can state that with authority because it’s already like 70% done and the development team consists of me, myself, and an occasional hired muscle person from Varvet.

After a few decades of fumbling my way through this so-called industry I’m converging on the perfect team size, and it hovers somewhere around five people. The least you can get away with for a product company is three: a salesperson, a designer, and a developer. For speed, add another developer and a salesperson. This is plenty, as long as you keep your knives sharp and your ammo dry. Let development be driven by a rousing and stentorian README, let your day-to-day be driven by GitHub issues and PRs, let your high-level project planning be a shared Googledoc that gets updated when it needs to be.

All those tools. All those toys. They’re bringing you down.

For your development environment, boring is the name of the game. Stick to the tried and tested and don’t buy lottery tickets – cutting-edge technology is called that because it will cut you. You have a finite pool of creativity and problem solving every day and that should go in your app, not your framework.

You should also steer clear of the siren song of “project management.” The books are written by desperate people who want to leave their career for a life on the speaking circuit. There’s no silver bullet to be found in OKRs, scrum masters, or stakeholder meetings. You’re a minimalist now. Let yourself be in charge. You already know what to build. So pour yourself a big cup of coffee, adjust your chair, make lightning flow from your fingertips, and get something out there in the world. Then refine it if needed. And, most importantly, don’t look at what big companies do.

There’s a reason C# exists

Seriously. DO NOT LOOK TO BIG COMPANIES FOR INSPIRATION. They’re an enormous antipattern. For them, the game is defined as “turning the output of subpar programmers into working features” and subpar is not a slight, honest to god – there’s a median, and roughly 50% of programmers are going to fall below it. Now, if you have a very big bag of VC cash and a hockey stick graph to chase, this might be the safer bet! You’re throwing a big pile of bodies at the problem to get there quickly and if that means recruiting a bunch of Product Owners and People Managers just to try and keep things together, then so be it. Let’s call it BCDD, Bean-Counter Driven Development: it’s just numbers, right? Mythical Man Month asymptotes be damned. To succeed at BCDD, you’ll need lots and lots of red tape. Release cycles, requirements capture, team boundaries, performance reviews, angry compilers, everything that sucks about software. Then that awful bezoar will be taken to “developer advocates” and turned into fawning blog posts about how swimmingly it works. Don’t be fooled.

Try to be yourself

Look, some people absolutely thrive in big companies, immersed in SaaS tools, procedures, and hierarchies. There are upsides. You’ll never have an in-office barista in a five-man team. Equity in big companies is fantastic, compared to the big fat zero you should expect in a small startup. But life is always going to be about tradeoffs. And with the mature frameworks available today, a small team of experienced generalists can run circles around a hundred-strong company. I intend to prove that.