Getting Actually Useful at Leading Small Teams
I spent several years managing operations teams that ranged from six to fourteen people, and the biggest problem I saw wasn't a lack of training or poor tools. It was people trying to lead small groups like they were running something much bigger. The Small Unit Leadership A Commonsense Approach isn't really a formal system you can buy. It's more of a set of principles that emerged from watching what works and what falls apart in practice. The core idea is straightforward: a small unit of roughly six to twenty people operates fundamentally differently from a large organization. You cannot run it with large-organization methods. Most leaders I've seen who struggle are applying processes designed for hundreds of people to teams of a dozen. The results are predictable — paralysis by analysis, wasted meetings, people doing busy work instead of useful work. Start with clear intent, not detailed instructions. In a large unit, you write procedure documents for everything. In a small unit, that's counterproductive. Your team members need to understand the objective and the constraints, then they need the space to figure out the method themselves. I learned this the hard way when I assigned a six-person team to reorganize our inventory tracking system. I wrote a two-page process document covering every step. They followed it exactly, which meant the project took three weeks instead of four days. The system we ended up with was technically correct but entirely inadequate for what we actually needed. After that, I switched to describing the desired outcome and letting them solve it. It went faster and worked better every time.
Communication in a small unit should be direct and frequent, not layered through multiple approval chains. One level of management above the team lead is usually sufficient. I've seen teams where the lead had to get sign-off from three different managers before making a routine decision. That's not small-unit leadership. That's a bureaucracy pretending to be a small team.
What This Looks Like in Practice
Delegation is where most leaders fail in small-unit environments. The instinct is to take control when things get stressful. That instinct is wrong. You delegate authority, not just tasks. When someone on your team has the authority to make decisions within their area, they move faster and they become more invested in the outcome. I had a team member once who needed to escalate a vendor issue. The standard process required a written report and approval from two departments. She bypassed that, called the vendor directly, and resolved it in forty-five minutes. When she came to me afterward, I made sure the appropriate people knew what happened rather than reprimanding her for skipping the process. The process was the problem, not her. Trust is a finite resource in any team, and small units consume it quickly if you waste it. Micromanaging a team of eight people is like trying to drink from a fire hose. You will fail, and everyone will be miserable. I ran a project once where I had eleven people working across three time zones. My initial approach was daily check-ins with each person. By week three, I had burned through all available trust and was spending six hours a day in meetings instead of doing actual work. The workaround was simple: I switched to weekly status reports and biweekly one-on-ones. The quality of the work improved because people had time to think between interactions. The visibility I lost was negligible. The people who felt trusted performed at a higher level across the board. Feedback needs to be immediate and specific. Waiting for a quarterly review to tell someone they have been doing something wrong for three months is not leadership. It's negligence. In a small unit, feedback travels fast enough that you can correct course in real time. I usually address issues within twenty-four hours of noticing them, and I keep those conversations under ten minutes unless the situation requires more depth.
Get the Full Details
Where This Breaks Down
This approach does not work universally. If your small unit is handling highly regulated work where documentation and compliance checks are mandatory, some of the flexibility I'm describing becomes impossible. I managed a team that built medical device software for eighteen months. The FDA requirements meant we could not delegate certain approval decisions no matter how competent the individuals were. In those situations, you layer in the necessary controls on top of the commonsense foundation. The goal is minimum sufficient process, not no process. Another scenario where this struggles is when team members lack the experience to operate autonomously. The intent-and-space model assumes your people can figure out the method. If they are genuinely inexperienced, you need more hands-on guidance until they reach a threshold of competence. I have seen leaders skip this step entirely and pretend that autonomy training is unnecessary. It is not. The approach also requires that you, as the leader, have enough context about the work to set appropriate intent. If you are leading a technical team in an area you do not understand, your ability to define boundaries and accept alternatives becomes significantly harder. In that case, you need to invest time in building domain knowledge or pair your team with a subject matter expert who can fill the gap.
Practical Rules That Actually Matter
Keep meetings short and purposeful. A team of ten people in a fifty-minute meeting is typically spending thirty-five of those minutes listening to other people talk. I found that standing meetings or twenty-minute timeboxes forced people to cut out the unnecessary discussion. Decisions that previously took two meetings now took one, and sometimes neither if they were straightforward enough to resolve over chat. Make objectives visible to everyone on the team. When a developer can see how their work connects to the customer outcome, they make better decisions without needing permission for every minor thing. I posted a single page with our current quarter's top three priorities and linked it from our main communication channel. People referenced it constantly. It reduced the number of questions about direction by maybe sixty percent because they could answer their own questions. Rotate decision-making responsibility when possible. Having one person always make the calls creates a bottleneck and it disengages the rest of the team. I rotated the lead role on a monthly basis for non-critical projects. The person rotating had to present their plan to the group beforehand, which forced them to think critically about the work. It also meant that if someone was out, another person already understood the current direction. This is especially valuable in small units where key-person dependency is a constant risk.
Accept that some inefficiency is acceptable. In large organizations, efficiency is optimized because the cost of waste is spread across many resources. In small units, speed and adaptability often outweigh pure efficiency. I used to push for perfectly documented processes. After watching a team spend two weeks building documentation for a project that got pivoted halfway through, I stopped caring about documentation that nobody reads. We now document only what is necessary for continuity and compliance. The rest gets captured in conversation and moved on. The Small Unit Leadership A Commonsense Approach ultimately comes down to treating people on your team like adults who are capable of solving problems. Most leaders know this intellectually. They struggle with it emotionally because losing control feels risky. The risk of tight control is usually higher than the risk of, and the difference becomes especially clear when your team size stays under twenty people. Above that, you start needing more structure simply because coordination becomes a heavier lift. But within the small-unit range, commonsense leadership consistently outperforms rigid methodology.
