Staff Engineering Skills

Summary

A working map of 19 skills for staff-level engineering, grouped into four areas: choosing direction, delivering sound technical change, making collective work effective, and making outcomes last. It starts from a base list of 15 broadly valuable skills, translated into engineering practice, and adds four capabilities the role depends on: verification, delivery planning, technical communication, and developing other owners. Each skill comes with a concrete way to practise it.

Background

The starting point was a list of 15 broadly valuable human skills. All 15 apply to staff engineering, so the note keeps all of them. Each one is restated in engineering terms, and four capabilities that a staff engineer depends on are added.

One item needed reframing. Institutional creation becomes creating durable engineering structures, such as ownership models and decision processes. How much it matters depends on your scope.

A note on the evidence

The original list came with forecasts of how long each skill would stay a human advantage. Those percentages are left out on purpose. The research supports these skills being useful, but it does not show that humans will keep a long-term advantage over AI in them.

Overview

Group	Focus	Skills
1. Choose worthwhile problems and direction	Deciding what is worth doing and why	1-5
2. Understand systems, establish evidence, and deliver changes	Getting the technical substance right and shipping it	6-10
3. Make collective engineering work effective	Working through and with other people	11-17
4. Make outcomes and improvements last	Following through and leaving durable structures behind	18-19

1. Choose worthwhile problems and direction

Skill	What it means in staff engineering	How to develop it
1. Objective setting and prioritisation	Decide which outcomes deserve investment, what success means, and which constraints must hold.	Write a brief explaining the desired outcome, success measures, alternatives, and why this work deserves attention now.
2. Problem discovery	Find overlooked user pain, operational risks, wasted effort, and opportunities that have not reached the backlog.	Observe users or operators doing real work. Investigate a recurring workaround and establish its actual cost or consequence.
3. Problem reframing	Recognise when the stated problem is a symptom, an unnecessary constraint, or an assumed solution.	For a stalled initiative, write two alternative problem definitions. Gather evidence to determine which leads to a more useful intervention.
4. Judgment under uncertainty	Make consequential decisions when evidence is incomplete and reliable probabilities are unavailable.	Compare plausible scenarios, downside, reversibility, and the cost of waiting. Record what evidence would make you change course.
5. Technical taste and discernment	Recognise designs that are coherent, understandable, maintainable, and appropriate to their purpose.	Compare competing designs using explicit quality criteria. Explain which complexity you would remove, which you would accept, and why.

These five break the broad capability of “problem framing and prioritisation” into distinct practices. Will Larson’s guide to writing engineering strategy makes the same connection between concrete problems, alternatives, tradeoffs, and explicit rationale.¹

2. Understand systems, establish evidence, and deliver changes

Skill	What it means in staff engineering	How to develop it
6. Systems thinking and architecture	Design boundaries and interactions while accounting for data, failure modes, ownership, incentives, and downstream consequences.	Trace a proposed change across the system and its teams. Identify hidden assumptions before choosing interfaces and responsibilities.
7. First-principles reasoning	Separate genuine constraints from inherited conventions, then reconstruct the reasoning behind a solution.	Revisit one important design choice from its requirements, technical limits, and costs. Check whether the existing pattern still fits.
8. Empirical investigation and experimentation	Create useful knowledge through debugging, measurement, observation, and experiments.	Write competing hypotheses for a real problem, choose a test that distinguishes them, and update your explanation from the result.
9. Verification and risk assessment	Determine what must be true and what evidence justifies accepting a change.	For a consequential change, list required properties, supporting checks, and remaining uncertainty. Strengthen the weakest important check.
10. Migration and delivery planning	Turn a design into a completed transition, including compatibility, rollout, recovery, adoption, and retirement.	Break a migration into verifiable stages. Give each stage acceptance criteria, an owner, and a recovery path; define when the old system disappears.

Technical depth underpins this whole group

You need enough understanding of the implementation, your domain, and operational behaviour to challenge explanations and test predictions. Architecture, investigation, verification, and release engineering each have their own established foundations. Broad reasoning skills do not replace them.

