7 ms·

There are two different career tracks, namely IC (individual contributor) and EM (engineering manager). The latter revolves almost entirely around people manage

by lhorie 4y ago

There are two different career tracks, namely IC (individual contributor) and EM (engineering manager). The latter revolves almost entirely around people management. For the IC track, I've found this writing[0] on staff engineer archetypes useful. The gist is that there are archetypes that involve a lot of people management, but there are also some that are highly technical / coding oriented. One analogy that comes to mind is wuxia/murim novels (i.e. stories set in ancient times east asia, involving martial arts sects). Among the strongest characters, there's the sect leader type that is involved in politics most of the time, but there's also the recluse master training in the mountains type. Naturally, there's also plenty of characters clinging to titles, overconfident fools, etc. I think this analogy is interesting because there's a clear parallel between the two worlds in terms of how titles are perceived, the craft that they purport to represent, and their place in the world. Titles can represent both status and mastery, but only loosely at best, the craft can be honed irrespective of both titles and the state of the world, and it's only through increasing a sphere of influence that one can have a sizable impact in the world and its citizens. [0] https://staffeng.com/guides/staff-archetypes https://staffeng.com/guides/staff-archetypes

tkzed49 4y ago
Yeah I mean this is a cool concept assuming that you get to choose which "archetype" you progress into, rather than it being dictated by the organization you're working in. It's less cool when you get forced into the people management archetypes, which I feel are way more common in many places, because of the natural progression that GP described.
PuppyTailWags 4y ago
Something to note about leader-types and recluse-types: the recluse-types very rarely if ever have influence over the broader org, and if they do, only in limited critical circumstances unique to them (often in the enablement of critical leader-types). I think this is critical to note because an additional complaint by many senior engineers I know of is that they don't have enough influence when managers make dumb decisions or their opinions about the direction of the product aren't valued more than less-experienced product people. That is to say, I don't think the deliniation between IC and Manager work in practice because the influence of even a lower-level manager will often supercede an experienced IC, much to IC chagrin, except ICs also don't want to be in all the meetings managers are in where such influence is exerted.
VyseofArcadia 4y ago
I have been a senior IC. I spent no time training in the mountains by myself. I spent all my time in meetings attempting to do system design but actually just getting bogged down in politics. There needs to be a third track. IC (training in the mountains), EM, and IC (planning and design). A lot of orgs would call that last position a PM, but I have never worked with a PM competent enough to actually carry out that kind of work without ICs stepping up to do most of the PMing themselves. In my experience, PMs are the corrupt bureaucrats that serve as antagonists in wuxia stories.
- zamfi 4y ago
  In many of these organizations, PMs serve to insulate the "planning and design" ICs from conversations with customers. Not ideal either, IMO, ICs involved in planning and design should get out there and talk to customers themselves!
  - scruple 4y ago
    The most successful software project I've ever worked on, in terms of our utility to the business and our customers, as well as personal satisfaction to the team members, was one where myself and a technical PM handled "planning and design" in lock step with each other. My (former) management tried to build a template out of our success and failed, horribly, because you cannot account for the personalities that sit behind these titles/roles.
    - glomgril 4y ago
      > you cannot account for the personalities that sit behind these titles/roles. This is an important point, and should be more obvious than it is. Projects succeed or fail more as a function of individual personalities than of whatever their job titles are. Easy to forget given that people who share a job title are usually treated as interchangeable components of the machine (at least in big companies and at least in my experience).
  - jacobr1 4y ago
    Or Architects
scruple 4y ago
Starting in 2018, I was a tech lead (at the time, my title was Senior) for 2 teams spanning ~4 years. I have a Staff title today. Here's my problem with these roles. Going by the definitions from Will Larsen in your link, I am currently expected to be: a tech lead, an architect, and a solver. I engage primarily with tech lead and solver work. I also frequently have to dig in to "regular" IC work tickets. No single individual has the capacity to do all of these things well but the business will see you succeed in some degree with tasks associated to these different roles, fail to recognize that these roles are distinct from each other, and unrealistically expect you to do it all. I am working with my management on this problem, specifically about expectation setting (because it's a mess, everyone, and I do mean literally almost everyone, has a different idea about what my role confers), but it's frustrating.
- tunesmith 4y ago
  Yeah, you've described my challenge exactly. I'm all three and it's annoying. My title is Architect or Principal Architect. Boss sees me and uses me as Tech Lead across multiple teams (and the teams have really needed it). For me it's more about coding standards, best practices, and education than it is about interpreting product needs into stories - we have others for that. Boss's Boss doesn't appreciate that stuff and wants me as Architect, which puts them into battles. And in practice, I get pulled off both to be Solver - they call them "emergent issues", and the hard ones come to me. There isn't anyone technical above me that I can ask for help. Meanwhile I get dinged at quarterly reviews by our scrum-master for not having a predictable velocity.
  - gtirloni 4y ago
    Story of my life. Please please let us know if you ever come to a satisfactory solution. I'm starting to take my head of the sand about this now, finally.
  - dalyons 4y ago
    Tell your scrum master to go jump (or even better don’t work anywhere with a scrum master). If your title is principal architect, then the business expects different things out of you than story points.

