The magic of small engineering teams

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.