I recently ended my tenure at Gatsby after four years. Throughout that time, I went from being a junior engineer with less than a year of professional experience to a senior member of the team, responsible for multiple product surfaces. I’ve seen many projects through to completion and into maintenance, and have felt firsthand the results of my mistakes. Throughout this time, I’ve picked up some lessons about how a small team should be run.
Three people impacted my understanding of team culture the most: our co-founder Michael, senior engineer Hugh, and product designer Andy. Each of them had their own styles of working that at times clashed with one another. While I don’t agree with all of their approaches, I used the culture they built to formulate my own understanding.
Michael and Hugh were the antithesis of each other. Michael’s philosophy was quick and dirty: do what the customer needs as quickly as possible. Don’t spend too much time on planning; execution is more important. Hugh was more process-heavy. He pushed for daily stand-ups, sprint planning, and design docs. While this made sure everyone was on the same page, it also meant that everything took longer to finish.
I mostly agree with Michael: small teams don’t need a lot of process. Process is only as important as the increase in efficiency it provides by improving communication. Why spend time in meetings when there are only two to three people working together who can talk to each other directly? Daily stand-ups are useful but should be limited to people who work together on the same team. For example, I don’t need to hear about what sales is doing, but I do need to keep track of what my engineering teammates are doing, or if there is an update to the design or product specification. The rule of thumb is: don’t waste people’s time.
Hugh wanted to be an engineering manager, but small teams don’t need engineering managers. What you do need is a single point of contact between engineering and product, such as an engineering lead. The lead can understand the current progress of the engineering team and translate this into accurate timelines for the product team. Individuals should still be able to go around the engineering lead when appropriate. For example, the designer should be able to work directly with the frontend engineer to tweak the user interface. Nevertheless, the lead is the primary point of contact for other stakeholders.
Andy liked to ideate: he had engineers create demos, then he would tweak and sometimes overhaul his original designs. This resulted in longer development cycles and “wasted” engineering hours but usually ended up with a better, more polished UX.
I wouldn’t spend too much time on initial designs. Get the product working and ship it to users. If you’re afraid of releasing an unpolished product, find a group of core users who are willing to beta test. You should also test internally, dogfood, and tweak, but don’t spend too much time polishing. Most users don’t care as much about polish as engineers and designers do. Using your own product is the best way to make a better product.
To recap, small teams only need as much process as is necessary to communicate effectively. Individuals should work directly with each other when it makes sense, but there still needs to be a single point of contact for other stakeholders. Don’t spend too much time tweaking the product or trying to cover every use case; using the product is the best way to find its deficiencies.
These are effective ideas for running a small team, but they also need to be paired with guidelines to avoid burnout. A lack of process can create murky job responsibilities and uncertainty around job performance. In turn, I would tie the performance of the company directly to my own job performance. Working more doesn’t always lead to burnout; burnout is a combination of long hours with meaningless work. Individuals need to be excited and feel like they’re building toward something bigger. Their ideas need to be heard, even bad ones, and considered, even if they are ultimately never implemented. This can be done with tact and professionalism, detaching emotions from ideas and focusing on what actually makes the product better. Find people who have low egos and can give and take criticism freely. Talk to people in person. We can communicate much more with our body language and facial expressions than we can through text.
Finally, keep your team small for as long as you can. Many startup founders have an itch to play house, to build a team and act like they’re a “real company.” Only hire for what you need to meet your next goal. Don’t waste time and money on preemptively hiring people you don’t currently need. It’s like the engineering principle YAGNI (ya ain’t gonna need it).