16 ms·
How I operated as a Staff engineer at Heroku (2020)
- aix1 5y agoPrevious discussion: https://news.ycombinator.com/item?id=24437715 https://news.ycombinator.com/item?id=24437715 (edit: fixed the link)
- craigkerstiens 5y agoDoh, I submitted this twice, fully unintentionally. Came across it on Amy's feed again and well... forgot I'd submitted.
- dang 5y agoReposts are ok after about a year! so no worries https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html
- up_and_up 5y agohttps://amyunger.com/blog/2020/09/10/staff-engineer-at-heroku.html#spend-time 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?
- SkyPuncher 5y agoYea, 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.
- gautamdivgi 5y agoYes 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 5y ago>> 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.
- georgeburdell 5y agoYes. 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 5y agoThis is ridiculous - the most promising engineers are not always the best people managers.
- georgeburdell 5y agoA 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.
- actually_a_dog 5y agoThis 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.
- blondin 5y agostaff 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 5y agoWhat about for becoming a Sr SWE or Tech Lead?
- patleeman 5y agoThe 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.
- kqr 5y agoEither 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 5y agoWell ... Go on then! What are the other 20 that you recommend, sorted by your personal favourites?
- firstSpeaker 5y agoNot to hijack the thread, but anyone knows any book on what a director of engineering does?
- jon-wood 5y agoThe 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.
- vasco 5y agoA 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.
- deleted 5y ago[deleted]
- sys_64738 5y agoA 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.
- csmpltn 5y agoSomething 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/ 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...
- digisign 5y agoI'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.
- lelandbatey 5y agoQuantifying 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.
- kjeetgill 5y ago> most people will say "wow, that's an incredibly arbitrary and abstract way of quantifying impact that feels suspect." As someone who's said that, you've given me reason to ruminate on whether I was being too cynical and not empathetic enough.
- ketzo 5y agoIn 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 5y agoI 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 5y ago> 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.
- henning 5y agoI 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 5y agoNope. 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.
- henning 5y ago> 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. 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.
- addcninblue 5y agoThis is the first I've heard of the "Deep Diver" role. How common is this at companies of varying sizes?
- decebalus1 5y agoNot very common as a 'role', unless you're in the Navy. Because it's made up and it's an oddly specific description of some person the author observed. Everyone can become a 'deep diver' as appropriate. It's not a role, at best it's an archetype which evolves naturally if the organization allows for it. Nobody hires 'deep divers' (unless of course, we're talking about the Navy) or has a business need for 'deep divers'. All of this is just malarkey.
- jackblemming 5y agoI refuse to take anything besides software engineer and senior software engineer seriously. Even that varies by a huge amount at different companies. 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.
- brendanyounger 5y agoWell said. The original post makes it clear how Heroku and Salesforce at large haven't shipped anything of note for 10+ years.
- j7ake 5y agoI have noticed an uptick of “staff X” as the new prestigious goal for technical careers. Is this a recent phenomenon? Does anyone know why there are so many upvoted stories of people just recounting their daily work?
- tayo42 5y agoPeople with this title are making 400k+
- solatic 5y agoValuable Staff Engineering is basically the bridge between Product and the rest of Engineering. Product decides what the organization ought to build (based on discussions with customers etc.), while Staff Engineers break up the problem into buildable chunks and come up with a detailed plan for Engineering to execute, including a true understanding of costs and time estimates. Over the life of the plan (from paper to executed reality), you serve as the point of contact for any questions from junior to senior level engineers on how to execute, as well as the point of contact for Product to make changes to the plan as the business changes according to the market. 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.