2016 is almost over, and I’ve been running the engineering team at Dropbyke for about a year now. We started as three people with a monolith and a lot of ambition. We’re ending the year as seven, with a handful of services, a real deployment pipeline, and a much better understanding of what makes a small team work.
Some of that understanding came from reading. Most of it came from making mistakes and then paying attention. The short version: small teams with clear ownership, written context, and permission to disagree will outperform larger teams that rely on heroics and tribal knowledge. I learned this by getting it wrong first.
The hire that changed how I think about hiring
Early on I hired someone brilliant. Strong technical skills, great in interviews, impressive background. Within two months the team was slower than before. Not because the person was bad at code. Because they were bad at collaboration. They dismissed questions in reviews. They rewrote other people’s work without discussion. They treated every technical decision as a competition.
I waited too long to address it. I kept telling myself the technical output justified the friction. It didn’t. By the time we parted ways, I had lost one engineer who quit quietly and another who stopped contributing ideas in meetings.
The lesson was simple and painful: a good engineer who makes the people around them worse is a net negative. I don’t care how fast you can ship if the team ships slower because of you.
After that, every interview included a pairing session where I watched how candidates communicated under ambiguity. Not whether they got the answer, but how they handled not knowing it.
Writing things down saved us
The single highest-leverage practice we adopted was writing things down. Architecture decisions, deployment procedures, incident postmortems, onboarding steps. All of it.
This wasn’t natural for us. We were a small startup. Everybody sat in the same room. Writing felt like bureaucracy. Then someone went on holiday for a week and we realized that half of our operational knowledge lived in one person’s head. That isn’t a team. That’s a single point of failure with extra chairs.
We started with a rule: if you make a decision that affects how something works, write a short paragraph explaining what you decided and why. Not a formal document. Not a template. Just the decision and the reasoning. We kept these in a shared repo.
Within a month, arguments about past decisions dropped to near zero. New engineers could read the context instead of guessing. And when we revisited old decisions, we could evaluate them against the original reasoning instead of relying on memory.
Clarity scales better than talent. I believe that more every month.
Small and scoped beats big and versatile
We tried having one team that did everything. Backend, frontend, infrastructure, mobile API work. It worked at three people. At five, it started to crack. Not because people were less capable, but because context switching became the dominant activity. Everybody was halfway through everything and fully done with nothing.
We split into two groups. One owned the rider-facing product and mobile API. The other owned fleet operations, the backend services, and infrastructure. Each group had enough skills to ship without waiting for the other.
The improvement was immediate. Cycle time dropped. Ownership became clear. People stopped asking “who is working on that?” because the answer was obvious from the structure.
I don’t think there’s a magic team size. But I do think the moment coordination overhead starts eating into building time, you have outgrown your current structure. Pay attention to that signal.
Psychological safety isn’t a slogan
I used to think psychological safety meant being nice. It doesn’t. It means people can say “I don’t understand this” or “I think this is the wrong approach” without fear. That’s harder to build than it sounds.
The most useful thing I did was start admitting my own mistakes publicly. When I made a bad architectural call, I said so in standup. When I didn’t know the answer, I said that too. It felt uncomfortable at first. But within a few weeks, other people started doing the same thing. Problems surfaced earlier. Fixes came faster.
The other thing that mattered was how we handled incidents. We ran blameless postmortems for every significant outage. No finger pointing. Just: what happened, why did our systems allow it, and what do we change so it doesn’t happen again. We focused on the process, not the person. After a few rounds of this, people stopped hiding mistakes and started reporting them immediately. That alone probably saved us from two or three serious production incidents.
Conflict is data
In a small team, disagreements are inevitable. The question is whether you treat them as a threat or as useful information.
We had a multi-week argument about service boundaries. Two engineers had fundamentally different views on where to draw the lines. My instinct was to pick a side and move on. Instead, I made them write down their positions and trade-offs. Once everything was on paper, the disagreement was about specifics, not personalities, and we found a middle path that neither of them had originally proposed.
Now I encourage disagreement, as long as it stays about the work. When it gets personal, I address it immediately. Tolerating that even once sends a signal that undermines everything else.
What I would do differently
I would hire for collaboration earlier and more deliberately. I would start writing decisions down from day one, not after the first crisis. I would split teams sooner. And I would be more honest with myself about when a personnel problem is actually a personnel problem, not a process problem.
None of this is revolutionary. But doing these things consistently, with discipline instead of heroics, made a bigger difference than any technical choice we made all year.
The team you build builds the product
Building an effective engineering team isn’t about assembling the best individuals. It’s about creating conditions where normal people do exceptional work together. Write things down. Keep teams small and focused. Make it safe to disagree and to fail. Address problems when they are small. That’s most of it.