[Bahamut]

There are different ways of making teams more productive than doing just technical work.

For my own anecdote, I often can fix a lot of bugs/feature requests that come by in < 10 minutes, and often will. As soon as it is revealed that another dev will start contributing who has no prior experience, I stop most of that work and let that person take on some of those tasks & do the leftover ones. Mentorship/growing developer capabilities expands capabilities long term, even if the dev ends up moving to another project.

I also spend the most time in meetings of any IC on my team - reducing how many ICs are in meetings frees up their time to learn and grow.

I often float ideas to people for approaches to problems and designing apps/systems/features - I’ll also let others do the same. However, I also often take a light touch and leave ultimate decision making to others so they can gain that experience even if I disagree. Letting others take ownership improves the team’s capabilities.

There are many ways to expand productivity of those around you that even those who aren’t as technically gifted can do. Leadership is a very underrated part of being an engineer IMO. I do all these things as a mid-level engineer in title, but gained massive respect from management & senior ICs where they come to me for advice/ideas. I don’t fall into the trap of jealousy that others are getting credit/hampering my ability to get promoted because my work speaks for itself & I celebrate when others do well - I have no reason to feel insecure, and so help unlock my team’s productivity by removing that ego in my actions.

[JohnBooty]

I'm a believer in everything you just said!

It takes a very healthy work environment (and attentive management) for this kind of work to be noticed and rewarded. Unfortunately it's not often the case.

I have tried to take this approach many times and a lot of companies/managers absolutely do not value it.

Broadly speaking, it only works if management is really involved in the day-to-day (more like hour to hour, really) process of what you're doing. Then it is easy for them to see that you are lifting up those around you and elevating the team as a whole. Without this involvement, a "mentor" and "leader" winds up looking simply like "a guy who doesn't ship enough" to management.

At my last job, management was very... absentee. There was a shortage of management and this was a bottleneck. They relied on metrics too heavily (stories shipped, etc) and didn't understand the actual processes... who was mentoring and elevating others, and who was "highly productive" but was also leaving an absolute trail of technical debt in their wake.

[Bahamut]

I feel your pain there, definitely experienced it at most prior companies. Unfortunately good engineering management is uncommon in our industry :( .

[JohnBooty]

It's a shame when management fails at understanding this aspect of the game because I feel like it's one of the simplest ones to understand.

Appeasing clients? Balancing profit/loss? Juggling fire-fighting and feature-shipping? Recruiting? Hiring?

Hard, hard, hard, hard, hard.

Listening to your developers, who generally just want to be productive and generally know more than anybody else about how they can be productive? (If not, why did you hire them, if they don't know how best to do their jobs?) Understanding that technical debt exists and exerts a massive drain on future productivity?

I feel like those are the easy parts of the job.

Of course, the onus is on developers to communicate these things well. Otherwise we can't blame management for not understanding them. But I have never seen process break down because developers weren't talking. It always seems to fail because management isn't listening.