by lhorie 4y ago

tkzed49 4y ago

Yeah I mean this is a cool concept assuming that you get to choose which "archetype" you progress into, rather than it being dictated by the organization you're working in. It's less cool when you get forced into the people management archetypes, which I feel are way more common in many places, because of the natural progression that GP described.

PuppyTailWags 4y ago

Something to note about leader-types and recluse-types: the recluse-types very rarely if ever have influence over the broader org, and if they do, only in limited critical circumstances unique to them (often in the enablement of critical leader-types). I think this is critical to note because an additional complaint by many senior engineers I know of is that they don't have enough influence when managers make dumb decisions or their opinions about the direction of the product aren't valued more than less-experienced product people. That is to say, I don't think the deliniation between IC and Manager work in practice because the influence of even a lower-level manager will often supercede an experienced IC, much to IC chagrin, except ICs also don't want to be in all the meetings managers are in where such influence is exerted.

VyseofArcadia 4y ago

I have been a senior IC. I spent no time training in the mountains by myself. I spent all my time in meetings attempting to do system design but actually just getting bogged down in politics. There needs to be a third track. IC (training in the mountains), EM, and IC (planning and design). A lot of orgs would call that last position a PM, but I have never worked with a PM competent enough to actually carry out that kind of work without ICs stepping up to do most of the PMing themselves. In my experience, PMs are the corrupt bureaucrats that serve as antagonists in wuxia stories.

zamfi 4y ago
In many of these organizations, PMs serve to insulate the "planning and design" ICs from conversations with customers. Not ideal either, IMO, ICs involved in planning and design should get out there and talk to customers themselves!
- scruple 4y ago
  The most successful software project I've ever worked on, in terms of our utility to the business and our customers, as well as personal satisfaction to the team members, was one where myself and a technical PM handled "planning and design" in lock step with each other. My (former) management tried to build a template out of our success and failed, horribly, because you cannot account for the personalities that sit behind these titles/roles.
  - glomgril 4y ago
    > you cannot account for the personalities that sit behind these titles/roles. This is an important point, and should be more obvious than it is. Projects succeed or fail more as a function of individual personalities than of whatever their job titles are. Easy to forget given that people who share a job title are usually treated as interchangeable components of the machine (at least in big companies and at least in my experience).
- jacobr1 4y ago
  Or Architects

scruple 4y ago

Starting in 2018, I was a tech lead (at the time, my title was Senior) for 2 teams spanning ~4 years. I have a Staff title today. Here's my problem with these roles. Going by the definitions from Will Larsen in your link, I am currently expected to be: a tech lead, an architect, and a solver. I engage primarily with tech lead and solver work. I also frequently have to dig in to "regular" IC work tickets. No single individual has the capacity to do all of these things well but the business will see you succeed in some degree with tasks associated to these different roles, fail to recognize that these roles are distinct from each other, and unrealistically expect you to do it all. I am working with my management on this problem, specifically about expectation setting (because it's a mess, everyone, and I do mean literally almost everyone, has a different idea about what my role confers), but it's frustrating.

tunesmith 4y ago
Yeah, you've described my challenge exactly. I'm all three and it's annoying. My title is Architect or Principal Architect. Boss sees me and uses me as Tech Lead across multiple teams (and the teams have really needed it). For me it's more about coding standards, best practices, and education than it is about interpreting product needs into stories - we have others for that. Boss's Boss doesn't appreciate that stuff and wants me as Architect, which puts them into battles. And in practice, I get pulled off both to be Solver - they call them "emergent issues", and the hard ones come to me. There isn't anyone technical above me that I can ask for help. Meanwhile I get dinged at quarterly reviews by our scrum-master for not having a predictable velocity.
- gtirloni 4y ago
  Story of my life. Please please let us know if you ever come to a satisfactory solution. I'm starting to take my head of the sand about this now, finally.
- dalyons 4y ago
  Tell your scrum master to go jump (or even better don’t work anywhere with a scrum master). If your title is principal architect, then the business expects different things out of you than story points.