Here's a truth that might sting: the title "Senior Engineer" has been quietly devalued.
Three years ago, a senior developer who could ship features independently, review PRs thoughtfully, and mentor a junior or two was doing fine. Today, an AI agent can generate that same code in minutes. It can write tests. It can even explain its own pull requests.
So where does that leave you?
If you're a mid-level engineer with 3-6 years of experience, you're probably aiming at "Senior" as your next milestone. I'm here to tell you to raise your sights. The new benchmark is Staff Engineerand that's where your irreplaceable value actually lives.
This isn't gatekeeping. It's the reality of what engineering organizations now need. When AI handles syntax, boilerplate, and velocity, humans must own judgment, architecture, and cross-organizational influence.
I've spent years building systems at scale, mentoring engineers through this transition, and watching what actually separates those who break through from those who plateau. What follows are the 15 competencies that define Staff+ engineersorganized into four pillars that build on each other.
None of this is optional anymore.
The Shift You Need to Understand
Before we get into the competencies, let's be clear about what changed.
AI agents are now peers in your codebase. They commit code. They modify logic. They do it fast. And they don't get tired.
This means the old markers of senioritywriting code quickly, knowing the syntax, having patterns memorizedare now table stakes. Worse, they're commoditized.
What AI cannot do:
- Make judgment calls that balance business constraints, technical debt, and team capacity
- Design systems that will survive five years of evolving requirements and hundreds of contributors
- Build consensus across teams that don't report to you
- Know when to reject a "best practice" because it doesn't fit your context
That's the Staff+ layer. That's what you need to own.
Pillar 1: Foundations That Scale
You might think you "already know" SOLID principles or clean code. Most mid-level engineers do. But there's a difference between knowing these concepts and enforcing them at organizational scale.
1. SOLID + GRASP True Responsibility Assignment
At Staff+ level, you don't just apply SOLID principles to your code. You define responsibility boundaries that remain clear across millions of lines of code and hundreds of contributorsincluding AI agents that inject new logic constantly.
The nine GRASP patterns (Creator, Information Expert, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations) become instinct, not theory. You use them to audit team architectures and prevent responsibility leakage before it metastasizes.
The bar: You can walk into any team's codebase and identify where responsibility boundaries have eroded. You can propose fixes that the team actually adopts.
2. Object Calisthenics + Clean Code No Exceptions
Jeff Bay's Object Calisthenics rules might seem extreme: one level of indentation per method, no else keywords, wrap all primitives. But at scale, these constraints create codebases that remain readable as they grow.
Staff+ engineers enforce these standards especially on AI-generated code. You build automated linting pipelines that catch violations before they merge. You set code-quality SLAs that the entire organization follows.
The AI doesn't know when it's creating unmaintainable trash. You do.
The bar: You've established coding standards that apply org-wide. You've built automation to enforce them. Teams you've never talked to are following your guidelines.
3. GoF Patterns Knowing When to Reject Them
The 23 Gang of Four patterns are tools, not gospel. At Staff+ level, you know every pattern deeply enough to recognize when it adds accidental complexity rather than genuine value.
More importantly, you can achieve the intent of a pattern using modern language features instead of cargo-culting the classic implementation. You don't need a Strategy class hierarchy when a lambda will do.
You mentor other engineers to ask "what problem does this pattern solve?" before reaching for it. And you create org-wide guidance on when patterns should be rejected.
The bar: You can review a PR that adds a Singleton or Factory and articulate exactly why it's overkillor exactly why it's necessary. Your reasoning convinces the author.
4. DRY, KISS, YAGNI With Precision, Not Dogma
These principles sound simple until you've watched a team paralyze itself trying to eliminate every line of duplication. Or ship a "simple" solution that collapsed under real load.
Staff+ engineers apply these with extreme precision. You know when controlled duplication actually serves maintainability. You know when KISS means "simple to understand" versus "simple to write." You reject YAGNI as an excuse for lazy design.
You create decision rubrics that other engineers use. You audit systems for dogmatic over-application.
The bar: You've intentionally duplicated code and can explain why it was the right call. You've rejected a "simpler" solution because it traded simplicity now for pain later.
Pillar 2: Architecture That Survives
Architecture isn't about drawing boxes. It's about designing systems that outlive teams, survive hundreds of contributors and AI agents, and scale without collapsing under their own weight.
5. Domain-Driven Design Strategic, Not Tactical
Most engineers who "know DDD" know the tactical patterns: Entities, Value Objects, Repositories. Staff+ engineers operate at the strategic level.
You define Bounded Contexts and maintain sophisticated Context Maps across multiple business domains. You classify domains as Core, Supporting, or Genericand you fight to keep AI and outsourced development out of Core.
You establish Ubiquitous Language that bridges engineering and business. Not in a wiki that nobody reads, but in actual conversations, code, and documentation that shapes how people think.
The bar: You can draw the Context Map for your organization. You know which contexts are Core and can explain why. Business stakeholders recognize the language you've established.
6. Hexagonal / Clean Architecture Pluggable by Default
Ports and Adapters (Hexagonal), Onion, Clean Architecturethe specific flavor matters less than the principle: the domain is isolated from infrastructure.
At Staff+ level, you enforce this as the default org pattern. You guarantee that AI agents, databases, APIs, and message queues can be swapped without touching business logic. You design for independent testing and replacement of every layer.
You create reference implementations that other teams copy. You lead migrations when legacy systems violate these boundaries.
The bar: You can replace a database or add an AI agent to a system you designed without modifying the domain layer. You've done this in production.
7. Event-Driven + CQRS + Event Sourcing + Saga Patterns
When you operate at enterprise scale, request-response breaks down. Staff+ engineers architect with events, commands, and queries as first-class citizens.
You design systems that handle out-of-order events, guarantee idempotency, and support temporal queries. You choose between orchestration and choreography sagas based on the coupling trade-offs of your specific context.
You make these patterns org defaults with clear guidance on when simpler approaches suffice.
The bar: You've implemented Event Sourcing with full replay capability. You've designed a saga that compensates across multiple services when a step fails. You know when CQRS is overkill.
8. Deep Algorithms & Data Structures at Scale
B-trees, LSM-trees, skip lists, bloom filters, CRDTsthese aren't academic trivia. They're the building blocks of systems that serve millions of users at sub-millisecond latency.
Staff+ engineers maintain expert command of advanced data structures and algorithms across graph, string, numerical, and distributed domains. You make data-driven trade-offs between compute, memory, storage, and developer velocity.
You don't just implementyou choose. And your choices directly impact billions of requests and significant infrastructure cost.
The bar: You've selected a data structure based on big-O analysis of your specific access patterns. You can explain the trade-offs in bloom filter parameters. You've optimized a hot path that moved the needle on infrastructure cost.
Pillar 3: Systems That Self-Heal
Production systems don't fail gracefully by accident. Staff+ engineers design for failure, observe everything, and build platforms that recover without human intervention.
9. Distributed Systems Mastery
CAP theorem isn't a slide in a presentationit's a constraint you navigate daily. Staff+ engineers command consensus algorithms (Raft, Paxos, Zab), sharding strategies, replication topologies, and every consistency model from strong to eventual to causal to linearizable.
You design systems that predictably survive network partitions, latency spikes, and node failures. You define org-wide resilience standards that all teams follow.
When an incident happens, you lead the post-mortem. And your recommendations get implemented.
The bar: You can explain why you chose eventual consistency for a specific service and what you did to handle the edge cases. You've designed a sharding strategy. You've survived a major outage because your design anticipated it.
10. Observability & Resilience
OpenTelemetry (traces, metrics, logs, baggage) isn't optionalit's a first-class architectural concern. Staff+ engineers implement full-stack observability at platform scale.
You set SLOs that mean something. You spend error budgets strategically. You run chaos engineering experiments that reveal failure modes before production does.
Your systems self-recover. On-call doesn't mean getting pagedit means watching the system heal itself while you stay informed.
The bar: You've implemented distributed tracing that let you diagnose a production issue in minutes. You've defined SLOs that product and engineering both use. You've run a chaos experiment that found a real bug.
11. Secure-by-Design + Zero-Trust
Security isn't a checkboxit's embedded in every architectural layer. Staff+ engineers design with least privilege, zero-trust networking, immutable infrastructure, and continuous threat modeling.
You assume breach by defaultincluding breach of your AI agents. Every component authenticates, authorizes, and validates. Defense in depth isn't a buzzword; it's how your systems are built.
You define and enforce org-wide secure architecture standards. You lead security reviews for critical components.
The bar: You've threat-modeled a system before building it. You can explain your organization's trust boundaries. You've caught a security issue in architecture review that would have been expensive to fix later.
12. Agent Reliability Engineering
This is the new competencyand it's non-negotiable.
AI agents are probabilistic. They hallucinate. They generate code that compiles but subtly violates invariants. Staff+ engineers build deterministic guardrails around this chaos.
You design verification pipelines, human-in-the-loop gates, and automated rollback mechanisms. You treat AI-generated code with the same (or higher) rigor as human code: static analysis, property-based testing, formal verification where it matters.
You establish Agent Reliability Engineering as an org-wide practice. You're the person who says "that AI-generated PR looks fine but breaks our idempotency guarantees" and can prove it.
The bar: You've built a pipeline that validates AI-generated code before it can merge. You've caught AI output that passed tests but violated a business invariant. You've defined guardrails that other teams now use.
Pillar 4: Leadership Without a Title
Staff+ engineers don't need direct reports to shape technical direction. Their influence scales beyond their team through artifacts, alignment, and judgment.
13. Systems Thinking & Trade-off Mastery
Every decision is multi-dimensional: cost (FinOps, token economics), political (stakeholder alignment), reliability, and AI-specific constraints (latency vs. accuracy, determinism vs. creativity).
Staff+ engineers see the whole system. You make optimal holistic trade-offs for the businessnot just locally optimal technical choices. You teach other engineers to navigate these dimensions.
You drive executive-level technical recommendations. Your analysis shapes strategy.
The bar: You've made a technical decision that explicitly traded off political capital. You can explain how your organization's incentives affect architectural choices. You've changed an executive's mind with data.
14. Leadership Without Authority
RFCs. Architecture Decision Records. Design reviews. Lunch conversations. This is how Staff+ engineers drive technical direction.
You influence autonomous teams that don't report to you. You build consensus across business units. You translate executive strategy into concrete technical vision.
You establish and maintain org-wide engineering guardrails. Not because you have authority, but because you've earned trust.
The bar: You've written an RFC that changed how multiple teams build systems. You've built consensus on a contentious technical decision without escalating. You've shaped an engineering standard that outlived your involvement.
15. Humans Own Judgment; AI Owns Velocity
This is the mental model that ties everything together.
AI agents are your force multipliers for syntax, boilerplate, and routine implementation. You orchestrate them. You leverage their speed. But you retain absolute ownership of system design, architectural decisions, strategic direction, and final quality gates.
The judgment layer is irreplaceable. That's you.
You define how your organization collaborates with AI. You set the standards for human-AI workflows at enterprise scale.
The bar: You can articulate exactly which decisions AI accelerates and which require human judgment in your domain. You've designed a workflow that multiplies your team's output by using AI strategically. You've said "no" to AI-generated output when it mattered.
What To Do This Week
Reading about competencies doesn't build them. Here's one action for each pillar:
Foundations: Pick up a codebase you didn't write. Find three places where SOLID or GRASP principles are violated. Write down what you'd change and why. Don't actually change itjust practice seeing it.
Architecture: Draw the Context Map for one system you work on. Identify the Bounded Contexts. Find where context boundaries are leaking. Share it with one person.
Systems: Add one meaningful trace span to a request path you care about. Or define one SLO for a service you own. Make it something you'll actually look at.
Leadership: Write down a technical decision you disagree with in your org. Draft (but don't send) an RFC that proposes an alternative. Practice making the argument.
The Uncomfortable Truth
Most mid-level engineers plateau because they optimize for "good enough."
They hit senior title and coast. They do solid work within their team. They don't cause problems. And they wonder why Staff seems unreachable.
Staff+ requires owning outcomes beyond your ticket. It requires seeing systems where others see components. It requires influence where others see hierarchy.
The 15 competencies in this post aren't a checklist to complete. They're a bar to clear. And the bar rises every year as AI agents get better at everything below it.
The path is hard. But the alternativewatching your value erode as AI handles more of what you used to dois worse.
Start now.
Go Deeper
The competencies in this post draw from foundational texts. If you want to go deep:
- Foundations: Clean Code and Clean Architecture by Robert C. Martin. The Pragmatic Programmer by Hunt and Thomas.
- Architecture: Domain-Driven Design by Eric Evans. Designing Data-Intensive Applications by Martin Kleppmann.
- Systems: OpenTelemetry official documentation. NIST SP 800-207 on Zero Trust Architecture.
- Leadership: Staff Engineer: Leadership Beyond the Management Track by Will Larson. Thinking in Systems by Donella Meadows.
The bar has been raised. These 15 competencies are how you clear it.
What competency are you working on right now? Drop a commentI'll respond to every one.
Top comments (0)