Architectural mismatch is a good example of what that depth catches. Garlan, Allen, and Ockerbloom found that reused components often fail to fit together because each one makes implicit, conflicting assumptions about the system around it.²

3. Make collective engineering work effective

Skill	What it means in staff engineering	How to develop it
11. Contextual and organisational understanding	Understand the history, incentives, informal dependencies, and constraints behind what people say and do.	Before proposing a change, ask affected teams what previous attempts encountered and what would make adoption difficult. Check your interpretation with them.
12. Clear technical communication	Make intent, tradeoffs, system behaviour, and decision rationale understandable enough for others to act.	Explain a real decision through a short document, diagram, or example. Ask an unfamiliar colleague to use it to answer a practical change question.
13. Cross-team coordination	Make interdependent work fit together through clear ownership, sequencing, interfaces, and commitments.	Map one initiative’s dependencies and resolve its largest ownership or sequencing gap. Check whether blocked work resumes.
14. Trust and relationship building	Establish credibility through reliable follow-through, candour, sound judgment, and understanding others’ concerns.	Make explicit commitments, communicate risks early, acknowledge mistakes, and close the loop with the people affected.
15. Negotiation and coalition building	Reach workable agreements when teams have different priorities, costs, or incentives.	Identify each party’s needs and constraints. Develop options that distribute costs fairly, then secure explicit commitments from the people needed to execute.
16. Technical leadership and commitment	Give people a credible direction and sustain coordinated action while uncertainty remains.	Lead a bounded initiative with a clear purpose, near-term commitments, and review points. Revise the plan when evidence changes.
17. Delegation and developing independent owners	Expand the number of people who can make sound decisions and own consequential work.	Transfer a bounded responsibility with context, authority, and escalation boundaries. Assess whether the new owner can handle an unfamiliar variation independently.

Accounts of staff roles, along with research on coordination and onboarding, support treating these as separate contributions rather than one general “people skill”.³ Key distinctions below sets out how they differ.

4. Make outcomes and improvements last

Skill	What it means in staff engineering	How to develop it
18. Accountability and ownership	Follow consequential work through to its actual outcome, including operation, mistakes, and corrective action.	Define what you own and how success will be checked after launch. Review the result and close unresolved consequences instead of treating release as completion.
19. Creating effective engineering structures	Establish durable ownership, standards, decision rights, working groups, or collaboration arrangements where existing structures fail.	Address one recurring gap with the smallest workable arrangement. Give it a purpose, owner, and review date; keep it only if it improves outcomes.

Skill 19 is the staff-engineering form of institutional creation. It matters most when recurring problems require changes to how engineering operates. Creating new organisations or markets is not a general staff requirement. Will Larson’s guide to managing technical quality includes creating teams and quality programmes, and warns against introducing process too early.⁴

Key distinctions

Several of these skills sound alike but do different jobs:

Communication creates understanding.
Coordination connects work.
Negotiation changes commitments.
Trust supports cooperation.
Leadership supplies direction.
Delegation increases independent ownership.

How to use this list

Use it as a development menu, not a checklist

Judge improvement by the result, not by how many skills you can claim.

Pick the skill connected to a recurring, consequential problem in your current work.
Practise it on that problem, using the “How to develop it” column as a starting point.
Review the outcome, then pick the next skill the same way.

References

Will Larson, “Writing engineering strategy”, StaffEng. https://staffeng.com/guides/engineering-strategy/

David Garlan, Robert Allen, and John Ockerbloom, “Architectural Mismatch: Why Reuse Is So Hard”, IEEE Software, 1995. https://ics.uci.edu/~taylor/ICS221/papers/ArchMismatch.pdf

Will Larson, “Staff archetypes”, StaffEng. https://staffeng.com/guides/staff-archetypes/

⁴

Will Larson, “Manage technical quality”, StaffEng. https://staffeng.com/guides/manage-technical-quality/