Do Staff Engineers Code? with Nicky Wrightson—Software Development Superstream 🔗 **Source:** [Do Staff Engineers Code? with Nicky Wrightson—Software Development Superstream](https://www.youtube.com/watch?v=7LsAJt_4ssY) > [!note]+ Document Notes > tags: [staff-engineering, career-development, leadership, coding-practice] > author: [MISSING] > source: YouTube > reference: [https://www.youtube.com/watch?v=7LsAJt_4ssY] > date created: > > # 🏷️ Title: Do Staff Engineers Code? with Nicky Wrightson—Software Development Superstream > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Draft a staff IC ladder section on coding—context/https://www.youtube.com/watch?v=7LsAJt_4ssY #articleseed - [H2] Add “snowplow” unblocking patterns to playbook—context/https://www.youtube.com/watch?v=7LsAJt_4ssY&t=44 #xref - [H3] Measure Slack/IDE balance for staff ICs—context/https://www.youtube.com/watch?v=7LsAJt_4ssY&t=33 #articleseed - [H6] Include “feel the pain” check in rubrics—context/https://www.youtube.com/watch?v=7LsAJt_4ssY&t=97 #addendum - [H7] Write architect-vs-staff empathy guide—context/https://www.youtube.com/watch?v=7LsAJt_4ssY&t=111 #articleseed - [H8] Clarify on-call expectations for principals—context/https://www.youtube.com/watch?v=7LsAJt_4ssY&t=126 #xref - [H4] Capture “novel problem swarm-in” SOP—context/https://www.youtube.com/watch?v=7LsAJt_4ssY&t=68 #share - [H2] Use “snowplow” as a worldbuilding motif—context/https://www.youtube.com/watch?v=7LsAJt_4ssY&t=44 #bmf ## 🧭 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 - Include links cited in or relevant to the article. ## 📝 Summary - The talk addresses staff IC coding expectations. - It argues staff ICs still code, but differently. - Stakeholders include engineers, leads, and HR. - Risks include role confusion and skill atrophy. - Bottom line: Staff engineers code to unblock, de-risk, and teach. ## 📖 Main Content - Staff engineers code, but not always on the critical path. - They do proofs of concept (PoCs) and spikes to reduce risk. - They unblock teams and scout ahead like a snowplow. - They drop into novel, hard problems as senior hands. - They balance Slack time and IDE time intentionally. - They stay on-call to remain accountable for shipped code. - “Spike” means a time-boxed exploration in Agile practice. [Wikipedia](https://en.wikipedia.org/wiki/Spike_(software_development)) - PoC tests feasibility quickly with minimal scope. [Wikipedia](https://en.wikipedia.org/wiki/Proof_of_concept) - On-call rotas enforce operational empathy and readiness. [PagerDuty](https://www.pagerduty.com/resources/learn/what-is-on-call-scheduling/) - Staff archetypes frame responsibilities and focus. [StaffEng](https://staffeng.com/guides/staff-archetypes/) - Uncertainties: Varies by org size, product risk, and culture. - Tradeoffs: Less feature throughput, more leverage through unblockers. ### 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=0) Question about coding at staff level ### [H1] Staff engineers continue writing code regularly > [!quote] [YouTube](https://www.youtube.com/watch?v=7LsAJt_4ssY) by [an unnamed author] via [[YouTube]]. Published [MISSING]. Accessed . > “you you're definitely going to be still coding.” Staff coding persists, but the focus shifts. [view highlight](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=83) #xref #articleseed ID:rw_[MISSING] #### ⏱️ [00:00:33](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=33) Communication balance ### [H3] Staff balance Slack time with IDE time > [!quote] [YouTube](https://www.youtube.com/watch?v=7LsAJt_4ssY) > “you might be using Slack as much as your IDE” This balance reflects coordination demands. [view highlight](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=36) #xref ID:rw_[MISSING] #### ⏱️ [00:00:44](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=44) Unblocking and derisking ### [H2] Staff code focuses on PoCs, spikes, and unblocking > [!quote] [YouTube](https://www.youtube.com/watch?v=7LsAJt_4ssY) > “unblocking people, acting as a bit of a snowplow ahead of things.” Staff build leverage through early technical scouting. [view highlight](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=46) #articleseed ID:rw_[MISSING] #### ⏱️ [00:01:08](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=68) Novel, complex problems ### [H4] Staff swarm into unprecedented problems directly > [!quote] [YouTube](https://www.youtube.com/watch?v=7LsAJt_4ssY) > “really complex not seen before in the company problem… jump into the team” Staff operate as force multipliers during uncertainty. [view highlight](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=70) #share #xref ID:rw_[MISSING] #### ⏱️ [00:01:23](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=83) Leaders still code ### [H5] Senior leaders sometimes merge small changes thoughtfully > [!quote] [YouTube](https://www.youtube.com/watch?v=7LsAJt_4ssY) > “I even I sneak in the odd line of code even as a as a VP of engineering.” Leadership coding should avoid stepping on teams. [view highlight](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=86) #xref ID:rw_[MISSING] #### ⏱️ [00:01:37](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=97) Stay close to pain ### [H6] Hands-on work preserves operational empathy > [!quote] [YouTube](https://www.youtube.com/watch?v=7LsAJt_4ssY) > “you should be still keeping your fingers in the code.” This guards against process drift and stale intuition. [view highlight](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=99) #addendum ID:rw_[MISSING] #### ⏱️ [00:01:51](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=111) Architect risk ### [H7] Drifting away risks ivory-tower architect behavior > [!quote] [YouTube](https://www.youtube.com/watch?v=7LsAJt_4ssY) > “you've effectively accidentally flipped into more of the … expectations we used to have from architects” Keep skin in the game to avoid abstraction-only advice. [view highlight](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=114) #articleseed ID:rw_[MISSING] #### ⏱️ [00:02:06](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=126) On-call accountability ### [H8] On-call duty implies active code ownership > [!quote] [YouTube](https://www.youtube.com/watch?v=7LsAJt_4ssY) > “Whenever I was principal engineer, I was on the out of hours rotor.” Operational work cements responsibility and feedback loops. [view highlight](https://www.youtube.com/watch?v=7LsAJt_4ssY&t=128) #xref ID:rw_[MISSING] ## 📚 References - [Talk video: Do Staff Engineers Code?](https://www.youtube.com/watch?v=7LsAJt_4ssY) - [Spike (software development)](https://en.wikipedia.org/wiki/Spike_(software_development)) - [Proof of concept](https://en.wikipedia.org/wiki/Proof_of_concept) - [What is on-call scheduling?](https://www.pagerduty.com/resources/learn/what-is-on-call-scheduling/) - [Staff Engineer archetypes](https://staffeng.com/guides/staff-archetypes/) ## 🗣️ Paraphrase - The staff engineer codes, but targets leverage and risk reduction. - The role mixes coordination, advising, and tactical problem swarming. ## 📰 Newsletter - Staff ICs at scale still write code, just differently. - Expect PoCs, spikes, and rescue missions for hairy systems. - Balance Slack and IDE with intent, not by accident. - On-call keeps empathy sharp and designs grounded. - WordPress folks: think Core backlogs, performance spikes, and Playground labs. - Watch the talk here. [YouTube](https://www.youtube.com/watch?v=7LsAJt_4ssY) ## ✅ Action Items #### DevRel - Publish a staff IC coding rubric and examples. - Run a “spike week” workshop on de-risking techniques. - Add unblocking demos to docs and quickstarts. - Map comms channels to engineering workflows. - Survey staff IC time allocation quarterly. #### OSPO - Define staff IC expectations in contribution policy. - Document PoC governance and licensing reviews. - Add on-call guidance for upstream maintainers. - Track SBOM ownership for staff-led spikes. - Establish intake for “novel problem” swarms. - Report leverage metrics to executives. #### Community - Hold roadmap clinics on de-risking releases. - Pair new contributors with staff for spikes. - Publish transparent sponsor milestones and impact. - Run incident drills with cross-project comms. #### WordPress - Core: formalize “risk spike” issue type and SLA. - Core Performance: schedule profiling PoCs each cycle. - Core AI: create evaluation sets and review gates. - **Core Program Team:** add unblocker rotations and retros. - Mobile: create on-call playbooks and checklists. - Playground: teach reproducible bug labs for spikes. - Community: expand speaker mentorship on staff IC paths. - Training: add staff IC scenarios to curricula. - Marketing: explain leverage stories, not heroics. - Support: codify escalation paths and SLAs. - Design: include operations feedback in research. - Documentation: add examples-first patterns for spikes. - Meta: expose API reliability dashboards. - Polyglots: plan translation sprints for on-call notices. - Accessibility: schedule WCAG audits per release. - Themes/Plugins: add provenance and review liaisons. - Hosting: align telemetry and error budgets across hosts. - Tide: publish scoring transparency and review loops. - Openverse: document ingestion spikes and rollbacks. - CLI: add plugin scaffolds and smoke tests. #### The WPOCC - Fund maintainer stipends tied to de-risking work. - Pilot microgrants for PoCs and release unblocking. - Run governance clinics on staff IC expectations. ### FAIR - Encode covenants for funding transparency. - Provide signature checks and provenance policies. - Publish operator agreements and scorecards. ## 🧪 Hypotheses - Staff IC coding time correlates with lower incident rates. - Spikes reduce cycle time for risky features. - On-call duty increases system reliability over time. - Slack/IDE balance predicts mentoring impact. ### 📊 Methodology - Analyze incident metrics before and after adding spikes. - Compare cycle times with and without PoCs. - Survey staff IC time allocation and outcomes. - Track pager load against ownership and fix rates. ### ❓ Questions - How much coding preserves empathy without bottlenecks? - Which archetypes best fit WordPress core needs? - What guardrails prevent leader “drive-by” commits? ### 🔮 Future Research - Study staff IC paths in distributed OSS projects. - Validate spike ROI using multi-release experiments. - Model pager fatigue and mitigation strategies. ### 💡 Implications - Practice: schedule regular de-risking spikes. - Policy: write explicit staff expectations and ladders. - Security: align on-call with embargo policies. - Education: train mentors in unblocking tactics. - Funding: tie grants to leverage, not lines of code. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch–Kincaid Grade ≈ 9–10. #### 👀 Visual learners - Present: timestamped links and structured sections. - Improve: add flow diagrams for unblocking paths. #### 🔊 Aural learners - Present: linked talk with narration. - Improve: add a 3-minute audio summary. #### 🗣️ Verbal learners - Present: definitions and short explanations. - Improve: add glossary of staff IC terms. #### 🧩 Kinesthetic learners - Present: suggested spike and PoC exercises. - Improve: add playground labs for practice. #### 🧠 Logical learners - Present: hypotheses and methodology plans. - Improve: add decision trees and RACIs. #### 🧑🤝🧑 Social learners - Present: mentorship and pairing suggestions. - Improve: cohort guides and peer reviews. #### 🧘‍♀️ Solitary learners - Present: reflection prompts in questions. - Improve: self-check quizzes and journals. #### 🌿 Naturalistic learners - Present: ecosystem analogies like “snowplow.” - Improve: lifecycle thinking across releases. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: clear headings and landmarks. - Improve: add alt text for diagrams. #### Keyboard navigation - Present: logical order and visible focus. - Improve: add skip links and avoid traps. #### Contrast and readability - Present: readable text and spacing. - Improve: verify 4.5:1 contrast on visuals. #### Text resizing and reflow - Present: responsive layout guidance. - Improve: support reduced motion preferences. #### Media and captions - Present: video captions available on YouTube. - Improve: offer downloadable transcripts. #### Forms and interactions - Present: process checklists are scannable. - Improve: add inline validation patterns. #### Standards reference - Map gaps to WCAG 2.2 AA criteria. ### 🌍 DEIB Assessment #### Cultural breadth - Present: broad practices suitable across teams. - Improve: add non-US case studies. #### Inclusive language - Present: plain language and defined terms. - Improve: expand glossary for newcomers. #### Neurodiversity support - Present: chunked content and predictable structure. - Improve: consistent icon+text labels. #### Representation - Present: varied engineering roles referenced. - Improve: include diverse speaker examples. #### Psychological safety - Present: respectful framing of expectations. - Improve: publish moderated Q&A protocols. ### ✅ Logical Validity #### Strong reasoning - Inductive link between coding and empathy [H6]. - Causal claim: spikes reduce risk [H2]. - Analogical “snowplow” aids clarity [H2]. #### Fallacies - Potential hasty generalization from one org [H8]. - Fix by scoping: “in similar contexts” language. #### Tone of voice - Practical, candid, and experience-driven. ### 🛡️ DARVO Analysis - Deny: none evident. - Attack: none evident. - Reverse victim/offender: none present. - The rhetoric stays constructive and instructive. ## 🎯 Conclusion - Staff ICs code to create leverage, not volume. - Write ladders, schedule spikes, and keep pagers honest. ## 🔖 Zettel Candidates - **Staff engineers continue writing code regularly.** Useful for ladder drafts. [H1](#h1-staff-engineers-continue-writing-code-regularly) - **Staff code focuses on PoCs, spikes, and unblocking.** Training module seed. [H2](#h2-staff-code-focuses-on-pocs-spikes-and-unblocking) - **Staff balance Slack time with IDE time.** Time study idea. [H3](#h3-staff-balance-slack-time-with-ide-time) - **Staff swarm into unprecedented problems directly.** Incident response note. [H4](#h4-staff-swarm-into-unprecedented-problems-directly) - **Senior leaders sometimes merge small changes thoughtfully.** Guardrail memo. [H5](#h5-senior-leaders-sometimes-merge-small-changes-thoughtfully) - **Hands-on work preserves operational empathy.** Rubric pointer. [H6](#h6-hands-on-work-preserves-operational-empathy) - **Drifting away risks ivory-tower architect behavior.** Anti-pattern log. [H7](#h7-drifting-away-risks-ivory-tower-architect-behavior) - **On-call duty implies active code ownership.** Reliability practice. [H8](#h8-on-call-duty-implies-active-code-ownership) ## 🏷️ Tag Coverage #articleseed: 3 • #xref: 4 • #share: 1 • #bmf: 1 • #addendum: 1 ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [Do Staff Engineers Code?](https://www.youtube.com/watch?v=7LsAJt_4ssY) by [an unnamed author] via [[YouTube]]. Published [MISSING]. Accessed . > “Short quote, verbatim, ≤25 words.” Two lines: context and use. Cite data if relevant. [view highlight](https://www.youtube.com/watch?v=7LsAJt_4ssY#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [Do Staff Engineers Code?](https://www.youtube.com/watch?v=7LsAJt_4ssY) > “Short quote, verbatim, ≤25 words.” Two lines: context and use. [view highlight](https://www.youtube.com/watch?v=7LsAJt_4ssY#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] #### [Z2] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Short action — context/https://www.youtube.com/watch?v=7LsAJt_4ssY #fleeting #inbox - [F2] Short action — context/https://www.youtube.com/watch?v=7LsAJt_4ssY #fleeting #inbox - [F3] Short action — context/https://www.youtube.com/watch?v=7LsAJt_4ssY #fleeting #inbox --- <!-- deep-read:sections end --> ## 📺 Video ![](https://www.youtube.com/watch?v=7LsAJt_4ssY) --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=7LsAJt_4ssY)* **[00:00]** We've had a couple of people kind of ask this question in different ways and I think you know some so but HR I think sums it up sums the concern up quite well. HR says I want to progress towards becoming a staff engineer in my career but on the other hand I want to code dayto-day. I feel that if I move staff engineer I won't be coding anymore. What what would you say to that? No no I there is different archetypes. There are people that are completely deeply **[00:31]** technical. Um, don't get me wrong though, you might be using Slack as much as your IDE, but you're still going to be doing the code, but it's not maybe on the critical path. You may be unblocking people, acting as a bit of a snowplow ahead of things. you know, going off and doing a quick proof of concept, bring it back to the teams going, look what I learned out of this or or seeing that you can see this ugly thing coming up and you want to derisk it for the team by doing a couple of spikes. That's the kind of coding that tends to fall into **[01:02]** this this area. or if it's a completely really complex not seen before in the company problem, you will probably actually just jump into the team, behave like a senior engineer, unblock the team and disappear off. So you you're definitely going to be still coding. I even I sneak in the odd line of code even as a as a VP of engineering. Don't tell my team this. They probably won't agree with me doing that, but yeah. Um, **[01:34]** I think uh on the IC track on the principal all the way up the the ladder, you should be still keeping your fingers in the code. If you don't feel put your fingers in the code and actually feel the pain of being an engineer and what what what the barriers are to doing a good job there, you know, you you've effectively accidentally flipped into more of the um expectations we used to have from architects that they would come in and talk to you about things rather than um **[02:04]** uh support code in the live environment. Whenever I was principal engineer, I was on the uh out of hours rotor. So that's how much code you have to push to be confident enough to answer that phone call at 3:00 in the morning.