[vii]

Some of this advice is great, like getting out of the way, guiding people with how to think about trade-offs and doing daily coding. But it doesn't feel like 'Principal' level advice, at least in terms of Big Tech and the blog notes the author isn't sure what the distinction is with Staff.

The author complains that it's hard to be in the critical path at a senior level. This lacks self-awareness. It's always hard to be in the critical path. Shipping on time is one of the toughest deliverables of the software engineer role, and one that many people struggle with. Accurately estimating development costs including wall time vs. actual time someone has to work on a project is a very important skill. It's not acceptable for senior engineers to abrogate responsibility for this, especially if they claim to be mentoring other engineers.

Senior engineers own the business outcome and must weigh costs of all kinds, from security risks to technical debt. As scope increases, the feedback loops get longer and longer. A new engineer can tell if they did well with a comprehensive unit test. A junior engineer can tell if they did well with a performance or integration test. A senior engineer can tell if they did well with an A-B test in the market. A staff engineer can tell if they did well by seeing market share grow.

In Big Tech, senior staff and principal roles carry the idea of doing something to 'shock the world' - that is, successfully shipping innovation that people were afraid to, for example, because it seemed risky. Greasing the wheels of communication between teams and helping people avoid common mistakes is fine and a good thing. But there is limited business value in building consensus around the latest "architecture" or framework or language or whatever, however nice it feels to enjoy the social status as the person turned to for this kind of question. Step change innovation is the real value add and this article hardly touches on it.

[proc0]

> A senior engineer can tell if they did well with an A-B test in the market. A staff engineer can tell if they did well by seeing market share grow.

I don't get this, these are marketing and business skills. I don't understand why tech roles don't leverage the full power of engineering and instead engineers are steered towards tangential specializations. This isn't true across the board of course, but how can companies not see the value of letting some engineers become the technical experts without needing all these related skills? Knowing advanced CS and information theory can help, if anything to keep the other engineers up to date (and I think it would involve technical leadership, just not in terms of managing others), but it's not valued at all and without those other skills it seems engineers just stay as "contributors" (i call this bottom feeders).

[antonmry]

Interesting feedback, thanks! What I describe in the article are the challenges of the role based in my experience. What you describe it's the business as usual work. Innovation, deliver and push key initiatives, etc. are the reason to be promoted to Principal in first place. They are important but they aren't what I find more challenging in the role.

[astrange]

Do the architects actually… build things? The description of the work there is more like a program manager. Which is an important organizational job which doesn’t have any power, but also isn’t the person doing the work, and so doesn’t have the understanding to design it.