25 ms·
Staff Engineer Archetypes (2020)
- LAC-Tech 4y agoIt's only the other month that I actually realised having these as distinct roles - team lead, architect - has completely fallen out of fashion.
- therealdrag0 4y agoTeam lead seems pretty common still. But architect ya… kinda a bad word heh.
- LAC-Tech 4y agoWhich really does explain a lot about what's wrong with the current state of art :)
- dilyevsky 4y agoDedicated team lead is becoming more rare. Teams like to do per-project "leads" (where most of the time it's a single-person thread of work). This is commonly justified by "velocity" and bus-factor concerns. I am personally very skeptical of this fashion trend...
- rco8786 4y agoI straddle the line between Team Lead and Solver - but even just reading the descriptions there is a lot of overlap.
- deleted 4y ago[deleted]
- kache_ 4y ago>archetypes Staff archetypes is a meme. Here's an archetype for you: gets whatever needs to get done done. The idea of an archetype is harmful, it limits what people do and can become an excuse to not do hard grindy work. EDIT: On a second read, I guess you do end up doing one of those things for an extended period of time. But my point still stands: don't box yourself in
- dilyevsky 4y agoOk but a lot of people’s thinking is memetic. I’ve literally sat in performance review meetings where this article has been thrown around. Ignoring what management wants you to do even if it’s straight up cargo cultism probably wont get you very far
- beckingz 4y agoSounds like a right hand.
- HPsquared 4y agoThat's the rarest type, of course.
- codemac 4y agoArchetypes are useful in how you sell yourself. Don't forget that it's not what you are, just how you sell yourself. You can change between these every review cycle, job, career, all you want - no one in management is keeping track of your "archetype". They are keeping track of your impact. Lastly, you are the "person in the box" once you are senior enough. Take the archetypes, look at your org, and see which they need. Whatever is missing will be the most value to the org. How you see yourself accomplishing that box is the real challenge of executives, not this endless "what color parachute are you" self evaluation.
- adam_ellsworth 4y agoHas anyone read Tanya Reilly's new book "The Staff Engineer's Path"? Wondering if there's overlap in the concepts/model.
- 2rsf 4y agoI got it and skimmed through it, I can't answer your question but can definitely recommend the book
- efficax 4y agothe fetishization of staff engineers is really fascinating. do they actually act as "force multipliers", are they really essential to the success of large engineering orgs? In my experience, they spend most of their time in meetings not doing much of anything at all.
- mikefallen 4y agoSecond this, also stemming from this tend to fall behind technically speaking on the “bleeding edge”
- kccqzy 4y agoI think only the Solver type from the article acts as a force multiplier. Have a strange bug that you have been trying and failing to solve for a few days? They will probably fix that in a few hours and unblock you immediately.
- ilc 4y agoSolvers don't fix the problem. They tell you how to fix the problem. :) That's how they make sure the problem stays fixed.
- Matthias247 4y agothey should be able to do both. In case a high severity issue is ongoing, and someone knows how to fix it very fast - they should probably do it. Or guide another engineer in realtime on how to do it. If it's not that urgent, they might guide others in a more asynchronous fashion on how to get to a fix
- ilc 4y agoThey most certainly can do both, and do. But as a solver, I prefer to give it back to the person to solve. 1. I may know enough to know the problem and the rough fix. I may not know how to fix it in their codebase as quickly as they do. 2. See above. I want them to internalize the fix. That said, I ain't afraid to dive in and get it done. I remember not understanding some Java build system somewhere. So I fixed the code, tested it quickly, and hand deployed the jar... then I asked how to fix it for real ;) My boss was amused.
- travisgriggs 4y agoNeeds a 2020 tag
- voz_ 4y agoAvoid all these other types except Solver (we call it Fixer at FB). Anyone who calls themselves these things is weird, and will be hard to rely on. Disregard levels. Disregard titles. Fix what needs to be fixed. Unit tests, CI, docs, there's no such thing as grunt work. Real leadership happens in the IDE and only code matters - everything else is overhead.
- mi_lk 4y agoonly code matters is a stretch but generally agree. If you can fix whatever shit is thrown at you, you have my ultimate respect
- edmundsauto 4y agoI think the FB slogan is “code wins arguments” which is slightly different.
- throwaway1777 4y agoThat’s old school FB. Is it still like that?
- skizm 4y ago> Disregard levels. Disregard titles. Tell that to the person writing my paychecks.
- gorgoiler 4y agoCode Wins Arguments
- Supermancho 4y ago> Code Wins Arguments Unless the arguments are about "how to do the code correctly" for some value of correct that's imagined to be beneficial in the future.
- yamtaddle 4y ago
- vngzs 4y agoThis post is a draft version of the released version at [0]. [0]: https://staffeng.com/guides/staff-archetypes https://staffeng.com/guides/staff-archetypes
- ochoseis 4y agoI feel like the released version is a little better too. E.g. has the calendar graphics.
- agentultra 4y agoOne that I think might be missing is The Therapist: They are the glue that gets buy-in and agreement between people talking past each other. They demonstrate how a healthy organization can lead a team by setting guidelines for collaboration, communicating, being constructive, and removing barriers or silos between key stakeholders. They can resolve disagreements and unblock political stalemates with their unilateral authority and uncanny conflict resolution skills.
- hkarthik 4y agoAgree this is a key skill and necessary archetype in large orgs. But I'd call this person The Wolf (named after the Harvey Keitel's character in Pulp Fiction.
- ChrisMarshallNY 4y ago> But I'd call this person The Wolf Does this person get to ride off into the sunset in a fancy sports car, with the babe from the junkyard?
- hkarthik 4y agoI've seen the Wolf in a few companies and they are given some special treatment for sure. The corporate equivalent of the babe and the sports car. Years ago, one of them had a Macbook Pro while the rest of us were dealing with garbage Dell laptops that barely worked due to aggressive security scanners. He got his turned off by IT.
- dilyevsky 4y agoWat? The Wolf was a classic solver. Also see Mike from BB/BCS series
- Supermancho 4y agoI've never seen a Therapist Staff Engineer. This seems to be the primary function of middle management.
- 4y ago
- lifeisstillgood 4y agoIt's interesting to have pulled out the "Right Hand" archetype. Too often this distinction is ignored and everyone tries to align to the senior executive. All the other archetypes can be independent, as in the company can pay them to do their mission even if the executive is not engaged. I suspect it is time we stopped seeing companies as lead by an executive as the tip of a spear and more as a crowd with an agreed direction. Edit: I would also suggest that Staff Engineer is the next step on what I would call Software Literate Companies - it's not that we need execs who are not day to day technical supported by people who are. It's that we need execs who are day to day technical and not have ones who cannot code.
- biscuits1 4y agoBut what's your blast radius?
- posharma 4y agoArchetypes sharkitypes whatever…who cares! Identify a need in your organization and step up to meet/exceed that need. Done. Don’t need fancy titles, archetypes.
- posharma 4y agoWow! Why the downvotes?
- ki_ 4y agoHN can be weird on up/down-votes. Certainly when u put out a different opinion. Anyway. I would say, archetypes exist and they dont exist by choice. They are a natural occurrence. People do certain things in a certain way. And patterns can be found across these people. These patterns we call archetypes. People dont act to be like a certain archetype, the archetype is the label we give them based on how they act.
- PragmaticPulp 4y agoA lot of small and medium companies don't really know what to do with Staff Engineers. Not knowing what else to do, they default to something like the "Right Hand" archetype in this document, where they're reporting to someone important but lacking in any direct authority or accountability of their own. These positions can be very comfortable if the person isn't directly responsible for anything, but they can use their leadership-adjacent position to come in and take credit for successes on anything they touch. I worked at one particularly miserable company where the CEO's "Right Hand" engineer would be dispatched any time a project was running behind schedule. Lo and behold, the work would be delivered slightly after the deadline by the slightly behind schedule team, but the credit for the "turnaround" went to the CEO's "Right Hand". These positions can also be awful if the company puts unreasonable expectations on the Staff Engineer but doesn't actually give them the authority to execute. If you've been tasked with delivering a large initiative but you haven't been given any employees to do it with, your only option is to influence other teams to work on it with you. When it comes down to it, people are going to work on things for the person who determines their raises and performance reviews, not a floating Staff Engineer who needs people to help them. This is why "Team Lead" and maybe "Solver" are the only two of these archetypes that are sustainable for a company, IMO. Letting Staff Engineers sort of float around in the company and spread their knowledge sounds good in theory, but in practice you need to carefully assign them into the org structure like everyone else.
- civilized 4y agoI am a Team Lead and I have mixed feelings about it, some for reasons you give here. My manager handles the overhead of having reports, which is large at my company. But people only work toward my goals if my manager motivates them to, and most of his mental energy goes towards a separate fiefdom of his, not my team. And I have never had any control whatsoever over who is on my team - except in a couple serendipitous situations, where I made much better choices than the ones that were made for me. Overall I feel forced to work with entrenched incompetence and semi-competence, but at least I am rewarded fairly well for doing well in spite of this.
- hayst4ck 4y agoThis is jaded and angry, but I think there is another archetype called "the politician." They play the game extremely well, providing poorly thought out solutions quickly to problems they haven't dug into the complexity of. They lay operational traps everywhere in their quest to get things done fast (like directly embedding config data in code to avoid fixing the config format). Once they've picked the low hanging fruit and left too much complexity to maintain, they hop to another company where they sell themselves on all they accomplished leaving out the absolutely unmaintainable mess they left behind.
- maerF0x0 4y agoNext level politicians do a really broken implementation first cycle so they can deliver a solve next quarter for eye popping data driven results. I've personally warned people about terrible designs, saw them get implemented, they cost the company millions, but then they "improved" it next quarter to save the company "millions" ... They got promoted, I got called names like "too negative"... Great company.
- eftychis 4y agoI am guessing most/a lot of us have seen similar situations (unfortunately). (Sometimes, though situations like that are unavoidable -- given that demos can become product overnight or a deadline is unattainable no matter what you shave off. If I had a nickel for each time I had seen any of the above happen...)
- maerF0x0 4y agoyes there are shortcuts that one takes for a demo, but these were multimonth projects extending existing systems, it's not like the optimal solution was going to take much longer (if at all), we just needed an architect that understood computer science I think my biggest failing in my career is in being able to convince people that just because they don't understand something doesn't mean it's harder to code. Many O(n^2) solutions take just as long to code as O(n), for example...
- 4y ago
- denton-scratch 4y agoI wasn't familiar with the term "Staff Engineer", and wikipedia was no help. I found this: https://careerkarma.com/blog/how-to-become-a-staff-engineer/ https://careerkarma.com/blog/how-to-become-a-staff-engineer/ ...which seems to be saying that a "staff" engineer is indistinguishable from what I'd call a senior developer. As far as I'm concerned, "staff" is people that are permanently and directly employed. It doesn't mean "senior". If it's found it's way into the cycle of job-title inflation, that makes me sad.
- ChrisMarshallNY 4y agoIn "classical" corporations, the term "Staff" could be prepended to "Engineer," or "Scientist." They generally denote a management-level seniority, and they can be given staff, department head status, and a discretionary budget.
- opportune 4y ago“Staff” has been a regular title for SV software companies for quite a while now. It is basically the next level past “senior”. Whereas a senior will normally report to a line manager, staff engineers will often report to a middle manager and have managers as their peers. A normal range for a senior is 5-10 years of experience (but still many people will have more experience than that but not be “senior” depending on company), whereas staff is 10+ years. Obviously these are not wholly sufficient conditions but they’re common buckets, especially for external hiring. There is some title inflation going on where staff engineers are typically acting more as tech/team leads as opposed to senior engineers. IMO it’s a good title because “principal” has connotations of doing really big-picture stuff that may involve some resting on laurels. Also the bar for “principal” varies widely across companies - at Microsoft it’s the same as “Staff” at other places, at some places it’s like the top <1% of IC engineers, others are probably even more lax than MS.
- denton-scratch 4y agoThanks for explaining! The last time I was involved with job-title hierarchies (a long time ago), nobody was a programmer, everyone was an analyst. The people who did telephone support were called support analysts. I graduated to senior sales support analyst (roughly, doing random free work for the prospect, to close a sale). We assumed we were superior to "engineers": they were the guys that swapped-out hard disks and cards, twiddled the fuses to do performance upgrades, and lifted heavy boxes. We were better-paid. I think of them in boiler-suits, but actually they wore business suits like me. I liked the engineers. [Edit: I guess maybe the difference might have been that we (analysts) had degrees, and they didn't - they got lots of training on the hardware. The attitude "we" had was obviously degree snobbery. I say "we", because the engineers were regarded rather as I would regard a gas-fitter, by just about everyone.]
- lxe 4y agoThe Solver archetype and mindset if often overlooked and unrewarded in large organizations where staff level engineers are expected to be bogged down either with "strategic" work, or other high level bureaucratic shenanigans. If you're a "solver", the trick is to meticulously gather metrics about the impact of your work, and always put them front and center when you communicate about what you've achieved.
- renlo 4y agoWhat about the archetype Staff Software Engineer who’s good at creating a promo packet but not good at much else? They come into an org, replace some open source / well-documented well-built tool with an undocumented poorly working tool, then they convince other org members to use this new tool as they actively disable or undermine the existing tool. Come promo time they now have a line in their promo packet “built new tool, drove adoption of said tool to 80%”. At the last company I worked it seemed like a good many of the staff engineers were like this, though may be just the symptoms of a company with braindrain.
- siliconc0w 4y agoother possible types: 0) the wizened emeritus engineers staffed with special 'futures' or 'next-gen' bluesky type projects 1) engineers who may not be overly technical anymore but are really good at negotiating the organizational hierarchy and might know where and how to poke and pull at the cybernetic organism to nudge it in a desired direction
- davidthewatson 4y ago> Right Hands often dive into a fire, edit the approach, and delegate execution to the most appropriate team, and then pop over to the next fire elsewhere in the organization. > The Solver and Right Hand bounce from fire to fire, often having more transactional interactions with the folks they’re working with on any given week. It's worth noting that Ben Purgason from LinkedIn, identified Firefighters as stage 1 and beyond throughout his article on the five stages of SRE: > At this early stage, SRE is essentially fighting fires whenever the need arises while simultaneously trying to automate the process of fire suppression. With each piece of reliable automation written, the time saved on fire suppression is freed up for use on permanently fixing problems or for forward-looking priorities such as monitoring and alerting. https://www.usenix.org/system/files/login/articles/login_winter18_02_purgason.pdf https://www.usenix.org/system/files/login/articles/login_win... My observation has been that problems arise when you have roles that clearly default to firefighting without the larger organizational recognition that this is a signal that the default mode need to evolve or improve continuously. That is, that the stages beyond stage 1 (firefighting) that involve developing the roles, teams, tools, and ops in concert with one another are latent and need to scale with the organization, products, services, and customers.
- joshuamorton 4y ago"Firefighting" is being used in two different contexts here. In the SRE document, it means literal incident response, while in the Staff Eng context, it means "addressing whatever the organizational P0 is", which may occasionally be a literal incident, but it may also be developing an incident response team, or lending a hand to a project that is behind schedule, or...whatever. There's always something that is highest priority, and having a floating person(s) who can continually identify and provide support for whatever that thing is isn't a sign of a dysfunctional organization.
- davidthewatson 4y ago> "Firefighting" is being used in two different contexts here. In the SRE document, it means literal incident response, while in the Staff Eng context, it means "addressing whatever the organizational P0 is", which may occasionally be a literal incident, but it may also be developing an incident response team, or lending a hand to a project that is behind schedule, or...whatever. Good point. That's right. > There's always something that is highest priority, and having a floating person(s) who can continually identify and provide support for whatever that thing is isn't a sign of a dysfunctional organization. Yes, I do think that "floating" is an appropriate term here. I've also seen "consulting engineer" used in this context within large multinational organizations. However, I would point out that too much floating may be a sign of diminishing returns on matrix management.
- vsareto 4y agoThese archetypes seem like they should have different job titles except for maybe Solver. Additionally, what differentiates a Staff Engineer who's a Team Lead archetype from someone that's a TeamLead? Overloading the Staff Engineer title with these archetypes is going to lead to identity confusion in the job hunting landscape. If you're searching for Staff Engineer positions by title, now you need to figure out if your personal archetype matches what they're looking for. You might be able to get it from the posting, but maybe not. This also confuses salary bands. You might have some really effective management type Staff Engineers making loads of cash because they're management, but someone who's just a Solver might be on the far lower end of pay because they aren't management. These examples might be reversed if the Solver is able to solve really hard technical problems.
- quickthrower2 4y agoSalary is always going to be confused world. People can often earn more as a graduate than a senior by moving to another company or country. Within an org it is hard to measure everyone's true contribution. People's salaries may reflect the job market when they joined. So someone who joined recently gets paid more for a more junior position than someone who has been at the company for years. The company needs to keep salaries secret to avoid people getting annoyed at this! Companies are now also completing for staff not only with other companies, but with investors! If someone is capable, they could go off and start their own thing too. They are also competing with FU money that people have built up. The desire to control this with titles and bands makes me laugh. Obviously big companies need to do this though.
- sbf501 4y agoMozilla had some interesting archetypes. I only recall two because I didn't work there, but they were Wizard and True Believer. They all seemed to be more apt archetypes than standard job progression ladders because they allowed for more diversity than just 'manager' and 'technical' paths. I applaud the attempts even if they do seem a tad cringy.
- cebert 4y agoThis was a great read. I think there may be a 5th archetype for individuals who help enable others with “glue” work. This work can easily go unnoticed, but can have a dramatic impact on individual and team productivity.
- lamontcg 4y agoI'm pretty sure I've worn both the Team Lead, Architect, and Solver hats at the same time.
- quickthrower2 4y agoAt small companies you will, and you might still be just plainly titled "Software Engineer".
- lamontcg 4y agoPrincipal Software Engineer, but yeah.
- lhorie 4y agoA little meta commentary: I'm seeing a lot of negative takes using the word "they" (so presumably these are from people who either haven't worked in a staff eng capacity, or have, but in dysfunctional organizations). The intent of this article (as I understand it) was to help people navigate the emerging nebulous role that "staff engineer" was, particularly as it started to become a more mainstream concept a few years ago (whereas prior to it, the dichotomy was largely that senior was "the" terminal IC role and you had to transition to management past that). Many engineers on the upper side of the senior spectrum have clearly been operating above and beyond what is typically considered senior level, but not in the capacity of a typical manager archetype, so this was meant to help people understand how to identify/categorize these people as well as help people understand what kinds of challenges to look at after you've become a "full-fledged" senior engineer. Resources are useful, whodathunkit. My advice for those eyeing for a staff+ level would be to avoid making "hot take" categories, everyone can do that and if they're coming from a position of inexperience w/ the subject matter, there's a good chance it's a bad take. Instead, try to derive action items from each of the archetypes, and incorporate those into your work. A good point I heard is that no staff engineer qualifies as a single archetype exclusively; the role is usually a mix of all archetypes, with different people leaning more strongly one way vs another. It's very easy to make sour comments like "oh staff people just spend all their time in meetings, what good are they for". It's quite another to be that staff engineer and have to balance technical depth acquisition, alignment among disparate groups and the multiplexing required to operate at high levels at both. It's easy to chalk it up to politics, but it's quite another to be able to visualize power structures as tools, and use them as such to accomplish large scale engineering goals. There are classes of engineering challenges that only really arise at the staff+ engineer level, and engaging with them can be rewarding in their own right.
- YorkianTones 4y agoAre staff engineers needed? The role seems like a relatively new invention. Senior and midlevel IC engineers do the heavy lifting, principals set strategy and define architecture, EMs manage engineers, PMs manage product. I'm not clear on what the role of the staff engineer is and why it's needed.
- bsenftner 4y agoIn VFX and animation production there is a "firefighter" position similar to the Staff Engineer: a senior level developer unassigned to a specific project, able to float as needed and provide support and solutions for other projects that need spot senior level support. At some studios this role goes to sr. and lead developers whose projects are canceled/halted until they can be reassigned. At others, it's like a mini-sabbatical for sr level technical staff that would otherwise leave, but the company does not want them to leave.
- aaronblohowiak 4y ago>principals set strategy and define architecture, staff is sometimes used on road to principal, in some firms there are no principals but just staff, etc. i think _generally_ the industry is doing swe, sr swe, staff, sr staff, principal sometimes there is no sr staff, sometimes there is no staff and just principal, sr principal...
- ZephyrBlu 4y agoA big function of Staff engineers is working across teams. Cross-team communication and alignment is difficult.
- flir 4y ago"Teacher" is one that's missing IMO.
- winphone1974 4y agoThe 10x developer isn't someone who crushes 10 times as many tickets, or works 10 times as fast, they're someone who makes a large number of people marginally better while their peers focus soley on their individual contribution. It's both surprisingly easy to accomplish and sadly under recognized (or even actively discouraged)
- iancmceachern 4y agoGreat, putting people in buckets/boxes. Never helpful.
- meechi555 4y ago
- deleted 4y ago[deleted]
- jackblemming 4y agoIs there an archetype for programmer who does their damn job instead of bloviating at how elite they are because they read a few Martin Fowler or management books, or is it hard to spin that into a narrative worth high six figures?
- therealdrag0 4y agoI think you’re missing the point. It’s not about eliteness as much as role. If you can imagine a difference between a edge manager, a director, and a ceo, then you should be able to imagine differences between mid, senior, and staff engineers. Having these distinctions help clarify exceptions from both consumers of the employees work and aspirers who want to do a certain type of role or not.
- Ava4312 4y ago
- deleted 4y ago[deleted]
- socialismisok 4y agoI'd add "The Gardener". The gardener just wants to tend to things, taking thankless cleanup work and iterating away on it. Ops, metrics, tech debt, ACLs, pruning dead code, etc. Some people just like to organize and clean things up.
- dilyevsky 4y agoMost orgs would not consider this staff-level work. Doesn't mean you shouldn't get your hands dirty every once in a while and it could even be helpful for "dogfooding" purposes but if that's all you ever do that's not Staff.
- bombardier6789 4y agoYes and no. I have been asked if staff engineers are around so that they can pick up projects noone wants to do. This entirely defeats the point of staff engineers. I would want my staff engineering bunch to either pave the path or mentor the teams to do it themselves. Making it easier for the teams and future engineers could be a better strategy and effective multiplier. If there is organisational mission critical software lacking any of this then it is a p0 and I would count it under high impact work rather than gardening. Besides depending on company size, some of those responsibilities should belong to platform teams.
- nuker 4y agoThe Right Hand is NSFW
- ki_ 4y agoThe "pattern coder", applies design patterns the all parts of his code without really understanding why. His trust in authorities such as people that give tech talks are the only reason needed to why his coding style is good. This person often ends up with very slow code that no one can modify or debug because his hello world function uses 200 sub-functions spread over 400 files. A common speech pattern of this archetype is "This is how you write stable/mantainable code". Edit: Just noticed it's only about "staff"-engineers. I wondered why there were only 4. However, i think the "solver" isnt part of the staff either.
- bombardier6789 4y agoAlthough this is a generalisation of overall population in few buckets, it helps people understand what it is really. You can assume different archetypes at different times. That's the best thing about being staff. The staff engineer is a clear leadership role with expectation to perform each of these archetypes at varying degrees. The person might prefer to be one of these archetypes but doesn't shy away to pick up others if the situation demands. Of course, they and people in their vicinity would want to play their strengths.