Estimated reading time: 7 minutes
Key takeaways:
- Staff engineering is horizontal, not vertical. The shift from senior to staff is about going wide across teams and getting people who don’t report to you to make decisions.
- The hard part is never the technology: getting seven people from four teams in three time zones to show up with context is where the real work lives.
- AI is changing what staff engineers are responsible for, not just how fast they work.
When people hear “staff engineer,” they often picture someone who writes more code, faster, on harder problems. A senior engineer with the dial turned up. In practice, the role is less about writing code yourself and more about making sure the right code gets written by the right people at the right time.
It’s also about ensuring that everyone involved actually agrees on what “right” means! Sometimes that’s system design. Sometimes that’s running an incident. Often, it’s herding cats.
I’m a staff software engineer at Crunchyroll, where I work across the fan experience engineering team. I don’t have direct reports. I’m a pure individual contributor (IC), but my day rarely looks like what most people imagine an IC’s day looks like.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
The staff engineer job is horizontal
The biggest shift from senior to staff was the axis of my work rotating 90 degrees. As a senior engineer, I went deep on my team’s problems. As a staff engineer, I go wide across teams’ problems.
In a given week I might be reviewing a technical design document for our partner metadata feeds service (a system where someone had built a Minimum Viable Product (MVP) that wouldn’t scale). I had to learn it and then architect the scaling solution, spanning ingestion, transformation, and delivery pipelines. I had to investigate why a downstream service was generating excessive authentication calls and coordinate with our payments team on a partner onboarding flow, all while someone from a team I’ve never worked with pings me in Slack asking how our credential system works.
At Crunchyroll, I’ve served as technical lead for our partner recommendations Application Programming Interface (API), helped revamp our search and discovery systems, and most recently prototypes that I can’t talk about here.
These systems touch partner engineering, content metadata, account services, data engineering, and security. No single team owns the full path from a user opening a partner’s set-top box to seeing personalized Crunchyroll recommendations inside the Crunchyroll app. That means no single team can design, build, or debug it alone. My job is to be the connective tissue.
Herding cats
The biggest misconception about being a staff engineer is that it’s a technical role. It is, but only in the way that being a film director is a “camera role.” Yes, you need to deeply understand the technology, but the hard part – the part nobody warns you about – is getting seven people from four teams in three time zones to converge on a decision before the window closes.
I authored multi-part technical design documents that spanned partner engineering, our internal content APIs, and our DevOps infrastructure. The architecture itself was complex but knowable. What was hard was getting pre-readers from each team to actually read it, leave feedback within the same week, and show up to the design review with context. I spent more time in DMs nudging people than I did writing the document. That’s not a failure of process – that is the process at the staff level.
I’ve also been a regular participant in our weekly technical design review meetings, which are open to all engineers across Crunchyroll. The goal is to create a forum where people present designs early enough that feedback is still actionable. Half of making that work is logistics, half is culture – convincing engineers that presenting an ugly-but-honest early draft is better than presenting a polished document after the code is already written – or hiding your document entirely.
More like this
You still write code, but different code
I want to be clear: I still write code. A lot of it. However, the nature of the code changed. I recently shipped a 14-part stacked pull request (PR) series for a prototype, building out the service layer, Command Line Interface (CLI) scripts, data pipelines, and Databricks notebooks for production data. I fixed a SEV2 incident where deeplink URLs for a partner serving 200,000 potential users had silently regressed.
I’ve also written things that don’t look like “code” at all: incident postmortems, on-call runbooks, onboarding guides, and architecture documentation. When a partner’s deeplinks broke, I didn’t just fix the bug. I wrote the postmortem that identified the gap in our deployment process, calculated the blast radius (three of five carousels across 2 million set-top boxes), and documented the timeline from detection to recovery. That document is infrastructure too. It just doesn’t compile.
The staff engineer role in 2026: AI changes the shape of the work
The staff engineer role is evolving faster than I’ve ever seen. In the past year, AI tools have changed how I work in ways that are hard to overstate. I now use Copilot CLI with Model Context Protocol (MCP) integrations for Datadog and Atlassian to investigate incidents, query metrics, and create analysis notebooks without leaving my terminal.
I’ve also created two skills that I hope will help engineers at Crunchyroll work better:
- Specific types of Datadog notebooks: everyone can benefit by starting with this skill when doing analyses.
- Writing a technical Design Doc (TDD) to Jira ticket to PR: it’s the whole lifecycle at my fingertips in the CLI.
During a recent incident involving NAT gateway exhaustion, I used my tools to correlate JSON Web Key Set (JWKS) fetch errors across services, produce a Datadog notebook with the relevant traces and metrics, and draft the investigation summary, in hours rather than the days it would have previously taken.
However, here’s what I think is more important than how AI changes my personal productivity: it changes what a staff engineer is responsible for. I’m currently building and leading a 12-week pilot AI engineering training program at Crunchyroll, our first structured initiative to help engineers become what I call “AI-native.” The curriculum covers everything from prompt engineering fundamentals to using AI agents for incident response. I open-sourced the playbook and presented the methodology at QCon London 2026.
This is new territory for the staff engineer role. Five years ago, nobody would have expected a staff IC to design a training curriculum. In 2026, if you understand both the technology and how engineers actually work, you’re the right person to figure out how AI tools should be integrated into your organization’s workflow – not as a top-down mandate, but as a practical, engineer-led adoption.
I wrote the Datadog MCP setup guide and shared it in Slack. I reviewed how teams were using Copilot code review and reported back on what was working. I’m training a cohort of ten engineers and documenting what we learn so the next cohort goes smoother. That’s staff engineering: see a gap, fill the gap, make it repeatable.
What does the role require?
If I had to distill the staff engineer skill set to its essentials, it would be these:
- Comfort with ambiguity: senior engineers get well-scoped problems. Staff engineers get “we need to support hundreds of future partner integrations and the system doesn’t exist. Build it.” Your first job is to figure out what the actual system needs to be before you can build it.
- Writing: technical design documents, postmortems, runbooks, architecture diagrams, Slack messages that summarize a two-hour call for the people who weren’t there. If you can’t write clearly, you can’t operate at this level. Period.
- Knowing when to code and when to delegate: I could build every feature myself and it would take forever. Or I can build the prototype, document the patterns, and let the team run with it. The second approach scales. The first one burns you out.
- Relationship-building across the org: when an incident happens, I need to know who owns the service, who’s on call, and who has the context before I read the runbook. That comes from months of showing up in other teams’ channels, reviewing their designs, and being helpful when they didn’t ask for it.
London • June 2 & 3, 2026
New activities added to LDX3 London 🎉
The staff engineer reality
Being a staff engineer means your calendar is a mess of design reviews, incident bridges, 1:1s with engineers who don’t report to you, and Slack threads that somehow became your problem. You’ll write a technical design document in the morning and spend the afternoon explaining it to five different audiences. You’ll fix a production bug and then write the doc that prevents the next one. You’ll build an AI prototype and then build the training program to teach your colleagues how to use it.
It’s not glamorous. It’s not “10x engineer” mythology. It’s the work of making an engineering organization actually function across boundaries. In 2026, those boundaries include figuring out how humans and AI tools work together effectively.
If that sounds like your kind of challenge, pull up a chair. We have plenty of cats to herd.
