I found the part about coding interesting.. "My coding activities were always productive. They either launched a new project or a major change in direction of

I found the part about coding interesting.. "My coding activities were always productive. They either launched a new project or a major change in direction of a project. They also enabled me to have discussions with my team members at a completely different level of detail (to everyone’s enjoyment)." This can be great. It sounds like it went well. However, I have personally seen a downside, some potential risks, when the boss "keeps coding". Here's why - if the boss is coding but staying off the critical path, this means that the often detailed, difficult implementation work will be delegated to developers who report to the boss. The old adage that genius is 1% inspiration, 99% perspiration? Well, the critical path is the perspiration part. Deadlines, estimates, glaring errors that shouldn't have happened and need to be fixed late at night or over the weekend… these are all part of the critical path. While coding can keep a boss closer to a technical team, it can also create a dangerous illusion, that the boss is still "technical" but insulated from the truly difficult aspects of a technical role. There is a big, big difference between coding on your own research project and coding under deadline pressure for a system that needs to work. This is only a risk, not a certainty, as a good manager will recognize this. Perhaps a greater risk, though, is that if the boss gets to play around with new technology and launch projects for the rest of the team to finish off, there's a risk that the boss is pretty much eating the frosting of the team's dessert but making everyone else eat their vegetables, so to speak. If you're a manager who codes, keep in mind that autonomy and innovation may be key to the motivation and job satisfaction of the people working for you. This can lead to a very damaging management anti-pattern, where a manager who "keeps coding" essentially uses managerial authority to intercept and filter projects, make the key technical decisions, do the interesting bits that would lead to interesting conference talks, and then delegate the work of actually finishing the product to the team. This may deprive senior level developers the autonomy that they really were supposed to have on projects. Once again, I want to emphasize that this isn't necessarily what happened here, in fact, it sounds like it wasn't. But the passage made me a bit nervous, since I consider this to be something of a management anti-pattern.