The Best Way to Move Fast as a Small Team

It’s not that deep.

Mika Yeap
Mika Yeap
May 17 · 4 min read

An engineer working in a startup walks into a bar. The bartender doesn’t respond. Because the engineer never walked in at all. He was busy debugging a race condition that cropped up on production. While redesigning the landing page. And setting up a Redis cluster in some EC2 VMs.

Developing on a small team can get tricky. Always too much to do, in too little time, with too little manpower. I’ve grappled with this problem for a while, having never worked on a team larger than 10. Ever. And after many late night crunches and Sunday morning extensions, I managed to land on a half-solution. It’s both better and worse than you think.

First, an aside on culture. One of the things I enjoy the most about tech is the sub-cultures. You think politics is divided? Get into tech. There’s the REST gang vs the GraphQL bunch. Microservices vs monolith. Unix vs Windows. It goes on and on. There’s a schism for everyone. Since tech allowed us to do everything, we did exactly that. Which is both a blessing and a curse.

On one hand, you’ve got super niche languages like Go roaming in the wild. This is curious: Go was invented for the sole purpose of making large, high-performance programs running on multi-core machines. Things that would’ve had to be written in C+ or Java. And these days, few people have that problem. How many of us are working on codebases with millions of lines? Not many. And yet here I am leading a tiny team building microservices entirely in Go. The kicker: We don’t even anticipate much traffic. After all, how many people are going to use a trading bot platform? And yet here we are using a language designed for scale, when we have even less scale than React has elegance. Tech is so fragmented that we’ve got these little pockets we can make our own. There’s a niche for everyone.

But on the other hand, there’s plenty of noise to sift through. I mean, you’re hearing nice things about Go from me. But it doesn’t take long to find someone who’s not a fan. And you can do that with any language, framework, or ecosystem. So many people have an opinion on so many things that it can be hard to figure out the right thing. Which leads us to the technique my team and I used to build quickly. My half-solution: Ignore what everyone else says.

The idea is to treat all external tech opinions with skepticism by default. First, distrust. Then, verify. Then, consider. Doesn’t matter if it’s something old like REST or something new like React version 58.4.1. Skepticism forces you to reevaluate all “best practices”. Dig down and learn how and if they’re actually useful. How does that help with saving time? Because we engineers are all too happy to mess around with some weird library or package we don’t really need. And avoiding these tangents would save more time than you realize.

That’s what led my team to make a major service with mostly vanilla JavaScript, recently. And it was a charting service, too. So the logic was tricky. Admittedly, we missed the Svelte bindings and directives we were used. But when we pulled through, it was obvious that we saved a bunch of time sticking to a bare bones setup. Everything was simpler without Svelte getting in our charting library’s way. We could’ve added five more integrations that we didn’t. All in all, a good aversion maneuver. But it doesn’t just work for the simple choice of tools. It’s also the processes.

For instance, TDD. My arch-nemesis. A critical part of writing robust software is writing tests. The problem is, says who? That’s right: We scorned one of the oldest tricks in the book. Skepticism, people. Doesn’t help that we haven’t had much luck with testing as a team. It has always caused more bugs than it fixed. So we thought, “What if we just abandon testing this time? What would happen?”

The answer is, we’d move faster and still have roughly the same number of bugs. How do I know? Because that’s exactly what happened. Not sure how sustainable our solution is. But it’s nice while it lasts. Still, we always need to be on our toes. I guess that’s the price of abandoning the well-lit path. You’ve constantly got to watch where you’re going.

CodeX

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store