Sure. I don't disagree about not writing tests at times, etc. That's different than the point I'm trying to make. Leaders aren't necessarily tasked with doing any job a developer thinks is shit. The leaders job is to help the developer understand the why behind doing it.
Also, do you have anything quantitative to back your statement about being out of touch? That hasn't been my experience generally and I work quite hard to ensure I don't lose touch. That's obviously only data on my experiences - but I didn't make the assertion (I genuinely interested though).
Another recent engineer turned manager here. I can attest to losing touch, as I've had to work extra hard to see where things are trending in my spare time. If development wasn't also a personal hobby, this would be exceedingly difficult.
Fundamental shifts occur in development all the time, and if you're not actively coding while these are going on, you can definitely get left behind and be out of your element when it comes to decision making.
I have peers that cut their teeth on Enterprise Java and Oracle and now they are managing engineers doing Native Mobile, JavaScript Apps, Ruby on Rails, DevOps, Distributed Databases, and deploying on public clouds like AWS.
It's very easy for them to get lost in the jargon and they end up leaning on and trusting senior engineers to guide them a lot.
While this can be a good thing, it's very easy for the wrong senior engineer to lead them astray and start pushing their own agenda (rewrite all the things, resume driven development, etc).
> While this can be a good thing, it's very easy for the wrong senior engineer to lead them astray and start pushing their own agenda (rewrite all the things, resume driven development, etc).
This is a very good point, but how does an organization do this? Who can be at a management level for the majority of their time, yet still remain technically sharp enough in multiple technologies over time, to know when someone is outright lying to them? And it's not like you can just ask them to walk you through it - even ignoring the significant minority of egomaniac technical people who will more or less outright refuse such a request, in many cases even if they are relatively cooperative, often the subject matter is simply too low level or complex to be explained (or is deliberately explained in this manner), and sometimes the disagreement is not even a matter of fact, but rather a matter of opinion (everything XML, language choice, 100% test coverage, etc). It's a tough problem.
It's a good question, and a difficult one for me to answer as I'm still trying to figure it out.
One possible defense against this is to regularly refresh talent, and encourage high performing individuals to swap between contributor and manager roles without any career penalties in between stints.
Even if it doesn't work out for a contributor to manage people or a manager to write code, the cross pollination of talent could strengthen the technical capabilities across the organization. Contributors and managers would build trust with each other, and ultimately empathize enough with each other to act as trusted partners.
I've seen this play out in the startup ecosystem as you see VPEs leave to become early stage startup CTOs, get their hands dirty to launch ideas, and then ultimately bring in trusted contributors once the products have found product-market fit.
"Also, do you have anything quantitative to back your statement about being out of touch? That hasn't been my experience generally and I work quite hard to ensure I don't lose touch. That's obviously only data on my experiences - but I didn't make the assertion (I genuinely interested though)."
How do you know you haven't already lost touch? :p I joke, but the first time I switched into full time "architect" mode I did lose touch without even realising it.
I guess the key measure would be: could you jump into a senior developer role on your current project and be as productive as the other senior devs on the team? In my experience most team leads can, but very few managers can.
I doubt there is much in the way of hard data either way. I've personally met less than a handful of architects/managers that were clued in over my 15+ year career.
It's like looking at code written by a python developer who, a couple of years ago, used to be a c developer. The developer still understands memory management, but it's no longer forced to the front of their minds. And it shows in the code they write. Likewise because as a a manager you aren't forced to deal with the code your brain quickly abstracts it away. Your "atomic operations" when you think about a problem become a lot larger.
Also, do you have anything quantitative to back your statement about being out of touch? That hasn't been my experience generally and I work quite hard to ensure I don't lose touch. That's obviously only data on my experiences - but I didn't make the assertion (I genuinely interested though).