Book a Free Call
No commitment required
What happens when you hand over a full production big project to a five-person team — two developers, one QA, a Product Manager, and a Project Manager?
You get focus. You get velocity. And you also get:
“Can someone fix this production bug, write tests, do QA, write documentation, handle that meeting and deploy in the next 20 minutes?”
Over the past year, we operated under that structure, a testament to the trust and enabling environment fostered by our organization. Our team owned a production system, with responsibility for new features, maintenance, supporting, coordination, and delivery. All while juggling competing priorities and maintaining company-level engineering standards, supported by a culture that prioritizes the results, but has a strong space for well-being.
Working at this scale comes with trade-offs, challenges, and some very specific kinds of teamwork. We want to share what we learned from twelve months of building, maintaining, and growing a production system with a small, tight-knit crew. This post is a reflection on that experience. Not a romanticized "we hustled harder" story, but a look into the technical, procedural, and human trade-offs of building software in a small but highly responsible team, made possible by the robust foundation our organization provides.
Working in a small team has its perks. After a year, we found that the benefits outweighed the challenges in many ways. Here are some of the key advantages we experienced:
When your entire team fits into one video call without needing to scroll, communication naturally becomes simpler, faster, and reaching consensus tends to be easier. There’s no need to schedule across multiple calendars, no lengthy email threads, and definitely no over-engineered alignment docs. We focused on sufficient documentation to facilitate immediate team understanding, serve as a reliable future reference, and ensure efficient integration for any new team members.
Coordination around deployment times, responsibilities, support ownership — most of the things got clarified with one quick message or call. This smooth communication was a direct benefit of the agile principles fostered by organizations through the ongoing pursuit of agile education.
The reality is that more is not better for team effectiveness. Harvard professor (and specialist in team dynamics) Richard Hackman has shown that one of the key challenges with large teams is in the growing burden of communication. Put simply, as group size increases the number of unique links between people also increases, but exponentially. [1]
Conway’s Law (Melvin Conway, 1968) reminds us that software architecture mirrors team structure. When a team is small and tightly coupled, systems tend to reflect those efficient, low-friction communication paths — leading to architectures that are often flatter, leaner, and easier to reason about.
In a team of two developers, there’s no room for rigid silos. We naturally had to learn each other’s areas and fill in for one another when needed, not just in code, but also in testing, support, analysis, and even UI/UX design. This made us grow as engineers. We each became more T-shaped: keeping our depth, but gaining breadth across the system. When one was out for some reason, the other could take over.
Organizations that actively promotes cross-functional growth, fosters a culture where individual development contributes to collective resilience. A small team can’t afford to have one person be the sole expert in a module or feature. We had to be able to jump in and help each other out, which meant we both had to understand the system as a whole, not just our individual parts.
The concept of T-shaped skills is often cited in agile frameworks like SAFe and Lean UX — emphasizing adaptability across multiple functions while maintaining deep specialization in one.
It was easier to reflect on our process, because it was our process. Sprint retros, bug triage, and even standups were all tailored to our needs. We could iterate quickly on what worked and what didn’t with fewer people involved, so it was easier to implement improvements faster and see their effect.
We iterated on our standups, our ticketing process, our testing approach. If something didn’t work, we tried a different tactic. And the feedback loop was immediate.
Additionally, we could experiment with new tools or practices without needing to convince a large group. If it worked, great. If not, we moved on without much overhead. When companies place trust in their engineers, providing them the autonomy to experiment and refine their workflows, they unleash a powerful potential for continuous improvement.
As described in Team of Teams by General Stanley McChrystal: Smaller, empowered groups can adapt faster — and that agility made all the difference in how we continuously improved.
Because there were only two engineers, we had to understand the whole system. Even if we weren’t experts in each other’s modules, we both needed enough context to debug an issue, explain the flow to PMs, or pair-program in high-stakes situations. We didn’t need a heroic memory or perfect documentation — just a shared commitment to not hoard knowledge. Our company’s focus on open knowledge sharing, including activities like internal tech talks and Community of Practice, helps proactively reduce the bus factor.
The “bus factor” (the number of people who can be hit by a bus before a project is in trouble) is notoriously low in small teams. We actively worked to keep it at least above 1.
With fewer people, we could move faster. There were no lengthy meetings, no endless discussions about process, and no need to align across multiple teams. We could ship features quickly, provide support effectively, fix bugs immediately, and deploy, respecting the processes, but without waiting for a long approval chain.
This high velocity was a direct result of our small size, but also the trust and autonomy our organization provided. We were empowered to make decisions, take rational risks, and learn from our mistakes without fear of retribution. This is a key aspect of agile methodologies, where small teams can iterate quickly and adapt to change without the overhead of larger organizational structures.
While there are many benefits to small teams, there are also significant challenges. Big teams can absorb the load of unexpected issues, but small teams often feel the weight of every decision and every incident. Here are some of the key challenges we faced:
When a team member was out, the remaining developer had to pick up everything: code, reviews, support, deployments, and communication. It worked, but only barely. There were weeks where velocity dropped, pressure rose, and we were one production incident away from burnout. This highlights the importance of the organization’s broader initiatives, such as open spaces for shared hobbies and company-wide activities, which provide crucial opportunities to step away, recharge, and return to work with renewed energy, preventing prolonged stress.
When you’re a small team, every urgent task feels like a fire drill. There’s no one else to handle it, so you drop everything to fix that production bug, write that test, or handle that urgent support request. This leads to a constant state of urgency, where the team is always on edge, always ready to jump into action.
This can be exhausting. The pressure to deliver, to fix, to support, and to maintain can lead to burnout if not managed carefully. Our ability to manage this intense workload was significantly aided by the organization’s supportive infrastructure, including the emphasis on work-life balance and the provision of comfortable, high-performance tools that reduce friction in our daily tasks.
With a small team, there’s nowhere to hide. If collaboration falters, if feedback is taken personally, or if there’s friction in communication, it quickly becomes the dominant problem.
We were lucky: our team had a culture of respect, humor, and shared purpose. But that’s not always the case, and a breakdown in communication between two engineers can grind a project to a halt. Our organization’s commitment to fostering a culture of open communication and conflict resolution was crucial in helping us navigate these interpersonal challenges, ensuring that we could address issues before they escalated.
As noted in Crucial Conversations by Patterson et al., small teams require high levels of interpersonal trust and communication to function effectively. When that trust erodes, the team’s performance can suffer significantly.
Small teams can move mountains, but not without scar tissue. What we’ve gained in speed, ownership, and learning came at the cost of occasional overload and the challenge of sustaining motivation. The key is to be intentional: balance autonomy with process, speed with sustainability, and ownership with support. We’re proud of what we accomplished, and we’re excited to keep building. The challenges were real, but so were the rewards.