As a senior IC in a super-flat & growing org.. I'm almost like a customer successs engineer, product manager, scrum master, senior developer and tech lead all rolled into one.
Management administrivia I accumulate administrative things my manager doesn't want to do & pushes down I do unofficially own a part of the team Dotted lines of devs in my "team" that can be rolled in & out sprint by sprint
Customer success / product / architecture I collect customer requirements, translate them into stories & documentation I manage customer/manager expectations with status meetings & reports I project plan out 3 months of work with JIRA hierarchies/Gantt chart I design solutions given the requirements
Scrum I run our standups, sprint plannings, backlog refinements
Corporate citizenship I am involved in recruiting 5-10% of my week I run working groups / long running cross team tech org
Development I do IC work - directly assigned sprint deliverable tickets (analysis, development, infra creation) I need to accomplish
I've been looking at moving to a more official management role elsewhere so I can focus at being good at a few things instead of decent at all the things.
This is also me. Except I really like it. But I'm not sure what to do about it, it can reflect super poorly on a resume for some reason.
"Oh, your applying to be a Senior Engineer? Look at all this product management and developer manager experience on your resume, you must not really be serious about coding, you aren't strong enough technically, the developers won't trust you"
"Oh, your applying to be a Product Manager / Product Director. Look at all this programming and tech experience on your resume, you are really just a developer, you should just be pulling tickets from JIRA/Asana/Linear, you probably wouldn't be able to speak in non-technical terms in front of customers/clients/etc"
(loop on repeat)
I've not heard of a job name/title/role that accurately represents this sort of work, even though companies generally seem to like it, if I can somehow get through their application process.
But that was only one project, so it doesn't really show up much in my CV. The main problem that recruiters have with me is that they don't know if I'm front-end or back-end, but I consider that a pointless distinction. I pick up whatever needs to be picked up, whether it's a single technical focus or everything else. (I'll even do infra if I really have to, though I'd rather not.) I like the diversity, but I also like to adapt to what the team needs.
If anything I find people tend to look upon varied experience as proof that you can add value on multiple fronts and across functions within the organisation, which should make you a slightly less common cog in the machine.
I think you will find that generalists are valued in extremely small orgs like startups, skunk works, spin-offs, and the like. Titles, when accurate, are likely to be vague (eg. Founding Employee). As organizations grow, roles tend to specialize, and generalists are undervalued, but reliable long term career success still tends to accrue to folks that have t-shaped[0] skill sets that allow them to be extremely productive in their area of specialization, and extremely effective at collaborating with other specialists across the organization.
You seem to be getting dismissed as a dilettante, though it is being couched in terms of your expertise in whatever the person you're talking to doesn't feel qualified to assess, or whatever they aren't looking for in the role they are seeking to fill.
There is, however, more than one way to specialize over the course of a career other than your role in an organization per-se. For example, you can develop domain expertise in an industry (finance, healthcare, legal, telecom, entertainment, retail, agriculture), market (eg. regional VARs, enterprise software, small businesses), delivery model (SaaS, information products, durable goods), or product/service category (content management systems, adtech, databases, business intelligence). Don't go crazy with combining these into something too hyper-specific, obviously.
Their development slows to a crawl, as they get stuck in one role. Yours, and others like you, just keep that intense growth happening.
It isn't necessarily their fault, either. Circumstances can keep someone slotted deep in a role, with no way to expand laterally.
So, they may literally think such breadth and depth of experience is just overstatement.
The first company I worked for let anyone grow into any role they proved they could do. If you solved the hard problems you were the senior developer, if you took the reigns you were quickly promoted to lead/manager. Seniority didn't count for anything and roles were very fluid.
That's an uncommon situation and what I've learned is it's hard to imagine if you've spent a career in more traditional organizations.
I recall a contract with a government department. Very much like this. And the very lengthy discussion about the simplest things.
Azure, Data Engineering, Data Science? Cause I'll hire you
Followed by a one liner summary
That being said, if you are doing all of these things, and not being fairly compensated for it, then that's definitely a problem. A $50k/year web dev position at some random agency, doesn't deserve this level of work from you, esp. if you could instead take all these responsibilities, and do them at a serious technology company or start-up, for 2x-5x the comp.
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.
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.
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.
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.
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.
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?
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.
Now I have my own company and I still do all those things, LOL. Big difference being I choose what I do, how I do and obviously the size so I can chew it on my own or with my few trusty subcontractors. It is basically development of new products from scratch either for clients or for my own company and once in a while some very short hit and run type jobs. I now also leave plenty of time for myself to enjoy whatever activities make me tick.
This is the kind of thing that any company doing this should be named, shamed and blocklisted.
There is no reason other than greed that a higher ranking employee shouldn't make at least as much as a lower ranking employee in total compensation. "Person was hired earlier and is okay with the lower wage" is, frankly, a reflection of a company hating their employees. It's a shame and an embarrassment.
To me the "rank" of senior engineer should indicate the engineer's experience, and maybe their "wisdom" and depth of knowledge, not their salary. A senior engineer may slack off a bit and be less productive than an eager junior, or want to take on less responsibility; it seems fine in that case that the junior is rewarded with higher pay.
Know your value to the company, and negotiate compensation to match it (or exceed it!). I'd also suggest companies not tie pay to title.
This can be a very subjective thing. How do you 'rank'? This is not something that is completely clearcut, cut and dry and you are 100% accurate without fail.
Example: I have a guy on my team that is 'more junior' than some others. He's killing it though. He's consistently behaving like he's got 10 more years of experience than he does and people that had 20 more years of experience than him couldn't do 10% of what he does without fail.
Of course you could say that the Senior developer should never have been hired if he was actually a Junior developer that's just been around for some time already but hiring practices aren't perfect, people get hired on one team and move to another and you're the first to actually do something about it etc.
Are you going to promote him? If so, why? Are you going to give him a meager raise? If so why? Are you going to give him a proper raise? ...
FWIW, the "Senior" is no longer in play. I do not tolerate such incompetence for long. And yes I am doing everything I can to get the 'junior' a proper raise and a large bonus.
Instead saying "X left, we need extra budget to replace it" will often work.
It's idiotic and expensive for the company but what can you do.
You can't prove that giving me an extra 5k made me stay long enough to pay it back at >= our revenue targets.
The semi-healthy version I see play out is when people who want to be better use the loss of a customer or a coworker as fodder for pushing their agenda. Essentially it's one class of teachable moment. People learn from pain when nothing else works, and you can amplify or dull that sense of pain.
[Insert frustrated comment here about how capable, sufficient and well-performing ICs are absolutely rewarded.....with more work and additional duties]
I left for other reasons as well, but it really shone a light on how management thought of ICs. Managers: proactively reward your ICs, don't wait until they're halfway out the door. I would honestly take a less aggressive adjustment in comp if it was done proactively, rather than waiting until I'm fed up and on my way out.