> My 2c on being in engineering leadership is that it’s best to think of yourself as a manger without authority, rather than thinking of yourself as an engineer with authority.

Im a principal at AWS. A coworker made a joke that resonated with me; a principal engineer is a manager without direct reports.

My job is twofold. Helping managers understand where to go. Helping ICs and teams to get there. I have no inherent authority and it all comes down to trust and influence.

Sounds ideal. Do you code much still as part of that?

Not as much as Id like. But that generally comes down to prioritization and the broad autonomy & area of responsibility in these roles. The self reported survey data of time spent is that principals are doing direct delivery 12% of the time median and 20% average.

That said there does seem to be a push to reemphasize the ‘exemplary practitioner’ aspect and scale back on the high level “architecture” and pseudo PM aspects that creep in with expanded scope.

Thanks. I really appreciate the reply. It matches with what I thought might be the case. I've taken on a more senior role lately as my career progresses and I'm finding I'm spending only half my time doing direct delivery and the other half doing project management type work and coordinating changes across teams etc. I love the autonomy that comes along with it but I'm so used to the idea of getting paid to cut code that when I don't cut as much as I used to I feel like I'm not keeping up. Reality is I'm busy with other stuff and I'm learning to just accept that more and start to lean into it.

You’re welcome. My advice would be to keep the development up, but focus your efforts where they make the most difference. When it comes to grinding LOC, and even defining entire components, that’s what you have a team for. Trust them to do the needful, or intentionally lead by example until they can. Spend your dev time discovering/removing the complexity or laying the groundwork for the bulk of development to follow.

> "A third way in in a more nebulous “leadership” role that doesn’t have “manager” in the title, e.g. “Architect,” or “Principal Engineer.”

As a technical lead (getting into my 40s soon) I try to think of myself as an chief enabler / support net: Let the team figure out implementation, support them as they go where they get out of their depth - and protect them from DIRECT trickle down BS/interruptions from management or clients.

This has worked pretty well for me thus far, but I've really got no idea if this is a solid approach or way of thinking.

I'm curious to know anyones thoughts?

43 here and I was a CTO in my own startups that provided me a nest egg. Done Digital Transformation Coaching for a big chunk of it. But my last employer hired me after 1 year contract of doing this as tech lead. Much to my amazement because I don't really consider myself a good engineer, I'm just good at solving problems and was able to deliver stuff. Most of the times it isn't always as pretty as it should but people are happy. Except when I get those nasty job interview algo questions which I mostly bomb.

I'm actually a Vice President without any direct reports. I'm on the same level as the head of software delivery on the organigram. See myself as chief enabler too. Fixing architects disillusioned designs and try to explain to developers how to implement these designs. Sometimes I dabble doing some POC. Good thing is that I don't have people management bullshit, downside is that this is my glass ceiling if I stay here :)

> it’s best to think of yourself as a manger without authority, rather than thinking of yourself as an engineer with authority

That's great, and resonates

Andy Grove talks about this in "High Output Management". He says there are two kinds of managers, "know-how" managers and "position" managers. Both have a certain amount of authority, and a successful technology company needs both.

If you're a senior enough person who doesn't want to manage people, you should think of yourself as a "know-how" (knowledge, experience) manager and find a role that allows for that.

It's also been my experience as an engineering manager that it's best to think of yourself as a manager without authority.