When a team is too big

Team size and dynamics

• Many argue optimal engineering teams are small: commonly 3–6 people, with references to “two‑pizza” and “magical number seven” style limits.
• Once teams exceed ~7, commenters report more politics, cliques, and vying for manager attention; some solved this with rotating, task‑based subteams that form and dissolve per project.
• Others note unusually large teams (15–20) can still work well if there are informal subteams, strong culture, and clear ownership, but see this as exceptional rather than the norm.
• Several point out an important missing dimension in the article: whether the team is doing exploratory R&D vs. steady‑state maintenance, since these modes demand very different structures and behaviors.

Standups and communication

• A major thread is standups: many describe daily syncs that spiral into 30–90 minute “status theater” or solution sessions, seen as micromanagement and a waste of time.
• Suggested fixes: written/async standups, ultra‑short “blocked / not blocked” check‑ins, enforcing strict time limits and agendas, and moving real problem‑solving to ad‑hoc follow‑ups.
• Others defend brief standups as useful “dayplanners” for coordination, surfacing blockers, nudging juniors to ask for help, and giving managers a quick view of risks.
• Several note that when standups are the only communication forum, they bloat; healthy teams need ongoing direct communication (chat, impromptu calls, PRs) outside the daily ritual.

Generalists vs specialists

• The article’s “go generalist/full‑stack” solution is contentious.
• Supporters say any strong engineer can learn another discipline; T‑shaped skills (broad with one or more deep areas) match what good engineers already do.
• Critics counter that true full‑stack across modern frontend, backend, DevOps, observability, etc. is unrealistic for most; keeping up with multiple fast‑moving ecosystems is the real constraint.
• Some domains (e.g., legacy Oracle/Windows stacks vs Kubernetes/Linux) or advanced UX/accessibility/performance needs are cited as cases where specialization is essential and generalism doesn’t scale.

Management, process, and “best practices”

• Several commenters see the root problem as weak middle management: too many direct reports, no facilitation, and cargo‑cult Scrum ceremonies.
• Others argue there are no universal “best practices,” only patterns that fit specific contexts; killing rigid ceremonies (including standups) can be appropriate if teams communicate well by other means.
• Examples from large OSS projects are used to show alternative coordination models based on release cadence, code review, and gatekeeping rather than formal teams.

AI‑training notice and licensing

• The article’s “no generative AI / no training” notice sparks debate.
• Some like it and note that, in the EU, machine‑readable reservations (e.g., robots.txt) may have legal weight.
• Others consider it futile or conceptually confused: once text is public, trying to dictate how people (or models) learn from it is seen as unenforceable, though countered by analogies to software licenses and IP rights.