How I operated as a Staff engineer at Heroku (2020)
amyunger.com
amyunger.com
Sure, that could be toxic if you take it totally at face value. "Blame" has some nasty connotations.
But let's face it: Staff engineer at Heroku/Salesforce is probably, what... $400k TC? At the very least? You are supposed to be someone who is solving seriously big problems. I think the most coherent way to write a job description is defining what those problems are, and "things you will be blamed for if they do not go right" is a very pragmatic way of defining those problems.
Also:
> First and foremost, I am successful if the folks I work with understand how business decisions tie into their day-to-day work.
Love this. If this were the literal only sentence that a person knew about technical leadership in software engineering, they'd be instantly top quartile of technical leaders.
That's a great point. It's definitely not a perfect lens. And I do think that the power of a "Staff Engineer" title or similar is giving really talented, creative engineers the organizational capital to go do wack shit, because hey -- sometimes that wack shit is GMail or JavaScript!
But at the end of the day, we're all getting paid to be here; I think having a clear understanding from the start of "what could I do wrong enough that my job is at stake?" is very, very valuable.
Later in the article, Amy also talks about how the "blame" can come from below, too:
> If the ICs that report to my manager end up feeling like “I told you so” or “We knew this was a bad idea” and that wasn’t surfaced for a discussion, that’s on me.
And I think that's a really healthy way to approach leadership. It is -- and should be! -- a very serious responsibility to be making decisions that affect lots of other people's jobs.
That might well be. I have a vague, uncomfortable feeling that there's a deeper understanding here that simply eludes me. I feel like maybe five years from now with some more experience I'll be able to read this exchange and facepalm at my naivete!
So if you come up with an idea nobody else had thought of, and you convince the company to spend millions or more on it in engineer-time-dollars, and it ends up being a total waste: yeah, you might have some questions to answer. There's a difference between doing something nobody else thought of and doing the right thing nobody else thought of, and the more you're responsible for in a company, the more that falls on you if you either keep getting it wrong or get it wrong once in a sufficiently-spectacular fashion. (There are nuances here of course depending on how you sold it to people, just how much everyone was aware of the risk of failure, etc... but it's important to remember freedom to experiment and take risks is different than freedom to do whatever you want.)
(There are certainly places where cushy titles can be sinecures, but whether or not that's the case is going to vary greatly depending on the company and their positioning and needs.)
In terms of the $400k TC you'll be talking shares, that need to vest, and bonuses and suchlike included in that. Nice way to reduce that is to blame you for problems on a project that were out of your control.
I've worked in companies where the Project Manager always put too short a timescale on any project. This was pushed onto them by an exec but rather than speak to the devs get a reasonable time and try to cut scope or extend time they just put it straight back onto the devs. Often they'll cut some time which I always found weird. The reason that this happens is that these PM's know that there is no way they can ever meet these expectations and so rather than try they make sure it'll be late such that they can blame the devs. That way they don't need to actually manage the project and never get reprimanded as it's always someone elses problem.
A lot of talk about how the author lives on the cross section of business, management, technical leadership and architecture - but literally zero mention of any measurable numbers or quantifiable impact. Little to no mention of honest disadvantages and limitations of this role.
I also find it a bit strange how literally every single article on https://amyunger.com/ reminds us that the author is a staff engineer, cares deeply about staff positions, very knowledgeable about the staff engineering role, and that it's oh-so-difficult to achieve this prestigious title...
The only thing you can reliably point to is "During my tenure, the company saw X metric go up or down in this area." But anyone in management who claims "I made metric X go up/down" is probably selling snake oil. Are you sure that it was you? Maybe it was a parallel change made by someone else. Maybe it was someone you hired, while you did literally nothing else but hire them. Even if you are sure, how in the world is anyone else supposed to verify that?
If someone can point to actually reliable ways to quantify impact of leaders/managers, please I would love to be shown to be misinformed.
As someone who's said that, you've given me reason to ruminate on whether I was being too cynical and not empathetic enough.
I'm not saying your take is wrong here (some people seem to love this kind of management porn stuff a bit too much and roll around in it), but it is true that as you get more senior, you're expected to do things that don't have that kind of quick payoff.
That's a requirement for staff engineering. This is how you graduate to staff. If you don't understand, there's a couple of books you can buy and educate yourself. Also there's a staff engineering podcast where staff engineers are invited to talk staff engineering and how to staff engineer effectively.
See my previous comment about this:
“In literature, recurring character patterns are called archetypes, such as the "hero" or the "trickster," and the archetype term is helpful for labeling these frequent variants of Staff-plus engineers.”
How does anyone take this seriously?
Quantifying impact of mentorship, technical leadership, management inherits all those problems and then adds new confounding factors in on top of it!
Quantifying business metrics changing is usually going to be misleading at best short of for, say, a CTO, and even then it's gonna also depend on product, sales, marketing, etc.
1. The corporation itself is built on business metrics though. Everyone quantifies this way, it’s table stakes to portray oneself as responsible for a positive change in business metrics. You still must pretend they matter even if you know better.
2. What do you think about quantifying by the free market? Eg. the annual revenue contribution of a new SaaS SKU that you spearheaded.
> I was incredibly lucky to spend 5 amazing years at Heroku. By the end of my time, I was operating in a Staff capacity, although I’m honestly completely unclear which titles at Salesforce actually map to Staff.
> I live-snarked much of the process on Twitter
oh, that explains it. An "influencer" and "thought leader".
Based on how time is being spent that sounds an awful lot like an EM role to me?
Like EM responsibilities minus actual humans reporting to you?
There is also another part where you are free to work on activities that are 12-24 months out. So, prototyping new ideas, setting up the pilots and mentoring sr. s/w engg. resources to be able to execute on them.
The little secret no one mentions is that most of the time you're not needed. If you are then you're too much in the weeds and cannot be an effective staff engineer.
That should be true of every individual.
If you mean role (i.e., "what if we had no staff engineers (or equivalents) at all?"), ye-es, but only for a time, else the company will likely be, at best, inefficient.
Every higher level role on the team, be it a staff eng, a tech lead, an EM, etc, is a multiplier role; they should behave as basically a glorified plate spinner. When the plates are all spinning they can step away and you'll never notice their absence. When the plates are wobbly, you should feel their presence more. The ideal workflow is a series of barely perceptible touches to add a little more inertia across a variety of plates.
Maybe a better way of framing it is people managers have too much power. In an alternate reality, "staff engineers" hire and fire and have budget signature powers, and "people managers" are more like HR-plus who manage interpersonal conflicts and deliver performance evaluations. The status quo is a remnant of how society has historically undervalued and infantilized technical workers.
I don't care if your company called you an Elite Ascended Architect Principle Rockstar. Tell me some concrete things you've actually done. Sitting in meetings with the C-Suite might feel good, but frankly doesn't impress me.
You are distinguished from Architects, who are specialists in writing said plans, but do not themselves spend much time coordinating between Product and Engineering. If the plan is especially complicated, a Staff Engineer may serve as the technical manager for Architects, who build out and maintain the more complicated documentation, but typically Staff Engineers will write the plan themselves. Staff Engineers will also often write the code for prototypes or proofs of concept, to help illustrate the plan to Product.
You are distinguished from Project Managers and Engineering Managers, because your role does not require actually running after people and ensuring that the work is getting done on-time. You are responsible for your estimates, and you are held accountable if they are wildly off, so it is important for you to be well familiar with the Engineering teams and what they are largely capable of, but you're not responsible for the actual execution or for the professional development of the engineers managed by Engineering Managers.
Good Staff Engineers are rare because they need to have a firm grasp on the company's code, systems, Engineering teams, and the company's business needs in order to be successful.
Also: this needs (2020) in the title.
recently read that book. it's funny that the book wanted to show a diverse group of staff engineers and what they do. but i ended up thinking, oh wow, they are all pretty much saying the same thing. (there were a few exceptions)
but at least the book gives you an idea.
I could recommend twenty more books that I think are essential to be a good leader (in various areas like ownership, communication, continuous improvement, planning, innovation, anthropology, visual control, calibrated estimation, etc.), but Deming stands way above everything else.
I also found it impossible to rank books, so instead I took roughly the top 20, grouped them into themes, and then ranked the themes based on how important I think they are.
1. Deming is the primary writer of the type of management we need to be competitive: Deming, The New Economics & Out of the Crisis.
2. There is a wide variety of ways for humans to organise. Nobody is forcing the default capitalist bureaucracy on you, so be creative: Graeber, Bullshit Jobs & Dawn of Everything & The Democracy Project.
3. How people are motivated: Pink, Drive.
4. How to create a high-trust, less authoritarian, open, collaborative environment within a traditional hierarchy: Marquet, Leadership is Language.
5. Communication: Voss, Never Split the Difference. Faber, How to Talk So Kids Will Listen.
6. How to help organisations who don't want to admit what their problem is: Weinberg, Secrets of Consulting.
7. How to structure organisations and processes to deliver maximum value: Reinertsen, Principles of Product Development Flow. Ward, Lean Product and Process Development. Womack, Machine That Changed the World.
8. How to innovate cheaply: Westrum, Sidewinder.
9. How to estimate things properly: Hubbard, How to Measure Anything. Tetlock, Superforecasting. Savage, The Flaw of Averages.
10. How to train people to be experts at things: Hoffman, Accelerated Learning.
11. How people fail at decisions: Kahneman, Thinking, Fast and Slow & Noise.
I had to leave out a few about statistics, causality inference, project portfolio investment that didn't make the top 20 cut.
> If you’re not making your delivery timelines and this is a surprise to your organization, you and your manager have a problem
When the bullshit arbitrary estimates you gave became bullshit arbitrary deadlines, we didn't like it when reality happened.
> If product has a dream and no one knows what it would take to build it (time, resources, architecture), you have a problem
Some MBA cock landed a customer on lies about features that won't and can't exist and now it's somehow our fault.
> you are basically unfireable because you know so much
We are at the mercy of assholes. Our company rewards generating needless complexity.
> If you’re not making your delivery timelines and this is a surprise to your organization, you and your manager have a problem
If you're not communicating the state of the thing you're working on with the people who need to know then you have a problem.
> If product has a dream and no one knows what it would take to build it (time, resources, architecture), you have a problem
Your job is to effectively communicate what is and is not possible, and at what cost.
> you are basically unfireable because you know so much
Sometimes things are complex and you know why they are complex and how they got that way and how to avoid those mistakes in the future.
You're acting like it matters that you're communicating that there has been a setback or delay. Your estimate is a deadline and failing to make the deadline will be a disappointment.
> Your job is to effectively communicate what is and is not possible, and at what cost.
No one cares about any of this. All the people who actually run the company care about is fulfilling what they are now contractually obligated to do -- an obligation they made without consulting you, so everyone can move on to the next round of customer commits.
> Sometimes things are complex and you know why they are complex and how they got that way and how to avoid those mistakes in the future.
That sounds like everyone working on any large project. That doesn't make anyone unfireable.
Maybe I just got super lucky--it's a good fit for me and it's a huge part of why I've stayed so long--but to say that all companies and upper management are as you've described? That's painting with too broad a brush.
The point being if you're an engineer working on a project and it is done quicker than the timeline there will be nothing extra accept a thank you. If your project it late you could be fired.
Is this a recent phenomenon? Does anyone know why there are so many upvoted stories of people just recounting their daily work?
(edit: fixed the link)
Also most of your contribution to the business is ignored if you can't hire.
If Director is the most senior you can be without being that, you're generally the highest execution-focused role that lets your VP do their thing. Somewhat equivalent to an XO in the military. At the same time, you're usually the one who has to translate the relevant parts of the strategy into something relevant and tactical for everyone below.