4 ms·

Anybody in their 40s or older has valuable experience above and beyond ephemeral value of “Hitting the ground running with Cabbage and Sprouts containerized wit

Anybody in their 40s or older has valuable experience above and beyond ephemeral value of “Hitting the ground running with Cabbage and Sprouts containerized with Cuper9s using ES2020 and JSxyz.” One way to deliver that experience is in delivery management, that is, being responsible for teams that ship stuff. Another way to deliver that experience is in people management. Not all companies equate this with the previous responsibility. A third way in in a more nebulous “leadership” role that doesn’t have “manager” in the title, e.g. “Architect,” or “Principal Engineer.” The latter is tricky, but can be a very good opportunity. 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. - - - FWIW, I am 57 and a Principal Engineer with PagerDuty.

o_____________o 7y ago
> 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
- vikasg 7y ago
  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.
- alexgartrell 7y ago
  It's also been my experience as an engineering manager that it's best to think of yourself as a manager without authority.
dfsegoat 7y ago
> "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?
- toadi 7y ago
  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 :)
donavanm 7y ago
> 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.
- james_s_tayler 7y ago
  Sounds ideal. Do you code much still as part of that?
  - donavanm 7y ago
    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.
    - james_s_tayler 7y ago
      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.
      - donavanm 7y ago
        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.

o_____________o 7y ago

> 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

vikasg 7y ago
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.
alexgartrell 7y ago
It's also been my experience as an engineering manager that it's best to think of yourself as a manager without authority.

dfsegoat 7y ago

> "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?

toadi 7y ago
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 :)

donavanm 7y ago

> 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.

james_s_tayler 7y ago
Sounds ideal. Do you code much still as part of that?
- donavanm 7y ago
  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.
  - james_s_tayler 7y ago
    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.
    - donavanm 7y ago
      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.