Strangely, that’s not how everyone defines success. For many in the tech industry, success is only about revenue, customers, and employee count. To them, success is $100 million in revenue, 10 thousand customers, or hundreds of employees. None of these feel like clear indicators of success, but employee count is especially troubling.
Theoretically, growing employees allow a business to do more: to scale up, expand products, and pursue new markets. But more employees also means expensive fixed costs, management overhead, and administration. These costs suck energy and money from you. Energy and money that you could be investing in your product.
When you pay this price to add employees, you’re betting that the benefits of the employees work will more than overshadow the costs and complexity. Sometimes you’ll win. A lot of companies lose.
You don’t have to add employees to be successful. You can stay small. Technology allows small teams to make a bigger impact than ever before, but we need to set ourselves up to thrive small.
Small teams are awesome. Many of the benefits attributed to Startup businesses over corporations are actually the advantages of small teams over big ones. Small teams are at the heart of agile software development, largely because they communicate better and can be properly incentivized to succeed.
The Mythical Man Month taught us about the limits of group communication, also called the handshake problem. As the number of people in the team increases, the number of communication paths explodes. To manage that explosion, you have to start segmenting people into specialized groups. Unfortunately, groups mature into their own tribes, and don’t communicate as well anymore, and many opportunities to integrate or change direction are lost.
As the number of groups increase and become more specialized, you also lose the ability to incentivize them correctly. A small team has a single goal: increase the profitability of the product. Achieving that goal can take lots of forms, but a small team will adapt and seek out the most effective path when they share in the success.
A specialized team can’t be incentivized the same way, at least not with the same effectiveness. Let’s say you’ve grown your employees and specialized into a marketing group. Marketing doesn’t have direct control over profitability, and they will argue that they should be incentivized on what they can control, perhaps the number of leads created. While entirely reasonable from their perspective, that’s not the same thing as profitability, and encourages groups to maximize their goals, often to the detriment of the overall product.
Setting your goals and prioritizing the work to achieve them is one of the most important decisions of a business. A small team helps you make the right decision by limiting the amount of work you can do. That can be a tremendous advantage because it forces you to understand your goals and aggressively prioritize. It forces you to constantly decide “what one most important thing should we do next?”.
Growing your team encourages you to take shortcuts prioritizing and take on too much work. Imagine you have customers clamoring for new features, a new landing page for marketing, and a few big expansion projects you’ve been thinking about. It’d be easy and tempting to build everything, especially if you have a big team to spread the work.
Making prioritization decisions is hard. But by limiting work to the next most-important thing, the right decision is easier to make.
A small team does not have the capacity to handle lots of unplanned work. Unplanned work like outages and external changes. While all teams should avoid unplanned work, it is especially critical for small teams because it quickly drains energy and attention away from the important work.
Avoiding unplanned work starts with technology choices. Choosing technology that is old and boring is also choosing technology that has well-understood failure modes. Technology that you can predict and plan for outages. Building your product atop the latest technology feels cool and cutting edge, but getting that 2AM outage alarm sucks. Worse, if it happens at 2AM every day.
Keeping the maintenance needs of the team minimal and reducing the risk of unplanned work is essential to keep the team focused on the “most important thing”. Avoiding maintenance means implementing systems that require little maintenance, duh. We gravitate towards hearty, reliable systems that are observable, self-repair, and have few external dependencies. If we can’t build that, the benefits of the work might not outweigh the maintenance risk.
Sometimes, our desire to stay small and stable limits what we can do. There are some features and capability that we won’t pursue because of maintenance needs, or the risk of unplanned outages are too high. We believe that this is the right choice for us, and the right choice for our customers. We have a small, totally sustainable, and highly-reliable system that catches lots and lots of bugs for our customers. And that’s what success means to us.