Punching Above your Weight
A few tips on getting big results with small engineering teams
Technology is a fast-paced field, especially in early-stage companies where every hour and day count. The runway decreases, while the expectation to deliver results increases.
The typical scenario looks like this: a small team trying to deliver multiple features just in time to hit a launch date for customers. A company trying to exceed expectations and deliver more than thought possible.
How to outpace your larger competitors with a small team?
Startups usually have a strong bias toward action. A small group of motivated people, little bureaucracy, and a clear direction. Doing things fast is much easier than in a big organization, and that’s a great start. However, it’s not everything.
With that in mind, here are a few lessons I’ve learned from working for several years in small teams with big plans. While these are ideas that can be applied to teams of any size, they become more essential the smaller they are.
(Very) Simple technology, (very) simple infrastructure
It probably comes without saying, but keeping technology simple is a very good thing when you can count your team with your two hands.
Don’t think about less infrastructure, think about no infrastructure. Don’t add new programming languages to your tech stack unless strictly necessary. Deprecate old technology as soon as you can. Stretch that monolith as far as you can go unless there are great benefits in doing it otherwise.
There are plenty of solutions out there that are based on reducing infrastructure costs to the minimum. Use them, and buy instead of building it unless it’s part of your strategic advantage.
Generalists >> Specialists
When you have a small team, having a specialist usually means having only one person that has a specific skill in your team. While that can be an advantage, it’s also a risk.
If you keep your tech stack simple, you can more easily find people that can work across it. More overlap will mean more productivity every time. While people will have different levels of comfort on different parts of it, embrace the idea of T-shaped engineers. It will make development much simpler.
Build less, build iteratively
While building things fast is a great skill, not building what is not necessary is even greater. Priorities change on a daily basis and what was urgent yesterday is not as urgent today.
When it comes to engineering, the biggest advantage your company can have is: less code. It means more flexibility and less complexity moving forward, and it automatically increases your quality. It’s common thinking to aim for quality with more automation, but not as much thought is given to achieving quality without adding complexity to your code.
And when it comes to that, approaching work iteratively is the best solution I’ve found. The more you build releasable iterations of your product every day, the less chance of sunken-cost-driven-product-decision-making to occur.
Think about your whole team
While engineering capacity and skills are essential for fast product delivery, engineering productivity doesn’t depend only on engineers. A stable and productive business cadence and collaboration results in a continuous flow from product ideas, design, analysis, and delivery.
Without a well-rounded team, bottlenecks and low quality work can occur at any point. Low-quality software can be delivered when there is pressure and not enough engineering capacity OR when low-quality requirements are created without enough intentional product strategy.
Also, when it comes to fixing mistakes, it’s simply less expensive to fix less code than more code. You don’t want to be paying that price.
Limit the analysis, but don’t eliminate it
Product management is one thing that easily falls to the side when the team is small. It’s hard to justify Design Sprints when your whole project takes a week, or AB testing practices when you don’t have enough users to achieve statistically significant conclusions.
While the situation above creates an urge to throw your arms up in the air and say “let’s just build this”, you can leverage simpler product techniques to receive product feedback.
You can increase how much you understand user behavior and perform UI testing in one day. You can run small versions of design workshops in a few hours. Investing in your product process in a way that makes it efficient but still allows for the right amount of thinking and collaboration in the team is worth it. Your business will be well compensated by the code you don’t end up writing.
In summary, small teams work. Have a small group of people running a lean process from concept to cash. You will be impressed by how much you can deliver.
