Comment by lhorie | Hacker News Reader

Comment by lhorie | Hacker News Reader

Parent Full thread

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

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.

The secret is — when you’re a senior IC, if you think that it’s important to spend 2 days a week coding, you’re expected to tell people to fuck off so you can spend 2 days a week coding.

Imo, the politics is the design.

Who is going to pay for what? Who's responsible for when a certain part goes wrong?

If you figure out the politics well, you've mostly constrained the system design to something straightforward

Or, you built a poorly architected piece of software that replicates your organizational structure.

It's basically a law of the Universe that your software will look like your org structure. You have to treat it as a hard engineering constraint, just like you'd treat seek latency on a spinning disk, or the speed of light between two data centers. You can't increase the speed of light, but you can still function. Treat org constraints like that.

Or, you build a well architected piece of software that replicates your organization structure if the people (director+) who are in charge of the org structure do their jobs well.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

— Melvin E. Conway

I guess the trick is to flip this by modeling your organization to the system design (i.e. create teams around the components of the system, not components around pre-existing teams). This is easier said than done, and as architecture changes one needs to adapt the organization structure...

it's not a complete solution, as 1/I've seen this cause games of musical chairs happen that essentially stall the work and 2/ creating silos make cross-cutting concerns fail to be addressed...

Hahaha. Perfect.

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!

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.

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

Or Architects

In systems: Politics is as much a constraint as budget, and technical constraints.

If your manager will not accept way X. It really doesn't matter if X is optimal. You'd better find Y, or convince the manager.

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com