The magic of small engineering teams
Small engineering teams are praised for their speed, focus, and reduced communication overhead, especially in early-stage startups where everyone wears many hats. Commenters contrast this with the frustrations of small teams inside large organizations, where bureaucracy, dependency on centralized functions, and “accountability without authority” can severely limit effectiveness. A recurring theme is that while small, autonomous teams can work well, scaling a company almost inevitably introduces specialization, coordination costs, and growing maintenance burdens that blunt the initial productivity advantages.
Small teams inside large organizations
- Several comments describe small teams in big companies as powerless and blocked: long waits for procurement, infra, security, or marketing even for trivial needs.
- A recurring complaint is “accountability without authority”: teams held to major delivery deadlines but unable to approve tiny expenses or bypass process.
- Some argue the only rational response in toxic, over-controlled cultures is to quit; others find meaning in “refactoring” the organization and shielding their teams.
Bureaucracy, abuse, and controls
- Many processes are framed as reactions to a few abusers, producing barriers that slow everyone else.
- Multiple people endorse the idea that the “optimal amount of fraud is non-zero”: preventing all abuse costs more than occasional loss.
- There’s debate over whether abuse should ever be “accepted”: some say tolerate and punish when caught; others insist on firing abusers quickly.
- Measuring the cost of bureaucracy vs. abuse is seen as hard and asymmetric; risk aversion leads orgs to prefer visible process costs over uncertain fraud risk.
Startups vs. big companies
- Several participants strongly prefer small startups for autonomy, speed, and focus on tech rather than internal empire-building or greed.
- Others note that after big funding rounds, imported management cultures can quickly recreate big-company dysfunction.
Team size, specialization, and the “pizza” metric
- Many agree small teams (roughly 4–8 people) execute faster due to fewer communication paths; some emphasize on-call sustainability and redundancy as reasons to go slightly larger.
- The “two-pizza team” idea is widely criticized as vague and culturally dependent; people debate what pizza size and serving assumptions it implies.
- Role specialization and “this isn’t my job” are identified as the inflection point between startup-like fluidity and necessary bureaucracy.
Scaling, maintenance, and limits of the model
- Commenters argue a 47-person company hasn’t proven a scalable small-team model for hundreds or thousands of staff.
- Several point out that as products mature, maintenance dominates; per-engineer “new features shipped” must drop, regardless of team structure.
- Some suggest large firms resemble planned economies: internal monopolies, little incentive to improve, and structural pressure to keep growing headcount.