I tend to encounter the latter in smaller companies that have revenue pipelines outside of tech and aren't entirely tech-oriented.
My current manager has a technical background. I now spend the vast majority of my work week in meetings. Not because my job has changed, but because they have so many meetings that we never had under my previous manager. Scrum, backlog, retrospective, one on ones, touch bases, etc. I seriously maybe have 5 hours a week to actually program these days. If we want anything, he is likely to say no and that we can get along with what we already have. He often has opinions on how we should do things based on how he did things years ago instead of modern best practices. Give me a non-technical manager any day.
But also on the expectations being transported down from above.
The problem is, imagine a company with your second managers mindset and his/her boss takes a look into the calendar, sees there are no management meeting tasks (Jour Fix, standup, and so on) in there. His/her boss would think he/she is not doing anything, because the signifiers that declare a manager actually managing are missing.
I don't see these signifiers as actually managing - I see them as creating disturbance - but modern management culture seems to be seeing these signifiers as sign of real managerial work.
I also find a lot of managers need to please their own ego by feeling they do something. They often need to feel important - hence too many meetings as signs of them having control.
They seem a lot like the project manager to me. :-P
But talking about how the team builds systems, who’s doing the building, and things like that should never be within the domain of a PM.
I’ve had a few managers that did that, one of whom was very close to the absolutely worst manager I’ve had in any job.
Understanding the work is a useful thing for a manager, and having done it is one way to get there. Understanding people is more important, and working as a developer is not much of a way to get there.
In some management roles I've had too many reports or too many reports who expected hands-on management and yeah, it becomes a full-time, full-time thing. In others--and, to no surprise, my preferred situation--it's much more of a "first among equals" situation where, yeah, a good chunk of my time is spent in meetings (clustered early in the week when I could) to firewall off my team, but it'd be rare to not be able to carve off a full day or two afternoons for deeper work, whether it's code or architecture or analysis. And in those roles it was usually necessary to write a good bit of code, because I'd been an IC before a manager and had done most of the work--and one of the artifacts of doing more work on it, then, was documentation and making it accessible for the next person.
Honestly, in most intellectual work, the first-level manager having an intermittent toe in the water of the actual work (not focussing there, of course!) I find to be a pretty good sign—if they don’t, my experience is that they either don’t understand it or are overcommitted (usually, too broad a span of control, but sometimes too much pushed down to the first level of management that should be at higher levels), or are inventing no-value work for staff in their slack.
The biggest problem I have is that, while both managers are OK software devs (but not great), anything I advocate for that is above their skill level is perceived to be “too complicated”, or “takes too long to do, let’s just get it done quickly for now”.
So, instead of proper config files or method dispatching for client-specific behavior, we end up with if/else and switch statements with hard coded client primary keys.
Then, when a huge bug comes along on a Friday at 5pm as a result of how we built the thing, I get to be the one to dig us out of the hole while my managers are busy “working on the next big feature” which will almost certainly be done just as poorly.
So, conveniently, only myself and our customers ever get to experience the consequences of their decisions.
And what can I do? I can fight to get my way, sometimes, on new features, but when “their way” becomes a problem, I can’t use it as an example to support my ideas or say “I told you so” without hurting feelings or going against the people signing my paycheck.
Our former VP was a securities trader turned IT manager, who knows how he probably knew people, and was terrible.
These orgs also tend to treat all tech as cost centers (perhaps, correctly in their context of business). The more non-technical the manager, the more likely tech is a cost center and necessary evil, usually resulting in toxic development cultures.
I mean not to generalize, but a lot of developers are neurodiverse introverts, the flavor that doesn't go well with typical management skills.
I mean managers and sales and the like also have their own flavors of neurodiversity - to generalize, it's things like psychopathy (or the ability to suspend their own moral compass) and high extroversion.
That is not my observation.
Having some ability to program can definitely be a plus, but it is also frequently a hindrance, if the manager is not aware of the dangers.
Best managers I had were just good at managing. They did not try to make technical decisions but instead tried to figure out a process to work with a collection of various experts that would let these experts to make best use of their expertise in context of the project.
In other words, they were focused on making right conditions for people, team, project to succeed rather than focusing on making technical decisions.
They tried to complement the team with their management expertise rather than trying to be lead developer.
Ability to program (as in developer who has just been promoted to management role) is frequently a hindrance. It is a crutch that the new manager uses which prevents him from learning his new trade well.
It lets him understand stuff without needing to communicate with the team, it lets him see through bullshit without having to build rapport and honest relationship and it lets him make passable decisions without consent from the rest of the team.
Which works fine for a while but in the end tends to result in mediocre manager and team.
Also a programmer manager frequently only ever learns to work with other programmers. This might be fine for strictly development team but leaves the manager out of the water when interacting with non-development teams, clients, etc.
My previous manager never even coded, while the manager before that was also still actively developing, and both had a much more personable yet effective style. Everybody has their pros and cons, but I just wanted to agree that being a programmer manager isn't necessarily good or bad.
This means you are in a fundamentally different team.
I have seen it is hard for developers to shed their development skin and become real managers. They might feel they need to prove their ability by being able to make all these decisions or even code themselves. There is probably couple of other things happening.
But that also means the team has less development responsibilities because manager will make all most important development decisions. And people who do not have important responsibilities tend to devolve.
Now, the world "tend" is everywhere here and it just represents the fact that every manager is different. I just mean this as a general observation from 20 years of working in development in companies like Canal+, HP, Intel, Samsung, Credit Agricole, Credit Suisse, Citi and others. There were better and worse managers and there were definitely some good managers who were developers before.
The way I define them is team lead is the or among the most senior and experienced team members. They still do some hands on work, the high value stuff, and they support, coach train the team on technical stuff, do high level design and ensure it all adds up to coherent working quality something.
Manager understands people, client, goals, process, company - how to support their team, how to protect the team, and how to get shit done - and crucially, how to get the right shit done based on company's and user's priorities.
I find its crucial to distinguish the roles and expectations. One of the best managers I ever had I did not respect at the time - I judged them as a team lead and their tech knowledge was limited...but when they left - team fell apart, and shit I didn't know existed started hitting us and we got torn seven different ways.
These are often the best companies to work for though, because the tech teams are outside of the normal management structures and can do whatever.
And he was really good at prioritising stuff.