Software Engineering is a Team Sport

A passage that shaped my perspective on software engineering:

The point we've been hammering away at is that, in the realm of programming, lone craftspeople are extremely rare—and even when they do exist, they don't perform superhuman achievements in a vacuum; their world-changing accomplishment is almost always the result of a spark of inspiration followed by a heroic team effort.

A great team makes brilliant use of its superstars, but the whole is always greater than the sum of its parts.

Let's put this idea into simpler words: software engineering is a team endeavor.

This concept directly contradicts the inner Genius Programmer fantasy so many of us hold, but it's not enough to be brilliant when you're alone in your hacker's lair. You're not going to change the world or delight millions of computer users by hiding and preparing your secret invention. You need to work with other people. Share your vision. Divide the labor. Learn from others. Create a brilliant team.

The quote is from Titus Winters, Tom Manshreck, and Hyrum Wright in Software Engineering at Google. I read it in 2023, three years into my career, deep in pandemic-era habits: locked in the hacker lair, isolated from my team, convinced I had to deliver something singular to change the world (or at least my org). The book was a mirror. I needed to work with other people. I needed to share a vision.

My priorities have inverted since. Technical excellence and impact used to top the list; today it's teamwork, leadership, and mentorship. Some specifics.

A Team Sport

Software engineering is a team sport. Every role on a sports team has an engineering counterpart:

• Coach → Manager. Sets strategy, develops players, calls the plays.
• Team Captain → Tech Lead. A player on the field who rallies and directs.
• General Manager → Director. Builds the roster, makes trade-offs on talent and resources.

The org chart and the roster have the same point: nobody runs the play alone.

Old me: take a feature, disappear for two weeks, surface for code review with the work "done" and "perfect." A solo run on a team field. Predictably:

• The coach had the play. Requirements I'd assumed wrong, surfaced too late to fix cheaply.
• The captain was on the field. Design choices nobody validated, defended past the point of usefulness.
• The GM saw the roster. Someone on the team quietly building a parallel version of the same thing.

All of it preventable. All of it caused by not asking for feedback while I still could.

A player who only trains alone doesn't get better. They just get really good at the wrong thing.

My Playbook

Joining a new team, the metric used to be time-to-landed-code. I'd read code in detail the first week, often the first day, with the goal of submitting something useful within two weeks. I still ship early. The priority is now people: you can't pick the right thing to ship if you haven't asked anyone what matters.

Example: find a problem your manager doesn't enjoy giving attention to. Take it.

Why it works: trust gets built where someone else stops paying attention. You learn how the team operates by inheriting one of its uglier corners, and you don't need permission to start.

Then I learn the culture, both team and org. Canvas enough people and the picture sharpens: where this org came from, how decisions actually get made, where growth happens. None of it is in a doc. All of it determines whether your work lands.

Example: can you tell your org's history, prototype to present, to someone who doesn't work there?

Why it works: if you can narrate the story, you understand the why behind the codebase, the org chart, the calendar invites. If you can't, you're optimizing for what looks important instead of what is.

Last, I try to sell a vision. This step comes after, never before. By now I've built credibility, mapped the culture, and earned an opinion. Maybe there's a tool I built that solves a recurring frustration. Maybe there's a roadmap-shaped gap nobody has named yet. Either way, it has to read as the natural next thing, not an outsider's pitch.

Example: if you had a free quarter, what would you build, and would your peers nod when you said it out loud?

Why it works: a vision your team nods at is a vision they'll help you ship.

Leaving the Lair

Three years in, I read a book about software engineering as a team sport. Six years in, I feel like I'm finally getting it down.

The best work I've done has been a heroic team effort. I shared a vision. I divided the labor. I learned from others.

Software engineering is a team endeavor. And I spend every day trying to be a better teammate.