11–20 of 269 posts
the 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.
the 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.
the 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.
This is largely dependent on the company in my experience. I've been a Staff at one company where I had to actively protest meetings. I would get in trouble for not showing up. I had to point out several times that 1-2 hours a day of non-meetings was not enough to be effective no matter what level a person is at.
At other (typically smaller) companies, I do feel like Staff engineers can really have a multiplying effect. Based on the OP, I personally fell into "The Solver" category and would bounce around helping out teams who were stuck on something particularly troublesome.
> are they really essential to the success of large engineering orgs
I don't about know this one. In a large org, I was at my most ineffective. I do think they are essential to small-to-mid sized engineering orgs though, even if it only means they help out by knowing all the ways *NOT* to do something.
>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
Sounds like a right hand.
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.
the 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.
I'm also the one that sets certain best practices in code repositories, and I've learned that identifying a best practice and assigning it to someone else to introduce doesn't work very well. At those times I have to dive into the code, restructure things, and then present, so that the other coders can actually refer to it as an example. This in addition to helping team members know what is in-bounds and out-of-bounds for their story, and helping with code reviews. This is roughly the "tech lead" role. This has some sort of force-multiplier impact just by doing things like guiding the metaphorical ships away from the metaphorical icebergs.
Finally, there's the classic "architecture" role, where we identify tech paths for the org in general. Recognizing when a well-targeted effort can replace an inefficiency with something smoother. Like I had to take it upon myself to set up elasticsearch and kibana correctly, and structuring the code to report the correct dimensions. Or structuring how our graphql queries worked so they didn't pound our graphql server. Or placing an in-memory cache on one layer of servers (this basically saved our launch). That's also stuff where it's hard to calculate "force multiplier".
So I dunno. I'm talking about an eng organization of 50-100 people, so maybe that's not big enough to be valid for your question. But the point is that while the role is necessary and is a "multiplier", it's difficult to calculate because it's not as simple as just being 5x or 10x faster than another developer for a well-defined task.
Avoid 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.
the 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.
Avoid 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.