Staff Plus Live 2021 was a virtual conference held by LeadDev.com on Sept 14, 2021. I believe this is their first
conference aimed at Staff+ Engineers. Loosely defined, Staff+ are high-impacting engineers whose success is felt across
the company. In other words, these are engineers who creates high leverage. I was able to attend this year’s conference
and learned a lot from it. I started this post to write down what resonated with me before I forget about them.
Yonatan talks about four broad skills a Staff+ Engineer needs to have:
Technical Contribution Which can involve architecture, design, or implementation. It can be as a team lead or
working under a lead.
Product Management Is the skill of creating a story about what to build and why it is important. This is a
combination of understanding the business, the organization and the company values. Then creating a compelling story
that people will buy into.
Project Management Requires one to organize people to successfully accomplish a goal. This is commonly known as
“cat herding” and involves continuously pushing on a project to ensure forward progress. One can consider Product
Management as the “What” of a mission and Project Management as the “How” of a mission.
People Management This involves finding the right people to come together to solve a problem and address any
social issues: growing a team, resolving conflicts, handling egos, giving feedback, and building psychological safety.
While it is not necessary to master all four skills, a Staff+ Engineer needs to be competent enough to be a leader in
these areas when necessary. Yonatan stresses that, in today’s world, it is rare that a senior IC will be a master
of a specific thing (say, machine learning). Instead, a Staff+ Engineer needs to be able to smoothly transition to different
roles as the situation demands.
Yonatan also mentioned the critical importance of bringing a diversity of experience to the table. Big decisions are
often made collaboratively and great decisions often rely on a diversity of views. He points out that in today’s world,
human beings (e.g., engineers) are a critical part of any technical solution. Your personal experience is essential
to helping engineers in your organization succeed.
Speaking of personal experience, Yonatan expanded on the value of being the adult in the room – sometimes you need
to rein in the overwhelming enthusiasm of the team in order to deliberate on the details.
In the same vein, you often need to be the one to talk about not just “how things will work” (what Yanatan calls
“Product Engineering”) but also “how things will fail” (what he calls “Safety Engineering”). This kind of skill comes
only from the experience of making software for many years.
Being a Staff+ Engineer means taking on more ambiguity. But what does that mean? This was a great topic for the
panel. Derek viewed ambiguity as opportunity to exercise creativity. While Keavy took the opportunity to distinguish
“Ambiguity in what is expected of you (bad)” vs “Ambiguity in how you are expected to solve a problem (good).” What
everyone seems to agree on is that as a Staff+ Engineer, you are expected to create clarity out of ambiguity for less
A Staff+ Engineer generally need to influence without authority (a manager frequently need to do this as well). Glen
pointed out the value of using documentation as a way to do this. For example, by documenting pain points, one can more
easily get buy-in to solve problems. I thought Silvia hit it on the nose by pointing out the importance of understanding
hidden incentives. Commonly, problems fester because of hidden/bad incentives discourage people to work on them.
Keavy also made a great point: Look for a sponsor for your goals.
A sponsor can be a technical or non-technical leader. A senior person with influence cheering for your idea can make a
The panel had a brief debate about whether to use standards to drive outcomes:
Glen had success with avoiding creating standards. I thought his best point was, “Going from seventeen ways of doing the
same thing to three is easy. Going from three ways of doing the same thing to one is expensive.”
Silvia pointed out that a single way of doing things can have a large pay-off. It is almost always necessary when a
company gets to a certain size.
Derek recommended using the “golden path” pattern: Make the recommended way too easy to resist instead of mandating a
standard. I thought this touched on Silvia’s point regarding understanding incentives and human behavior. I’m sure
they were virtually high-fiving each other in DMs.
A later discussion touched on what differentiates an IC leader from a manager. A couple of points
A manager’s job is leadership, which often involves creating vision. A manager owns what to do, not how to do it.
While an IC leader is capable and often steps into the role of a manager. It is ultimately up to a manager to take
ownership of a project.
The last one seems particularly wise. Some people will tell you to work on the hard problems first (they are right, in
the right context). But most of the time, you should avoid solving hard problems. They are expensive in terms of company
resources and opportunity costs.
Building Successful Relationship Between Manager and Senior IC
Tramale pointed out that trust must be earned. This statement was controversial on the LeadDev slack. Reading it
charitably, I’d have to agree. As with any relationship, everyone must put in the effort to build and strengthen
trust. Furthermore, it should come as no surprise that in order to lead a high impact and high risk project, one should
have built a track record of success first. At the same time, this does not mean people should be distrusted by
default. A culture of constantly performing and proving can only lead to bad things.
Understanding business needs and knowing the right people are essential to success. For an IC, this often means
consulting with good managers. Managers, by their nature, meet more people, thus, have a better sense of who has
relevant information. A good manager can help you connect with the right people to understand the business, what’s
important, and who can help you succeed. It is important to create a good relationship not just with your manager, but
with other managers within your organization.
Build Your Own High Impact Backlog
Every senior engineer should have a “High Impact Work” backlog. It is up to you to create and maintain this. The input
to the backlog should be:
Company goals - What is important to the business.
Team needs - Identifying shared pain points. Understanding what other teams need.
Engineering goals - What is important to the engineering org. Process improvements, hiring and developing people. Not
just building systems.
Personal growth - What do you need to work on to grow?
Use feedback from your manager, peers, and leaders outside of your direct sphere (such as Product, UX, Sales,
Accounting, and Legal) to refine and prioritize your backlog. Once you refined your backlog into actionable goals, share
them widely. Finally, make this an ongoing process. Create a cadence to continually refine, course correct, and track
There are many great talks that I left out. The luminary interviews are evocative and personal stories such as [Leslie
Chapman]’s The Delegation Equation brings the human components to the session. I really enjoyed the first Staff Plus
Live conference. Many thanks to Tanya Reilly and other organizers for putting this together. I am hopeful for a
repeat next year.