I don't see where I made the connection between practicing the craft and hacking together solutions.
If an engineering manager (presumably one who attained this position because they were or are a good engineer) is going to fix something, they're going to apply best practices because they know what they're doing.
If an engineering manager was hired just because they know how to manage, well then they aren't really an engineering manager, are they? They're just a straight people manager and in my opinion, shouldn't be managing an engineering team. They should be a project manager.
Engineering skills decay with time and even the most technical manager will be out of touch compared to someone who spend 100% of their time on code. They also have the pressure of the buck stopping with them and not having to deal with the tech debt fallout which creates an incentive to just hack things. Some will avoid this but most won't.
>presumably one who attained this position because they were or are a good engineer
Why do you presume this? Management is a very different skill set than engineering. The best engineers having to become managers to advance their careers is an anti-pattern which most modern tech companies avoid. Managers thus tend to be average engineers who are good at people and process.
They don't have to spend 100% of their time coding. Why not 50%? If you spend half your 40 hours a week coding, after presumably having had a career in engineering as a developer in the past, coding half the time will continue to support your technical knowledge well into the future.
I refuse to believe that managers shouldn't code. Actual managerial tasks do not take up that much time. Like I said in a previous comment, in my experience (as a manager), managerial tasks take up maybe 20% of my time per week. What's going on with the other 80%? I'd be bored out of my mind if I wasn't coding as much as I currently am.
I've written in another post where I spend 80% of my management time. I could cut it down to 20% but then I'd be building up the management version of technical debt. As I see it, there's a lot of things you don't have to do but doing them makes your team function better in the medium and long term.
Read this, and it gave me a lot of clarify and appreciation for my own manager. Thank you for adding this. You sound like you've got a balanced perspective on the engineering manager experience.
I was hired into a new leadership role recently. I had previously worked my up at a few places and go to the point where I was coding maybe 5-10% of the time at most. The new role hired me for my management and strategic experience since I actually have almost no experience with their tech stack. Coding is coding, but I'm slightly useless to them as a dev for now and I haven't committed a single line so far.
I think the response to your original comment was more that having the "Ugh, forget it I'll just fix it myself" last resort option could be a crutch for a manager
If an engineering manager (presumably one who attained this position because they were or are a good engineer) is going to fix something, they're going to apply best practices because they know what they're doing.
If an engineering manager was hired just because they know how to manage, well then they aren't really an engineering manager, are they? They're just a straight people manager and in my opinion, shouldn't be managing an engineering team. They should be a project manager.