A hobby project to keep current isn’t a bad idea, though.
That's a very good indicator of a bloated institution. People have to compete for work instead of pushing it away or avoiding it because they already have their hands full.
But I don't believe there is a general rule that applies here.
Most great managers I had were deeply technical and involved in the nitty gritty of the projects, including coding the very spiky aspects of a project.
Most mediocre managers I had were very focused on relationship building. The kind of manager that would need a hobby project to keep current, instead of being the most knowledgeable person in the room.
> I think that there is a big difference between being in the code and writing code. All managers should be in the code, but not all managers should be writing code.
I think it's not possible to be in the code without writing code. People can pay lip service to being in the code as the author indicates, but as we all know there is no substitute for actually sitting down and writing the code yourself in terms of understanding the actual pains and struggles.
And my anecdotal experience says that if you aren't writing at least some of the code, more often than not the disconnect between the manager and what the team is doing grows and grows.
If I were an IC and my boss was picking the sexy work I would leave. If I was a director and one of my EMs was picking the sexy work I would fire them.
I’ve also done POCs of work that has been met with resistance that I didn’t feel was justified in order to actually give it a fair shake. That is my coding fun.
I've had managers do this to me. What an awful experience. Because they're the manager you can't push back against the awful design decisions they made. They feel it's almost done so don't understand that it takes a lot of time to deal with all the side effects they didn't consider.
This helped me out by leaps and bounds. I was usually swamped with other research. I would then make it ready for production or lead the team to and take care of the edge cases, integration with our config system, logging and alerting, etc.
There is a huge difference between a POC and an MVP. An MVP should be properly designed and scaffolding that you can build on, a POC doesn’t take those things into account.
I hope I don’t come across that was and do have some evidence (not to be laid out here) supporting that I don’t.
I think I’ve created a team and structure where the developers I manage are comfortable telling me I’m wrong or what I didn’t consider. It happens weekly. We value honest feedback highly. We do it with respect, but we do it.
We just have some developers on the team that are resistant to ideas that don’t follow a pattern until they see it. And sometimes my communication around the initial idea is poor and the best way I can communicate is an implementation.
I’ll add one other great edge in building a quick POC yourself. Sometimes your idea actually _is_ bad, and trying to articulate it in code helps you see it.
Then again, I've been called a bad manager on Hacker News so...
Obviously being a good manager is first and foremost, but I’ve always had more respect for managers that I know can (even if they never do) do my job as well as bring a manager. Early in my career at a startup I had a manager that was both and excellent manager and right there in the trenches with you when issues arose or business deadlines were approaching. The amount of respect I still have for that individual is immeasurable and I’d go work for them again in a heartbeat if they asked.