Is Modern Software development still the Ultimate Team Sport?

I’ve been watching the latest developments in software development closely, and with some interest. I’m seeing parallels between my early career and the current technologies being touted as the next best thing. Chunky (AI-written) specifications and (super crazy fast) waterfall development anyone?

For decades, the promoted stereotype of software development was a loud, chaotic team sport. We pictured war rooms covered in whiteboard scribbles, late-night pizza fueled hackathons, and open-plan offices buzzing with synchronous chatter.

Today, walk into a modern tech company, or indeed log into their Slack workspace, and it feels very different. It’s quieter. Engineers are remote, communicating via asynchronous pull request comments. AI assistants could be writing significant chunks of boilerplate code. A solitary "indie hacker" can now launch a profitable SaaS product in a weekend using low-code tools (or so the internet would have you believe!).

This shifting landscape begs the question: Is software development still a team sport?

The short answer is yes. But the definition of "the team", the rules of the game and the playing field itself are undergoing a radical transformation. The days of throwing engineers at a coding problem are over. Today, it’s a sport of hyper-coordination, cross-functional friction, and elite, smaller units.

1. The New Rules: Why Collaboration is Non-Negotiable

It is tempting to look at the productivity gains of individual engineers using AI tools like GitHub Copilot and conclude that teams are becoming obsolete. This misses the bigger picture. While writing code has become easier, building systems has become infinitely more complex.

The Cognitive Load Problem

Twenty years ago, a "Full Stack Developer" could realistically master an entire stack. Today, a standard enterprise application involves microservices, container orchestration, dizzying cloud infrastructure options, complex front-end frameworks, and intricate CI/CD pipelines, not to mention the additional prerequisite mobile app.

It is cognitively impossible for one person to be an expert in all these domains. We need teams not just for extra hands, but for specialised brains. We need the security specialist, the DevOps engineer, and the UI expert to come together like a film crew specialising intensely and collaborating smoothly.

From Scrum to Relay Race

The "sport" used to look like a rugby match with everyone moving together in real-time. Now, remote-first cultures have turned it into a high-speed relay race. The focus has shifted from synchronous chatter to asynchronous precision. The best teams win not by talking the loudest in a stand-up, but by communicating clearly whether that’s through written documentation, detailed Git commits, and/or precise specs. There’s potentially a future discussion here about how modern AI tools that seem to lend themselves to solo efforts can be used effectively by teams.

2. Redefining "The Team": Enter the Trio

Perhaps the biggest shift in modern development is realising that if you only look at the developers, you are missing half the team.

In the old "waterfall" days, development was a series of handoffs. Product wrote requirements and tossed them over the wall to Design. Design made mockups and tossed them to Engineering. Engineering wrote code and tossed it over to the Ops team. This model is obsolete.

Today, high-performing software is built by a cross-functional Product Trio working simultaneously. The "sport" is the constant, healthy tension between three distinct perspectives:

• Product (The "What"): Focuses on Viability. Does this solve a real business problem that customers will pay for?
• Design (The "How it looks/feels"): Focuses on Desirability & Usability. Do users actually want to use this, and can they figure it out?
• Engineering (The "How it works"): Focuses on Feasibility. Can we build this securely, scalably, and efficiently?

Friction Is the Gameplay

In a solo endeavor, you make all the compromises yourself in a vacuum. In a team sport, the friction leads to better outcomes.

An engineer pushes back on a PM's feature request because it will ruin site performance. A designer pushes back on an engineer's shortcut because it degrades the user experience. This negotiation is the game. Without the team, there is no one to check your blind spots.

3. The Roster Size: The Magic of the "Two-Pizza Team"

If the "Product Trio" (Product Lead, Design Lead, Engineering Lead) are the captains deciding the strategy, how big is the actual team?

In the modern era, massive teams are viewed as a liability. The industry standard has converged around Amazon’s famous "Two-Pizza Rule": If a team cannot be fed by two pizzas, it is too large. (Clearly, never worked in a team with me on it!)

This usually translates to a squad of 5 to 9 people:

• 1 Product Manager
• 1 Product Designer
• 3-6 Engineers (with varying specialisations)

Why is this the sweet spot?

Any smaller (a team of 2-3), and you lack redundancy. If one person gets sick or goes on holiday, velocity hits zero. You also lack the skill diversity needed for complex stacks.

Any larger (12+ people), and communication overhead cripples you. Consensus becomes impossible, meetings drag on, and psychological safety diminishes; quiet voices with good ideas get drowned out.

If you are building something massive like Netflix or Uber, you don't build a 500-person team; you build a Team of Teams. You create dozens of autonomous two-pizza squads, each owning a specific slice of the product domain.

The Verdict: From Brute Force to Coordination

Software development has matured. We have moved away from the sport of brute force - measuring success by hours worked or lines of code written - toward a sport of coordination, measured by customer outcomes and system reliability.

Equally, the lone wolf developer building an enterprise system is a myth of the past. But the bloated, bureaucratic IT department of the 90s is also dying.

The future belongs to small, elite, AI-empowered squads led by a tight-knit trio of Product, Design, and Engineering. The game is faster and more complex than ever, and you absolutely still need a team to win.

This article is AI generated by me from a series of questions and prompting using Gemini 3 Thinking model. I refined and editted the final version. It does, however, reflect my own personal opinion of where we are at for modern professional software engineering and why. I'd be interested to hear you thoughts - use disqus below.