In Amy's list of different staff engineer archetypes and their responsibilities, she puts a lot of emphasis on "what you might be blamed for," which I actually really like as a way of defining what someone's "actual job" is.
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.
I was in a meeting once decades ago when the company was going through its annual deck chair rearranging. A woman we didn't know came in and said she was going to watch our meeting for... #reasons. My manager asked over and over what she did and finally after 3-4 rounds of CorporateBizSpeak, he finally just said, "Ok, let's try this. What at <company> would have to fail for you to be fired?"
If ever there was a live experience that indicated what "gobsmacked" meant, it was that. She basically couldn't answer. The only thing she could blurt out was "<the person who she reported to that we all knew and was fairly high up> said I should be here".
I dislike the blame bit because success in creative jobs are to a large extent about doing things nobody else thought of. (And by definition, of course, if you fail to do something nobody else thought of, nobody would blame you for it either.)
> if you fail to do something nobody else thought of, nobody would blame you for it either.
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.
> 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.
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!
I'd prefer responsible or accountable for to blame, personally, but blame has a way of really getting you to zero in on the important-to-the-business aspect. The stuff people will be mad about if it fails!
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.)
At staff, or even senior levels, you only have a limited time after joining a company to identify opportunities and initiate projects. Once your projects go live, you're responsible for them. If your initiatives keep failing and getting scrapped, you'd be out of a job soon.
Eek pretty bad take on this. The reality is blame cultures are there such that you can be used as a scapegoat. It's nothing to do with defining problems it's there to have someone to fire when something goes wrong.
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.
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.