Skip to content

Wider Responsibility, Thinner Belonging: Pick Your First Team

At staff and manager level, responsibility spans teams while belonging thins. Pick a first team, tie belonging to a shared outcome, and keep the group open.

Ayhan Sipahi Ayhan Sipahi

Once your responsibility spans several teams, you stop fully belonging to any one of them. Will Larson calls it “surprisingly common to find folks who feel like they are not a member of any team”. For staff+ engineers and engineering managers, I recommend one default: your first team is the peers who share your cross-team outcome. The default only works when belonging to that group comes with holding each other to the shared outcome.

The Team You Lead and the Team You Are On#

A wider scope changes what you are responsible for, but it leaves your calendar mostly where it was. The platform, the migration, or the group of squads is now yours. Most of your working day, standups and reviews included, still sits with one delivery team. Belonging tends to follow where the hours go, so it stays with that team.

The cost shows up in the peer sync. Each participant arrives as an advocate for their own team, and decisions turn into negotiations between delegates. Patrick Lencioni describes the pull toward the team you lead as “so regular and understandable and dangerous”. His five-dysfunctions model ends at the same place: each team meets its own goals while the outcome they share is missed.

The default comes from Lencioni’s work with leadership teams: the team you are a member of comes before the team you lead. Will Larson makes the same argument for engineering managers (opens in new tab). In the peer groups that work this way, he writes, members have shifted their “first team from the folks they support to their peers”.

Larson writes about managers. I would extend the same default to a staff engineer without reports. The structure is the same: embedded in one team, responsible across several. The first team is then the group that shares the cross-team outcome, usually the other staff engineers and the managers of the affected teams. The Solver archetype is the extreme case, with no fixed team at all.

Belonging and Responsibility as Two Axes#

Choosing a peer group does not make it a team. The grid below is adapted from Amy Edmondson’s framing of psychological safety and accountability. Its axes are belonging to the peer group and responsibility for the shared outcome.

Low responsibilityHigh responsibility
High belongingComfortable club: a friendly sync where nobody questions a commitmentFirst team: peers own the cross-team outcome together
Low belongingDelegates: each person defends their own teamLone owner: one person carries the cross-team outcome alone

Responsibility here means the shareable kind, the work of getting the outcome. Who Owns This Code Now separates it from accountability and blame.

A new peer group usually starts in the delegates cell. The sync is a status round: each person reports and defends, and the gaps between teams belong to nobody.

The lone owner appears when one person takes the shared outcome seriously and the group does not. That person does the glue work: the follow-ups and the alignment between teams. Tanya Reilly describes this work (opens in new tab) as essential to a project’s success and not always rewarded. With no team watching, it also stays invisible.

The comfortable club is harder to notice because it feels like success. Peers like each other, and nobody challenges a missed commitment. The Table Group’s guide to Lencioni’s model gives the reason: people would sooner protect a comfortable relationship than start an awkward conversation. Edmondson reaches the same point from the safety side: psychological safety does not excuse anyone from doing the job well. She defines accountability as psychological ownership.

From Status Round to Shared Commitments#

Moving a peer group into the top-right cell takes a deliberate act. Larson writes: “It’s hard to move membership from the team you spend the most time with, and I haven’t seen it happen organically.” Someone has to say that this group is a team, and what it is a team for.

Naming the purpose attaches responsibility to belonging, because a shared calendar slot gives a group nothing to be responsible for. A first team owns outcomes that no member’s team can deliver alone, such as a migration finishing or a platform being adopted.

Commitments made in the group are tracked and reviewed in the group. That makes visible what Google’s re:Work research calls dependability: members reliably finish quality work on time. Glue work for the shared outcome goes into the group’s own record, where the other members can see it. Larson also lists refereeing among his conditions, because one member acting only for their own team invites the rest to follow.

The Table Group guide states the standard: “Once a decision is made, peers have to be willing to call each other out on behavior that hurts the team.” A group has reached that standard when a trade-off goes against a participant’s own team and that participant still backs the decision. A second sign is that concerns about a peer’s area are raised in the meeting, with the peer present.

Where the First-Team Rule Stops#

Liane Davey objects (opens in new tab) to the first-team rule. She argues that a strict version makes leadership groups insular, with too little conflict and weaker decisions. She also warns that it “can inadvertently cause you to shortchange the team you lead”.

I accept both risks and keep the default, with a narrower meaning. First team decides whose outcome wins when the group’s outcome and your own team’s outcome conflict. It is not a loyalty ranking. You still bring your team’s reality into the peer group: its capacity, its objections, and the cost a decision places on it. Davey’s alternative is to keep both roles deliberately: speak for your function first, then decide for the whole. A peer group that turns into a closed club and stops hearing from the teams it serves is failing, however pleasant the meetings are.

The rule also does not repair unclear roles. If nobody in the group knows who decides what, more belonging will not fill the gap. In that case, start with RACI and DACI for software teams and return to the first-team question once decision rights are written down.

References#

Related posts