Comment by ath3nd

> Once I was full-time managing, I had no shiny distractions and was able to spend my showers focusing on how to be a better manager. And once I was 50%+ focused, well, I haven’t become a “superstar 10x manager” yet, but I quickly stopped being 0.1x.

Counterpoint: a manager who is not spending at least some time on programming or in the codebase/PRs is not able to evaluate fully their teams' strengths and weaknesses and collaboration and is less of a 1x manager than a manager who does code/spend time in the codebase(s).

Let me elaborate further.

# Engineering Excellence

It's a part of our job to foster and encourage engineering excellence. A hands-off "I only manage" type of engineering manager can get the following signals for a team member in terms of excellence:

- from other team members (great)

- from Jira/PRs merged output (good-ish)

But is this merged PR the best work that can be done? Is it maybe not shoddily but quickly done, and LGTM-ed by others? Do you get good feedback about that person from other team members because they are great at being friends, or because they are excellent engineers? Is the codebase slowly becoming unmaintainable from the whole team vibe coding? You can't know for sure, cause you didn't check, and if you are "I only manage" type of engineering manager, after some time you wouldn't be able to tell the difference even if you checked either.

Conclusion: an engineering manager who doesn't frequently check the codebase and or/code themselves can rely on fewer signals to gauge technical ability in their team and is less informed and capable to steer engineering excellence than a hands-on engineering manager.

# Promotion and recognition

It's a part of our job to recognize talent for the work they do and reward them for that. An "I only manage" engineering manager can rely only on two things to find things to reward in a software engineer:

- Other teammates' feedback (okay-ish)

- If that software engineer themselves brought up a significantly difficult achievement and self-advocated for their work (bad, selects for chest thumpers)

An "I only manage" engineering manager not looking at code is blind to the achievements of more shy engineers that don't loudly advertise their work, and can be also blind to a dynamic where teammates don't know what others are doing. On the other hand, a hands-on manager might find achievements that teammates don't, and build a culture of celebrating each others' achievements + actually knowing what the hell others are doing.

Conclusion: "I only manage" engineering manager can be blind to some dysfunction and reward disproportionately people good at selling themselves. A hands-on engineering manager has a better and ampifly teams' recognition of one another and create a culture of shared celebration of achievements.

# Know what people are talking about

If you don't code/solve technical problems and you "only manage", what makes you qualified to hold a discussion, and even worse, judge merit of your team members? Why are we shoving a dynamic where the least qualified judges others and "solves" their problems. Sure, many problems are people problems, like salary, conflict, etc, but these problems are very often related to actual job performance. How can you judge thoroughly if someone is actually doing a good job ("I only manage" uses 80% vibes and 20% second-hand stories) and deserves that salary increase if you haven't seen their code or how they communicate with others in PRs?

I want to stress out that I don't advocate for managers that are the best devs in their team, nor managers who don't care for their teams' wellbeing. I am simply saying that to actually manage well, you gotta be "in the things", know well what your team is doing AND HOW WELL. To judge software engineering capabilities, you yourself need to have sharp software engineering capabilities and getting a taste of the daily work makes you a far better engineering manager than the "I only manage" type of manager.