Hacker News Reader

Comment by siggen | Hacker News Reader

I feel managers, directors, etc. who cannot code should not be managing, either.

You have two classes: management and individual contributors, when there shouldn’t be. Management ought to be able to solve any problem people they serve (i.e., their underlings) are facing, given certain amount of time to familiarize.

View on HN

This depends on the size and context of the organization. I'd argue that front-line managers should handle trivial, low-priority, low-glamour development, but not more than a small fraction of their time (say between 10% - 30%). If they're doing development work that is more sophisticated or requires more of their time, they aren't going to be able to do their more important job: managing. Managing, by the way, is more than just having 1:1s every week and filling in the budget spreadsheets--it's negotiating for priority, fighting for direct reports' career needs (e.g. fighting to get the team assigned the projects that ICs will be able to use in their performance reviews) and balancing that against the needs of the business, etc.

Mmm, what I was arguing for is that a manager ought to have sufficient experience that they can substitute for and work as any individual under them.

I understand that many large institutions are constructed in a mechanism you describe. In many cases, these managers are technical enough that they can substitute any individual working under them. There are also many cases where they are not sufficiently technical.

Nonetheless, if a manager’s purpose tailored towards prioritizing, fighting for projects, and assisting ICs career growth, I am not convinced that that manager is necessary as I am not seeing his value. Prioritization ought to be intrinsic for everyone and is more a collaborative choice, no? Why does a single individual (manager) decide priority?

Because direct collaboration scales as O(N^2) in terms of person-to-person interactions which becomes rather big as N grows. Having everyone spend 80 hours a week in meetings and still only understanding 1% of the business seems a silly use of time and rather inefficient in actually getting things done. Thus you get managers who are the ones in meeting with other managers which leads to a smaller N.

Understood. Apologies, I didn’t understand what was being prioritized previously. Previous replier clarified. Agree that otherwise this reduces to a handshake problem.

Prioritization is a collaboration in many parts: between members of a team including the manager, and between managers, their managers, etc.

Often ICs don't have the context necessary to contribute much to the conversation once it leaves the sphere of influence of the team they're on--and more importantly most of them don't want to acquire that context, often because they view it as inferior work that is beneath them. They don't see value in management because they can't see past their own egos and myopia.

Got it— prioritization of say features vs prioritization of tasks in the backlog, as an example. Management is necessary— I don’t think management’s function to a company can be discounted. I am advocating for certain traits I think a manager ought to possess, one of which being they have full ownership of everything happening under their umbrella. :-) Not saying they have to code, but saying if necessary they can be a substitute for anyone under them (given some minor startup cost).

The problem is that the world is not filled with superman. People who can code, lead, manage down, manage up, do product and so on are very rare. Ones who can do all those well are even rarer. By focusing on coding you get people, who to be blunt, can't manage or lead well. Which leads to more conflicts and issues than it fixes in my experience. Even if you find such people you get into the problem of them stepping on toes because they or others don't realize which hat they're wearing at a moment (ie: are they talking as an IC or as a manager).

Plus, at the end of the data, a good manager should aim to hire people smarter and better than them. If they can step in for those people quickly then they're not hiring better or smarter people which is a problem. A first line manager should understand what people do but that is different from being able to do their job to the same level.

"I feel managers, directors, etc. who cannot code should not be managing, either."

It works if they know they are out of touch and trust their people. On the other hand if they try to give input but haven't coded in 10 years it's bad,. Last year I had a fight with a manager who insisted that we use JSON for everything. I pointed out that this is a minor decision and really not very relevant. Another guy agreed and was almost kicked out of the project.

I'm in this situation now and it's not bad. It's really important for everyone to have a nothing-personal policy about being like "Hey, this is my area and not yours, let me take over." (And it goes both ways).

It does lead to a lot of "Black Triangle" [0] situations though. Where you spend a long time with no "real" actionable results to show management, and then after an annoyingly long amount of time present what looks like an insignificant joke to a non-programmer.

[0] https://rampantgames.com/blog/?p=7745

> I feel managers, directors, etc. who cannot code should not be managing, either.

Somewhere, in a different forum there is a bunch of managers discussing an article where a project has completely failed because some completely naive engineers made a bunch of rookie management mistakes, pissed off half their employees and crashed the whole project.

And they are busy saying "Engineers who don't know anything about management shouldn't be managing stuff..."

:-) I am not convinced engineers cannot be trained to also be great managers. A lot of managers were devs in the past choosing to take management roles to increase salary and forsake programming to satisfy rules implemented in their environment. Forsaking dev work is a mistake.

Management is not something complex. Almost all of management is expectations management.

Some directors may have dozens, if not hundreds or even thousands, of people under them directly or indirectly. This rapidly grows beyond the scale where the director can jump in for anyone in the tree beneath them.

Your comment probably applies for a team lead with a half dozen IC reports. Add in one other layer (i.e., a half dozen team lead reports) and it might still apply in some cases. But double that number or add in another layer and things are probably far beyond the scale you were imagining. The manager’s job now requires a vastly different toolset that most developers know nothing about, have no experience with, and generally wouldn’t even know how to think about.

You don't have to do it recursively, a director should be able to substitute his reports but not necessarily their reports.

Right. I wasn’t clear above. I do not mean recursive. For example, I don’t expect a CEO to do dev work: different skillset.

> Management ought to be able to solve any problem people they serve (i.e., their underlings) are facing, given certain amount of time to familiarize.

I disagree with that.

If your manager has the best technical skills of anyone on the team, then they are probably a poor manager who can't hire/retain good technical people (by far the most important job of a manager).

this is how it works in finance - but doesn't carry over into tech for some reason

What is the reason though? Was there some survey done that analyzes why this strategy is used (in large tech firms)? I am going to start looking into past research to see if any have delved into this question.

i think its because tech is seen as a trade (like plumbing) and not a profession (like finance).

Reply on news.ycombinator.com