[HN Gopher] How I operated as a Staff engineer at Heroku (2020)
___________________________________________________________________
How I operated as a Staff engineer at Heroku (2020)
Author : craigkerstiens
Score : 87 points
Date : 2022-03-31 17:47 UTC (5 hours ago)
(HTM) web link (amyunger.com)
(TXT) w3m dump (amyunger.com)
| henning wrote:
| I translated a few important parts:
|
| > 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.
| lghh wrote:
| Nope. Way too cynical of a take.
|
| > 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.
| firstSpeaker wrote:
| Not to hijack the thread, but anyone knows any book on what a
| director of engineering does?
| vasco wrote:
| A director is there to get shit from VPs about EMs and get shit
| from EMs about VPs. FTEs think you're not an engineer anymore
| and forgot everything once your title changed and "business
| people" think you're too much of an engineer and don't
| understand the rest of the business.
|
| Also most of your contribution to the business is ignored if
| you can't hire.
| rrdharan wrote:
| This is a fantastically accurate description. I'm tempted to
| send it as a card to my director along with a sympathy
| bouquet and a box of chocolates. Well done.
| cozos wrote:
| They can wipe their tears with stacks of hundred dollar
| bills :)
| [deleted]
| jon-wood wrote:
| The Manager's Path by Camille Fournier has a chapter or two in
| senior engineering management, and regardless of that is just a
| great book about being an effective manager in technical
| organisations.
| sys_64738 wrote:
| A director is the interface between the higher ups and the
| lower levels of the org. Basically taking strategy and vision
| by articulating it to product deliverables. They're also the
| first to fall on their sword when things don't work out and
| heads need to roll.
| actually_a_dog wrote:
| This isn't really directly related, but close enough that I feel
| it isn't off topic: what are the 3-5 best books a new staff
| engineer should read? I realize that reading 5 books on the
| subject generally puts you 4-5 books ahead of just about
| everybody else, but I like books.
|
| Also: this needs (2020) in the title.
| kqr wrote:
| Either _The New Economics_ or _Out of the Crisis_ or both, by
| Deming.
|
| 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.
| angrais wrote:
| Well ... Go on then! What are the other 20 that you
| recommend, sorted by your personal favourites?
| blondin wrote:
| staff engineer by Will Larson.
|
| 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.
| triyambakam wrote:
| What about for becoming a Sr SWE or Tech Lead?
| patleeman wrote:
| The Manager's Path by Camille Fournier is my go to
| recommendations for all new tech leads or those getting
| into people management on my team.
| softwarebeware wrote:
| What about Debugging Teams?
| softwarebeware wrote:
| Or Peopleware
| actually_a_dog wrote:
| I've actually read Peopleware and got a lot out of it. It's
| been a while, so I might be due for a re-read.
| aix1 wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=24437715
|
| (edit: fixed the link)
| craigkerstiens wrote:
| Doh, I submitted this twice, fully unintentionally. Came across
| it on Amy's feed again and well... forgot I'd submitted.
| dang wrote:
| Reposts are ok after about a year! so no worries
|
| https://news.ycombinator.com/newsfaq.html
| up_and_up wrote:
| https://amyunger.com/blog/2020/09/10/staff-engineer-at-herok...
|
| 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?
| georgeburdell wrote:
| Yes. Perhaps I'm getting old and cynical, but "staff engineer"
| is an invention by companies that are no longer growing quickly
| enough to absorb all of their most promising employees into
| proper management roles. Instead of having the power of
| enabling continued employment, you have to "influence" others
| to do your work.
| mostdataisnice wrote:
| This is ridiculous - the most promising engineers are not
| always the best people managers.
| georgeburdell wrote:
| A promising engineer rises through the technical track by
| showing impact. You show impact by getting others to sign
| on to your vision. You request a budget. You engage with a
| lot of stakeholders through meetings. Sounds a lot like
| what we call a "people manager" but without all of the
| tools available to one.
|
| 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.
| gautamdivgi wrote:
| Yes and no. There is a part where you're responsible for the
| direction of the team but the real trick is knowing when to
| step away and let the teams executing own it and discuss with
| management what metrics are needed to track success.
|
| 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.
| lostcolony wrote:
| >> The little secret no one mentions is that most of the time
| you're not needed.
|
| 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.
| SkyPuncher wrote:
| Yea, that's essential what high level technical people are.
| They're making decisions on generalized details with enough
| confidence that they details can be filled in by lower level
| engineers.
| addcninblue wrote:
| This is the first I've heard of the "Deep Diver" role. How common
| is this at companies of varying sizes?
| csmpltn wrote:
| Something about these articles reads so self congratulatory and
| aggrandizing...
|
| 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...
| lelandbatey wrote:
| Quantifying impact in many of these roles is something that's
| incredibly difficult, and if you actually do it, most people
| will say "wow, that's an incredibly arbitrary and abstract way
| of quantifying impact that feels suspect."
|
| 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.
| digisign wrote:
| I've only read this one, but did in a spirit of "happy to be
| there." I did get a bit of a whiff of "drank deeply of the
| cool-aid" vibe, however. For a blog meant primarily to be read
| by your team/pr-vehicle it might make sense.
| ketzo wrote:
| 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.
| kqr wrote:
| 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.)
| ketzo wrote:
| > 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.
| subsubzero wrote:
| Maybe replace "blame" with "responsible for", it has the same
| meaning but has less finger pointing/negative connotation
| associated with it.
___________________________________________________________________
(page generated 2022-03-31 23:01 UTC)