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.
