Software has not been an individual sport for a long time. The systems are too large to hold in one head, the on-call rotation is shared, and the code you write will be maintained by someone who was not in the design discussion. Being a good teammate is not about agreeableness — it is about making the people around you more effective, and doing it in ways that show up in the codebase.
What it looks like in the work itself
- Pull requests small enough to review properly. A 2,000-line PR is not a contribution, it is a hostage situation — and it gets rubber-stamped, which is the worst of both worlds.
- A description that says what changed, why, and how you verified it. The reviewer should not have to reverse-engineer intent from a diff.
- Reviews returned within a day. A blocked colleague is a more expensive problem than whatever you were context-switching away from.
- Comments that distinguish blocking from optional. "nit:" is a small word that prevents a lot of friction.
- Tests and documentation as part of the change, not as a follow-up ticket that will never be picked up.
- Commit messages and ADRs that explain the why. Future you is a teammate too, and has forgotten everything.
Shared ownership, actually shared
The instinct to own a subsystem entirely feels like diligence and behaves like a single point of failure. If only one person can deploy the payment service, the team's capacity is that person's calendar, and their vacation is a risk register entry. Rotate the unglamorous work — on-call, releases, the flaky test — pair on anything only one person understands, and write down what lives in your head. Being irreplaceable is a career trap, not a moat: it is very hard to promote someone nobody can replace.
The strongest signal of a healthy team is that people say "I don't know" and "I was wrong" out loud, without cost.
When things go wrong
Blameless does not mean consequence-free — it means the postmortem asks how the system allowed the mistake rather than who made it, because engineers who fear blame hide information, and hidden information is what turns an incident into an outage. During the incident itself, one person coordinates and everyone else reports what they are doing before they do it. Afterwards, the action items get owners and dates, or the postmortem was theatre.
The boundary
Being helpful is not the same as being infinitely available. If every interruption is accepted immediately, you become the team's cache and stop shipping anything of your own — and a burned-out teammate helps no one for very long. Batch interruptions, protect a block of deep work, and say "I can look at this after lunch" without apology. Push back on unrealistic commitments early and in writing, with data. And be reliable in the specific sense that matters most: if you said you would do it, it gets done or you flag it before the deadline, every time. Reliability is the trait that makes everything else count.