Staff Engineer Archetypes (2020)

I think as systems get more complex and bogged down, it's harder to innovate. As innovation is stifled by build problems, dependency problems, political problems, operational problems, the amount of code you have to read to do anything problems, etc, I think engineers start to say "could I be more productive, and therefore theoretically get more reward, elsewhere?"

I think as soon as the innovators start to jump ship, growth momentum is lost and it's nearly impossible to regain that momentum. Who does interviews? Who sells candidates? What is the marketing? What kind of sense of morale will potential hires perceive?

If a large refactoring project did take place, refactoring projects are generally very high risk and low reward. That is the type of project that most senior devs will avoid like the plague. It is not fun engineering. It is drudgery and toil.

So a history of poor software results in required cleanup/developer pain, which results in high value devs leaving for greener pastures, which results in a perception of high inertia non-growth, which then makes it harder to sell people on the prospect of "high growth" stocks which results in the tanking of average dev quality (and morale for that matter), which then makes it even harder to hire innovative devs or leadership, which ultimately results in stagnation.

Senior leadership, both managerial and technical, will play hot potato until the costs of not addressing the real, highly unpleasant, problems is too high and by then its too late. Things continue to get worse between the start of the effort to fix problems and the actual fix of the problems and a lot of people will choose not to suffer that.

I didn't work at twitter, but I watched this process happen. To me, there is a clear relationship between systemically unaddressed and festering technical debt and ability to innovate with direct personnel consequences.

> I bet no one has said that if only Twitters software was better it would gain more customers and advertisers.

But whats the cost of setting up a new service? Of creating a new interface? Of testing a new feature? Of creating a new payment system, etc. All of these are software problems. How efficient would an organization be if every team had their own repo? If every team had their own monitoring systems? If every team implemented their own release process? If every team re-implemented the same behavior over and over again because higher up leadership couldn't allocate resources to problems that every team has, what effect does that have? That inefficiency is innovation opportunity cost.

Imagine you acquire a company you think can provide an innovation to your own. What is the time/resource cost of integration and what effect do you think dev environment would have on success of the acquisition?

I think technical debt clearly has compounding interest. I think companies get into a position where the debt becomes debilitating particularly through pathological short term thinking. At some point the compounding technical debt exceeds growth and it's over.

Yeah. A few years ago the zeitgeist was "principal engineers" and then it turned into "staff engineers" and then "staff+".

As the GP said these titles have existed for a long time. But for whatever reason there's also been a progression in terms of them being super common in social media discussions.

The cynic in me says that it is driven by a certain subset of Internet Famous Devs progressing through their career.

I would add to this; that a certain amount of bad abstractions are preferable to underdoing it. The learning from failure (when there's sufficient investment in the outcome) is far more valuable than avoiding inefficiency.

Learning better ways is a process - so long as you remain robust in the face of failure and grow from it.

Most people think it's the people that are special or underperforming, but my view is probably a bit more contrarian. I think that some environments work in such a way that only a few can succeed while others make success possible in a network effect or on more manageable scale. I don't think that environments that produce the former really mean to; rather I think it's the leaders that are unable to craft incentive systems, pool resources, or effectively communicate that end up creating these kinds of ecosystems. It's really a fundamental misunderstanding of the people part of the job, which turns out to usually be the hardest.

If these 10x engineers really exist, they're rare. Building an engineering department with this type of employee isn't sustainable.

In 20+ years I've only worked with maybe 2 genuine examples of the good 10x engineer, and far more examples of the bad "10x engineer" who flies around quickly reimplementing patterns that they implemented at other companies, whether they're suitable or not. Once the low-hanging fruit is all gone and only the hard stuff (and hubris) remains, they leave. Usually, after getting pissy because other engineers have inherited their crap have started pushing back and questioning their design choices. I've inherited systems built by people like this and it's not pleasant.

You also better be willing to hire constantly if you want a few more 10xers in your back pocket. If hiring a regular "good engineer" is hard, then hiring one of these is harder. You need to find them, convince them to interview, present them with an interesting challenge, have a great interview process that separates wheat from the chaff. And finally, pay them a ton and don't let them burn themselves out

Oh, and admit that replacing a 10x engineer is going to be basically impossible, not just because it's hard to hire them, but because each one that leaves your takes far more experience and knowledge with them when they go (than the 1x engineer). If the 10x moniker was really accurate, it would be like losing a team of 10.

Sometimes it's better to have a reliable team of 6 engineers in at least 2 timezones who get along well, sync up once a week and have a really good lead/manager. This is sustainable, easier to hire, onboard, retain. And less detrimental if you lose one.