In my experience, software teams donât always leverage StaffPlus Engineers to their maximum impact. Some teams even treat them as nothing more than extra-prolific executors, leaving most of their potential untapped.
Do you manage StaffPlus software engineers, or aspire to do so? This post collects and explains my personal best practices for empowering StaffPlus engineers â which really just means creating the right framework for them to flourish⊠and then getting out of their way.
First, letâs define terms.
StaffPlus engineer is a catchall for software engineers who are Staff Engineers, Principal Engineers, or even more senior than that â distinguished engineers, CTOs, and so on.
Staff Engineers are the starting point within âStaffPlus,â although theyâre far along on the org career ladder and in engineersâ careers. Roughly speaking, âStaff Engineerâ denotes around seven years of technical expertise, but is sometimes achieved faster based on impact. Though Iâve used years as a benchmark, be careful not to index on that too much. We will get into more specific attributes below.
Principal Engineers are the level above Staff Engineers. The two roles are similar in some ways: neither Staff nor Principal Engineers typically manage other engineers; instead, both are responsible for creating leveraged impact in the business and workflow of their company.
Crazy plant lady thatâs me.
What do houseplants and StaffPlus engineers have in common? More than youâd think.
And to understand the Venus flytraps that are Principal engineers, you first need to understand the rare orchids that are Staff Engineers.
For many years, all I wanted to be was a Staff Engineer. My first ever code mentor and cubicle mate was Steven Tamm, now CTO at Salesforce. âStammâ was loud and opinionated and inspiring. He was the first âStaffPlusâ I ever encountered. Salesforce called them âarchitects.â He sat next to me and I sometimes worried he might break his keyboard given how frequently he slammed on it (while occasionally cursing at his computer).
In those early days, I followed Steven around, trying to learn as much as I could. He would go to VAT (Virtual Architecture Team) meetings in which everyone would loudly debate the software designs of important projects. At the time, Jeanine Walters was one of only two StaffPlus Engineers who was a woman; her presence in those meetings gave me hope that I could do it too. Inspired by her and many others, eventually, I did just that.
In 2018, I was promoted to be Gustoâs first Principal Engineer who was a woman. Today, I empower StaffPlus engineers. Along the way, Iâve learned how to inspire and set expectations for these unique species of specialists â as well as which plant metaphors fit each one best đ .
In my experience, there are six keys to success for StaffPlus engineers:
- Strong business judgement
- Leveraged impact
- Problem finding
- Multi-threaded approach
- Teaching
- Support and community
And whatâs true for Staff Engineers is even more true for Principal Engineers.
1. Strong Business Judgement
John Doerr tells a famous story about Andy Grove, the former CEO of Intel. Andy told John: âIt doesnât matter what you know. Execution is everything.ââ
StaffPlus engineers are deeply technical. Their choices can lead to the commitment of limited business resources for long periods of time. However, itâs critically important to engage your StaffPlus engineers on actual problems faced by your users. A perfectly designed software system isnât much use if your users arenât happy â or, worse, arenât choosing to use your software in the first place. Their happiness depends on a variety of factors, from timing to user experience to sales.
As key role models and guides for the strategic direction of your software, StaffPlus engineers need to frequently take off their engineer hats and learn what customersâ problems are â whether they originate in the actual code, or in the operations of a completely âunrelatedâ division of the company. (Principal Engineers, in particular, arenât afforded the luxury of âunrelatedâ divisions. If the phrase âNot my problemâ is part of their vocabulary, then âPrincipal Engineerâ is not part of their title.)
Thatâs your StaffPlus engineerâs job â well above and beyond the software itself. And as their manager (or empowerer as we say at Gusto), your job is to hold them accountable for developing and exhibiting a strong sense of business judgment. It follows then that you yourself should work on developing a strong sense of business judgement, so that you can effectively coach them.
2. Leveraged Impact
Business judgment and leveraged impact go hand in hand. âLeveraged impactâ is the magic phrase for Staff Engineers â and Principal Engineers are expected to deliver about 5x the impact of Staff Engineers.
The word âexponentialâ is frequently misused in business contexts â but when it comes to the results expected from Principal Engineers, itâs right on the money.
Once again, the software itself is secondary. StaffPlus engineers are responsible for creating systems that create tremendous business and/or workload impact.
In The Matrix, when Neo asks whether heâll be able to stop bullets, Morpheus responds: âWhen youâre ready, you wonât have to.â
Replace âbulletsâ with âunforeseen user complaintsâ or âinternal development bottlenecks.â Thatâs the level of vision, foresight, and inventiveness your StaffPlus engineers must aim for.
Around 15% of all software engineers at a given company are StaffPlus; StaffPlus engineers are rare orchids indeed.
But Principal Engineers are a different beast entirely: like Venus flytraps, they make bugs disappear before anyone else knows they exist.
These are the questions your StaffPlus engineers should be asking â and answering:
- How do we not simply solve problem X â but solve every possible instance of the category comprising X?
- How do we reduce costs â monetary, labor-hours, emotional, or otherwise?
- How can we create âpits of successâ so our engineers can more easily do the right thing by default?
- How can we make it easier for engineers to add features? And make other systemic improvements that create leveraged impact?
- And so on.
3. Problem Finding
Randall Koutnik has an excellent talk called Rethinking the Developer Career Path. In it, he describes the concept of a âProblem Finder.â
In my own experience, facilitating this skill-set in StaffPlus engineers follows this approximate blueprint:
- Co-brainstorm problem areas: This includes specific examples of customer feedback or other metrics. You both should be bought in on the directionality of the problem that needs to be solved.
- Find a starting point: Say, your StaffPlus engineer gets curious about a particular area of the code and asks for space to spend time investigating the framework. The StaffPlus engineer opportunistically improves an area of the code. Taking a real-life example when Amanda Mitchell and I were working together on a team at Gusto, she became curious about a certain part of our reporting framework, after we had been discussing feedback from a certain customer segment. Her explorations led to opportunistic performance improvements of a critical set of reports by 30%.
- Provide air cover: This one is really important, and Joel describes it here. You should be talking with your team and cross functional partners to set expectations. Bring their exploratory work out into the open and create the space they need.
- Set Expectations: Unless there are other factors, such as a critical deadline, your teams should be consulting higher-complexity problems with your StaffPlus engineer.
- Creating Leveraged Impact: From my example earlier, following her opportunistic improvements, Amanda ended up redesigning the system in question, systematically addressing performance concerns, and creating a âPit of Successâ so that future engineers wonât make the same mistakes that degrade performance.
- Teaching: You as their manager, are able to find the right audiences for them to teach about their work. You as their manager are able to articulate the impact of their work in detail. This is easier said than done as their work becomes more complex.
- Continue working together to generate ideas and set direction.
4. Multi-Threaded Approach
Your StaffPlus engineers should be running at least three threads at once â ideally, two large projects, as well as spending at least 15% of their time on mentorship. Set expectations and tell your StaffPlus engineers to bring you problems and proposals, and to expect you to make space for, create buy-in and help execute those ideas.
As their manager, you should have already taken the time to understand their interests so you can find appealing projects for them. For example, your StaffPlus might love APIs or have a propensity for working on projects that have customer interaction, or be an expert in mobile. It is not uncommon to find engineers at this level start to specialize as well. Combine all this information to help your StaffPlus to decide what âthreadsâ they should be running and what role they should play in each thread â i.e., it could be any combination of a primary executor on a certain technical part of the project, tech lead, architect, primary executor, mentor, consultant, debugger etc.
Time Management: That said, ultimately the onus is on them to decide where to spend limited resources and how to balance their time. The buck should stop with your StaffPlus engineers; if theyâre hesitant, just ask, âYouâre no mere orchid, are you?â (Under no circumstances should you actually say that and coach them as needed.)
5. Teaching
âIf a tree falls in a forest and no one is around to hear it, does it make a sound?â
Alongside solving problems before anyone knows they exist is also helping their teams around them understand what happened or what needs to happen. As role models and influencers of your organization, you should coach your StaffPlus engineer on teaching mechanisms, spreading their influence and knowledge within your org. As one of my reports, Steve Konves likes to say âEvery problem is a marketing problemâ and the more appealing or entertaining their content is the more successful they will be at this.
6. Community and Support
StaffPlus engineers are a big deal. People look up to them and it can be isolating and stressful. They are also not immune to impostor syndrome. They spend a lot of their time guiding and boosting engineers around them; they help your company to make large and difficult decisions; They have to deal with things like ageism and pressure to keep getting better, which is really hard when youâre at âthe topâ of the career ladder. Finding ways to keep building skills and growing gets harder when youâre always expected to know the answer to everything.
Your StaffPlus engineers need a lot more encouragement than most people think. Theyâre expected to know everything, which is literally impossible. So, giving StaffPlus engineers chances to experience âbeginnerâs mindâ and a safe space to experiment with new technologies/principles is very important. They need their own support system and their own sense of community.
To quote, Kevin Lawver:
âItâs easier at larger companies because of the variety of problem spaces. It was VERY difficult at small startups since there was literally no one to mentor me, since I was Yoda. Who does Yoda go to when heâs having a bad day? Obi Wanâs ghost? The bar?â
Thatâs where you come in. As their manager, youâre perfectly positioned to be the trusted voice they need â to guide them on navigating organizational politics, growing their career, and picking their battles. Help them find community and a sense of camaraderie, and they will flourish. In other words: a little water, a little sunlight, and get out of their way. đ
Room to Grow
This post was inspired, in part, by Will Larsonâs excellent project staffeng, which shares stories of Staff Engineers â providing insight and role models for folks early in their careers.
And as fate would have it, weâre only a week away from the first-ever conference dedicated to StaffPlus engineers, courtesy LeadDev. Itâs called, appropriately enough, StaffPlus Live, and itâs happening online on September 14th.
Do you have questions sparked by my post, or any topics you wish Iâd covered? Have you read anything fascinating about software, engineering management, or plants recently? Reach out; Iâd love to hear from you.
P.s. Many many thanks to Amanda Mitchell, David Haley, Isaac Noda, Jeremy Thomas, Kevin Lawver, Steve Konves, and Steven Tamm who have inspired this post and most of whom I have had the privilege to empower.