> TBH, reading this as a manager, I have to admit I feel like asking my engineers to take on SOME of these beyond-just-the-code duties... is a good thing? Obviously there are a bunch of caveats, and nuances to whether you want an IC engineer to be 100% coding and 0% talking to customers or doing admin (this seems bad), or is it 90% vs 10% (maybe okay), or 80/20 (sweet spot?), 50/50 (concerning), 20/80 (bad again), etc.

1. Agree 100% coding and nothing else is bad most of the time. You can leave out admin tasks but engineering is more than just coding, it's problem solving. Understanding requirements (e.g. by talking to customers) is crucial and also the best code is the code that had to be never written.

2. Think that is also in large part an individual thing, some people like to wear multiple hats to some individually varying degree while others don't.

3. It must work out in practice and you have to make sure the sum of both does not result in a value above 100%

4. I agree if the technical stuff is as low as 20% it may be better to just transfer in another role completely as it is hard to contribute meaningfully there then.

... and 5., try to avoid duties which involve a huge amount of smaller interruptions over the day.

I agree most engineers should be doing SOME things beyond code-centric activities. There are things that almost nobody, whether they're an IC or people manager, wants to have take up their whole day. That requires spreading them out across staff.

Problems arise when that work isn't assigned out explicitly, evenly, and thoughtfully. Sometimes there's important work that isn't really assigned to anybody, and it can end up landing with whoever is least willing to ignore it. Over time, that can lead to situations that feel (and/or are) unfair.

Ask them.

Some engineers just want to do engineering. Nothing else. But more often engineers will be happy getting involved with the customers in some way, or working to improve some process they don't like, or some even love doing documentation.

Best thing is to bring up options and ask if any of them sound appealing. Letting people choose their work generally gets you stronger buy-in to what they're doing.

Same. As an IC I like ownership. I'd be fine with most of that list assuming it was related to something I owned. I may not specifically like some task, but I'm fine doing it if it's because I'm the person responsible for something.

The biggest issue I would have with that list is the description of the scrum setup, and being directly assigned tickets. I find it more engaging if I'm given or find bigger problems to solve, completing individual tickets isn't as interesting.

Yes I love ownership as an IC.

It's more that I spend near-zero time on any coding anymore, but also have very little visibility into the wider strategy (because there kind of isn't one).

So I am tasked to have work for my customer(s) / 2-3 devs on loan to me, planned out for a few months. However my manager doesn't really give us what his quarterly goals are most quarters. Product team doesn't publish them very often either.

In order of time spent in applications top to bottom it looks something like - Zoom, Slack, Email, Jira, Confluence, Sharepoint, Gitlab, VSCode.

Right, I'm rather experienced and make many multiples of 50k/yr, so its not really a compensation thing.

It's more that it feels very ephemeral / tenuous as none of it is in an org chart or official. It is basically what problems management has to solve and what seniors are available at the moment.

I am, officially in title and org chart an IC. In reality 10-20% of my time is IC dev work. 6 months ago it was 50%, 6 months before that it was 0%.

Further it feels like too much of a time split to really get any better at any of the aspects - software dev, tech lead, product, people management of this role.

What does this look like in FAANG?

It can be better, but it also can be just as chaotic sometimes. On balance overall, FAANGs are probably better at managing this "IC utilization" rate if you wanna call it that, vs just randomly expecting you to pick up and wear all the hats all the time or that hats are chaotically assigned, with no plan behind it. Certainly FAANGs aren't perfect, but at least it's easier to find "reference implementations" because there certainly are some very high-performing and well-managed teams, and if you're not on one yourself, then you can at least have the benefit of being able to see-and-compare, which then provides a potential for betterment and learning from others (which might be harder in non-FAANGs).

Right, I like the term "IC Utilization Rate". I think for me its the chaos of the hat wearing. I went about 6 months doing pure project management with 0 leadership or development work.

I periodically go long enough with 0 hands-on dev that stuff in the SDLC has changed again. So I have to go poke around and figure out why my commit message formatting is rejected, which teamcity instance we are using now, and what QA box I should be testing on.

Also the unmentioned part for me is that while 10-20% of my time is Dev at best, 50% of it is high urgency fires I am brought in to extinguish because I have the most knowledge of that part of the code base and can ship whatever improvement in 1-2 sprints without needing to spend 2 sprints on analysis first.

I'm just a senior IC, and not at FAANG. But my employer does recruit from FAANG. 0%-20% sounds low for dev work, but the basic description looks somewhat familiar. We don't have project managers, and not all teams have product managers, so seniority can get you more of that work, and less dev work. I don't think ICs do managerial people management if you don't include mentoring. And I do know one or two directors who still code a lot. Maybe some FAANGS have senior positions with more IC dev work.

They do, but it's vastly easier to get promoted to those levels as a manager, because the organization needs managers to function, but super senior ICs are less critical.

For me it mostly depends on management staffing levels, if I'm in a standup with more management/business folks than developers I don't expect to spend a lot of time handling that side of the process, especially if we aren't in a place where we are stable from a technical perspective or have deadlines looming. On the other hand if I'm just directly reporting to a single person I'm much more open to lending a hand and pick up a lot of stuff.