21–30 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.
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.
One 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…
But I'd call this person The Wolf (named after the Harvey Keitel's character in Pulp Fiction.
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.
only code matters is a stretch but generally agree. If you can fix whatever shit is thrown at you, you have my ultimate respect
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.
Tell that to the person writing my paychecks.
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.
It doesn't matter what you call them, they've always been there and always will be. Unless your engineering org is not run by engineers, in which case, you should join a company that has staff engineers :)
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.
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.
Providing technical leadership is weird and makes people hard to rely on?