Around 2021, I became a Staff Engineer at Hopin. It was the first time I was given enough space to think beyond my own output. I could help other engineers grow, mentor them through decisions, and lead small groups working across time zones.
Before then, I had an incomplete picture of Staff engineering. I thought the role belonged to the engineer who could take on the hardest work and do more of it than anyone else. The experience taught me almost the opposite. Staff engineering is not about being the person who does everything. It is about multiplying the people around you.
The trap of doing it all
Being the person who can solve a difficult problem is useful. Becoming the person every difficult problem must pass through is a risk. The team slows down when you are unavailable, other engineers get fewer opportunities to stretch, and your attention becomes another shared dependency.
This can still look like high performance from the outside. You answer every question, join every discussion, and rescue work that is falling behind. Yet the team is not becoming more capable. It is becoming more dependent on you.
My role as a Staff Engineer gave me room to practice a different kind of impact. Instead of asking, “How can I finish this?” I started asking, “What does this team need in order to finish this well?”
Multiplying others through mentorship
Mentorship was an important part of that shift. It was not separate from delivery, and it was not limited to scheduled career conversations. Mentorship happened while defining a problem, reviewing a design, or helping someone work through an uncertain decision.
The goal was not to turn every engineer into a copy of me. It was to share enough context for them to make good decisions in their own way, then give them real ownership. Sometimes that meant telling a story about a similar failure. Sometimes it meant asking questions instead of offering an answer. Often it meant stepping back when I could have done the work faster myself.
I have written more about this in engineering mentorship without prescriptive advice. The clearest sign that mentorship is working is not that someone starts making your decisions. It is that they make clearer decisions of their own and need you less over time.
Looking for the next blocker
Stepping back from implementation did not mean stepping away from the work. It meant keeping a wider view of it. While engineers focused on the problem in front of them, I tried to notice what might block the team next.
Was an important requirement still ambiguous? Did another team own a dependency we had not discussed with them? Were we making a decision that would be expensive to reverse? Did the people outside engineering understand what we were building and what it would change?
None of those questions produce code directly. Answering them early can save weeks of code, rework, and frustration. That is one of the less visible parts of Staff engineering: moving uncertainty forward so the team encounters fewer surprises later.
Being DRI without becoming the bottleneck
One of the most important projects I drove at Hopin was recording data localization. Organizers needed the option to store recordings in an EU-based data center, supporting the company’s broader GDPR and DACH compliance efforts.
The technical work mattered, but it was only one part of the project. The effort crossed boundaries between engineering, product, security, legal, and sales. Requirements needed to be documented, responsibilities needed to be clear, and engineers in different time zones needed enough context to keep moving without waiting for the same meeting.
Being the directly responsible individual did not mean personally implementing every part. It meant being accountable for the outcome. My job was to create clarity, divide the work into meaningful areas of ownership, notice risks, and make sure decisions did not disappear between teams.
We shipped the work, and it was used for the first time the day after it reached production during an internal event announcing DACH support. The project also exposed a weakness in how we communicated. Questions and incorrect assumptions continued to surface from sales, security, and legal. Our technical documentation and engineering alignment were not enough for every audience.
That was an important lesson. A Staff Engineer cannot treat communication as complete because the implementation team understands the plan. Different stakeholders need different levels of context, different language, and sometimes a different forum entirely.
Leading across time zones
Running small groups of engineers across time zones made clarity even more important. When working hours barely overlap, unclear ownership can cost a full day at a time. A decision trapped in a meeting can leave someone blocked until the next overlap window.
The answer was not to add myself to every handoff. It was to make the work easier to continue without me. Written decisions, explicit owners, clear boundaries, and enough background to understand why a decision was made all helped the team move independently.
This changed how I thought about leadership. Leadership was not being at the center of every conversation. It was creating a shared understanding that could travel farther than I could.
Derisking is part of delivery
I used to associate delivery mostly with implementation. In a Staff role, I learned to see risk reduction as delivery too. Clarifying a requirement before several engineers build against it is delivery. Finding a missing stakeholder before launch is delivery. Giving an engineer enough context to own a decision is delivery.
The best Staff work often changes what does not happen. The team does not wait on a dependency that nobody noticed. A decision does not need to be reversed late in the project. An engineer does not stay stuck because the only person with context is asleep on another continent.
My first Staff role taught me that impact at this level is not measured by how much of the system requires you. It is measured by how much more the team can accomplish because you were there, including when you are no longer in the room.