Staff+ Engineers Must Rebuild Team Culture ![rw-book-cover](https://res.cloudinary.com/leaddev/image/upload/f_auto/q_auto/dpr_auto/c_limit,w_1920,h_1080/next/2024/10/article-hero-leadership.png) ๐Ÿ”— **Source:** [Staff+ Engineers Must Rebuild Team Culture](https://leaddev.com/leadership/staff-engineers-must-rebuild-team-culture) > [!note]+ Document Notes > > [!info] Generated analysis โ€” not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # ๐Ÿท๏ธ Title: Staff+ Engineers Must Rebuild Team Culture > ## ๐Ÿงญ Table of Contents > - [๐Ÿ“ Summary](#-summary) > - [๐Ÿ“– Main Content](#-main-content) > - [๐Ÿ—’๏ธ Notes](#๏ธ-notes) > - [๐Ÿ“š References](#-references) > - [๐Ÿ—ฃ๏ธ Paraphrase](#๏ธ-paraphrase) > - [๐Ÿ“ฐ Newsletter](#-newsletter) > - [โœ… Action Items](#-action-items) > - [๐Ÿงช Hypotheses](#-hypotheses) > - [๐Ÿ“Š Methodology](#-methodology) > - [โ“ Questions](#-questions) > - [๐Ÿ”ฎ Future Research](#-future-research) > - [๐Ÿ’ก Implications](#-implications) > - [๐Ÿง  Learning Styles Assessment](#-learning-styles-assessment) > - [๐Ÿ“Š Accessibility Assessment](#-accessibility-assessment) > - [๐ŸŒ DEIB Assessment](#-deib-assessment) > - [โœ… Logical Validity](#-logical-validity) > - [๐Ÿ›ก๏ธ DARVO Analysis](#-darvo-analysis) > - [๐ŸŽฏ Conclusion](#-conclusion) > ### ๐Ÿ”— References > - Richard Dalton (chief design officer, Verizon) โ€” cited for "teams are immutable structures" > - Tuckman's stages of group development (forming-storming-norming-performing) โ€” cited framework > - LeadDev's own related coverage: "The 2026 Engineer Paradox: More Capable but More Alone," "Navigating Engineering Team Friction," "How to Become a Staff Engineer," "Derisking the Big Decisions: A Playbook for Staff Engineers" > - "Be the glue" (noidea.dog) โ€” external essay referenced for the staff+ glue-work concept > ## ๐Ÿ“ Summary > - **What happened.** James Socol (senior staff engineer, currently on sabbatical) argues that AI-enabled parallel, solo work is eroding the three markers researchers use to define a team โ€” shared goals, interdependent work, stability โ€” turning teams into "a collection of individuals" who ship more but collaborate less, and that staff+ engineers must now deliberately manufacture the culture-building interactions (celebration, charters, modeling) that used to happen automatically through necessary collaboration. > - **Why it matters.** This targets a specific, current organizational anxiety โ€” AI making individual engineers more productive while quietly dissolving the social structures ("team") that used to transmit norms, mentorship, and tacit knowledge peer-to-peer. > - **Stakeholders.** Staff+ / senior individual-contributor engineers (the addressed audience and the ones expected to do the rebuilding work); engineering managers (whose org design choices set the goal/incentive structure); junior engineers (who lose the peer "stories, battle scars, and lessons" channel the piece names as AI's replacement). > - **Risks.** The piece places the entire remediation burden on staff+ engineers' discretionary effort (celebration, charter-writing, modeling) without proposing structural/incentive changes โ€” if goals stay individually assigned, culture-work becomes unpaid, uncredited labor layered on top of the same output pressure that caused the erosion. > - **Bottom line.** A practitioner essay diagnosing a specific AI-adoption side effect (team dissolution via parallelization) and proposing individual-behavior remedies rather than structural ones. > ## ๐Ÿ“– Main Content > ### ๐Ÿ—’๏ธ Notes > - **Before/after contrast.** Opens with a personal before-AI/after-AI comparison: a year or two ago the team had one or two shared sprint goals and collaborative unblocking; now there are as many goals as engineers, parallelized across experiments rather than within one feature, and stuck engineers struggle to find help. > - **Three markers of a team (research-backed).** Names shared goals, interdependent work, and stability as the research-established markers distinguishing a team from "a collection of individuals," citing 25 years of research (unspecified studies) and Richard Dalton's "teams are immutable structures" framing plus Tuckman's forming-storming-norming-performing model. > - **The mechanism.** AI lets engineers ship solo, trading team bond for reduced friction โ€” but that friction (communication, collaboration) is specifically what used to propagate and reinforce culture; losing it doesn't just cost efficiency, it costs culture transmission. > - **Culture defined operationally.** "The way we do things around here" โ€” built from behaviors celebrated, tolerated, discouraged; established and reinforced through everyday interactions. Without shared interactions, individuals get answers "distilled by the AI" instead of from each other, losing the "stories, battle scars, and lessons" that came with peer-sourced answers. > - **Staff+ engineers as culture carriers.** Because the org holds staff+ engineers up as examples, their choices propagate โ€” celebrating good behavior (shout-outs, kudos channels, cross-team storytelling), writing/maintaining a living team charter, and modeling decision-making processes explicitly (so others learn how "it depends" applies in practice) are named as the three deliberate levers. > - **Historical parallel.** Compares this shift to the earlier remote-work transition, where interactions that used to happen automatically in a shared physical space had to be deliberately recreated โ€” framing AI-driven isolation as a second instance of the same kind of adaptation problem, not a wholly novel one. > - **Closing frame.** Positions staff+ engineers as already expected to "be the glue" within and across teams, and argues the same communicating/documenting/planning/reviewing time can be redirected to intentionally build the habits and norms that culture used to acquire automatically. > ## ๐Ÿ“š References > - No academic citation given for "research over the past 25 years" โ€” the specific studies underlying the shared-goals/interdependence/stability markers are not named. > - Richard Dalton (Verizon) quote is attributed but not sourced to a specific talk, article, or date. > - Tuckman's model is a real, named, citable framework (1965 original, well-established in organizational psychology) โ€” the one properly-grounded citation in the piece. > ## ๐Ÿ—ฃ๏ธ Paraphrase > Socol describes a shift he's observed firsthand: a year or two ago his team had shared sprint goals and people readily helped each other when stuck; now, with AI letting each engineer ship faster solo, the team has as many goals as people and works in parallel rather than together, and stuck engineers struggle to get help. He grounds this in research naming three markers of a real team โ€” shared goals, interdependent work, and stability โ€” and argues AI is eroding all three by letting individuals succeed independently. The deeper cost, he argues, is cultural: culture is built and reinforced through the everyday interactions a team used to need in order to get unstuck, and when engineers get answers from AI instead of from each other, they lose the peer stories and lessons that used to travel along with those answers. Because staff+ engineers are held up as behavioral examples by the org, he argues they now have to do deliberately what used to happen as a side effect of necessary collaboration: celebrate good behavior publicly, write and actually use a team charter, and model their own decision-making out loud. He closes by comparing this to the earlier shift to remote work, where physical-proximity interactions also had to be deliberately recreated, framing the AI-era task as adaptation rather than a wholly new problem. > ## ๐Ÿ“ฐ Newsletter > **AI didn't just change how engineers ship โ€” it changed whether they're still a team.** A LeadDev piece from senior staff engineer James Socol names something a lot of engineering orgs are feeling but haven't articulated: AI lets individuals parallelize work so effectively that teams quietly stop being teams. Using three research-backed markers โ€” shared goals, interdependent work, stability โ€” Socol argues AI erodes all three at once, replacing collaborative unblocking with solo shipping and peer-sourced "stories, battle scars, and lessons" with AI-distilled answers. His fix puts the burden squarely on staff+ engineers: celebrate good behavior loudly, write (and actually use) a team charter, model decision-making out loud. It's a genuinely useful diagnostic โ€” worth reading alongside this vault's ex [![article hero โ€“ leadership](https://res.cloudinary.com/leaddev/image/upload/f_auto/q_auto/dpr_auto/c_limit,h_1536,w_1536/next/2024/10/article-hero-leadership.png)](https://leaddev.com/leadership/staff-engineers-must-rebuild-team-culture)[article hero โ€“ leadership](https://leaddev.com/leadership/staff-engineers-must-rebuild-team-culture) **Key takeaways:** * AI-driven parallel work is eroding what makes a team: **shared goals**, **interdependent work**, and **stability**, leaving engineers shipping more while feeling more isolated. * **Culture forms through everyday collaboration**. When AI replaces peer problem-solving, teams lose the shared experiences that reinforce norms. * **Staff+ engineers must deliberately rebuild** what once happened automatically: celebrating good behavior, writing charters, and modeling collaboration. A year or two ago, the engineering/cross-functional team was a tight-knit, high-performing group. We had one or two goals we all worked on each sprint and we broke down work so that we could operate in parallel. When someone was stuck and needed help, there was always somebody ready to jump to their aid and keep them moving. Team meetings were upbeat, fun, and productive. We were regularly paying down [tech debt](https://leaddev.com/technical-direction/translate-tech-debt-into-business-risk) while our experiments gathered data. The vibe was helpful and collaborative. Now, thanks to [AI](https://leaddev.com/ai/best-ai-coding-assistants), we are shipping more than ever. We have as many goals every sprint as engineers. Rather than parallelizing work on one feature or experiment at a time, we parallelize the experiments. The vibe has shifted. When someone gets stuck, itโ€™s hard to find help. People view meetings as a waste of time โ€“ and honestly, they are. Instead of collaboratively solving a problem, everyone shares a status update while the rest of the group half-listens, knowing the update doesnโ€™t affect them. #### Are we a team or collection of individuals? What distinguishes a team from a collection of individuals? Research over the past 25 years has consistently found a few markers of what makes a team: * Teams have **shared goals**, with collective progress and success โ€“ and failure. If part of the group can succeed while another fails, that indicates a group is not operating as a team. It also creates competitive, rather than collaborative, priorities, since everyone is incentivized to work toward their own goals. With fewer, shared goals, team members are incentivized to work together to achieve them. * Team membersโ€™ work is **interdependent**. Team members often have complementary skills, and rely on each other to make progress toward those shared goals. Even where skills overlap, engineering teams have typically had practices like code reviews that ensured interdependence. * Teams are **stable**. As Richard Dalton, chief design officer at Verizon, once observed: teams are immutable structures. Any change means you have a new team, one that has to go through the stages of [forming-storming-norming-performing](https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development) again. The more stable and clear the team membership, the more time you spend at the performing stage. AI has helped some engineers ship entire features on their own, at a cost of [being more isolated](https://leaddev.com/communication/the-2026-engineer-paradox-more-capable-but-more-alone). Independence may mean less [friction](https://leaddev.com/communication/navigating-engineering-team-friction), but it also means a weaker team bond. That friction often takes the form of communication and collaboration, which are key opportunities to propagate and reinforce team culture. We can think of [culture](https://leaddev.com/culture/cultivating-culture-learning) as โ€œthe way we do things around here.โ€ Itโ€™s built from the behaviors that are celebrated and encouraged, tolerated, and discouraged or prohibited. Those norms are established and reinforced through everyday interactions between team members. A collection of individuals may not have a shared culture โ€“ each may have a different way of doing things. They may value different aspects of the work, and with independent goals, they may not see value in working together or supporting each other at all. Instead of getting answers from each other, with the stories, battle scars, and lessons that came along with them, they get answers distilled by the AI. There are fewer shared experiences. #### How staff+ engineers influence culture As leaders, [staff+ engineers](https://leaddev.com/career-development/how-become-staff-engineer) have an outsized impact on culture. The organization holds us up as examples, and our success within the org encourages others to mirror our behaviors and value our advice. If culture is the way we do things, then we can influence the culture by encouraging or discouraging certain behaviors. Celebrating a choice someone made or an action they took โ€“ whether within the team as a brief shout-out or in broader venues like Slack #kudos channels โ€“ sends a message that we, and so the org as a whole, want to see more of that choice. Sharing stories outside the team, especially if you cover multiple teams and can see the results directly, helps spread and normalize that way of working. If the venues to celebrate the team donโ€™t exist, we can create them. We can create a Slack channel, or to encourage sharing shoutouts during team ceremonies. In a particularly overt example, a previous employer of mine had a company-wide Legend award, that passed from IC to IC, given to someone who exemplified the company values, and was awarded at a company all-hands every two weeks. Another way to create a shared sense of how we work is to write it down in a [team charter](https://leaddev.com/uncategorized/collaborate-effectively-using-power-agreements). Taking the lead on writing a charter or working agreement, while soliciting input and feedback from the team, can not only trigger cultural conversations, but also create a common resource to point back to to help guide decision-making. Itโ€™s important to refer to the charter, and update it as necessary, to avoid it becoming a write-only document. Finally, we can model behaviors. As [leaders within the org](https://leaddev.com/the-engineering-leadership-report-2026/), our team members see the way we act as valued and worth emulating. When we are trying to create a habit of celebrations and shout-outs, we can help by sharing them ourselves. Explaining our decision-making processes lets the team see how to apply the same values and priorities โ€“ to learn how โ€œit dependsโ€ looks in practice. ![LDX3 New York is live](https://res.cloudinary.com/leaddev/image/upload/f_auto/q_auto/dpr_auto/next/2026/03/LDX3-New-York-is-live.png)LDX3 New York is live **New York โ€ข September 15 & 16, 2026** The pace of change keeps accelerating. See what other leaders are doing about it, at LDX3 New York. [AI is driving a shift](https://leaddev.com/ai/your-ai-coding-tools-buying-checklist-for-2026) to more autonomous work within teams, which means opportunities to establish culture that used to be automatic โ€“ time spent pairing, organizing work around shared goals, planning and designing together โ€“ now require deliberate choices. We went through a similar shift with the rapid increase in [remote work](https://leaddev.com/culture/engineering-teams-work-better-remote-first), when interactions that had been part of being in a shared space required creative replacements. The good news is that, as [staff+ engineers](https://leaddev.com/leadership/derisking-the-big-decisions-a-playbook-for-staff-engineers), we already need to [be the glue](https://www.noidea.dog/glue) within and across our teams. We can use that time โ€“ communicating, documenting, planning, sharing, reviewing โ€“ to establish and reinforce the way the team does things. With clear, high-performance goals in mind, we can intentionally seek and create the opportunities we need to build the habits and norms that shape the team culture., Staff+ Engineers Must Rebuild Team Culture, James Socol, 01m0apw7kevmfx7fx08429stjq.