The coach/player metaphor is an extremely weak analogy for Software Engineering. Sports aren't changing nearly as rapidly as software engineering is. If you don't watch a soccer/basketball/football/baseball for 10 years and come back, it's basically the same game. The last 10 years of software engineering have changed so much with mobile, map-reduce, responsive design, P/B/S/I/A - aaS offerings, dev-ops tools, cloud computing systems, new languages, etc...
I remember a specific example of a manager I had (great Guy) who wanted to build a searchable database of public certificates. When he asked me about what we should build, I said -- Just make one search box (like Google) and allow them to type in whatever they want and we can do the parsing on the backend. He counters saying, well I think we should go with the 50+ input form (That's what he was used to building on all of his old projects). If it was now, I would definitely be more vocal about his software design decisions because he was just rusty and not in touch with the current state of design/dev. I actually got permission to build both interfaces, since it wasn't really much work to build the single search box, and 95% of the usage came though the single search box.
I don't think managers need to program, but they need to be doing the equivalent of watching tape, studying other teams, understanding new/changing game rules, learning tradeoffs of different equipment, and keeping up with their domain. All of my experiences with managers that are active in the development community have been amazing. Managers that weren't have always been terrible.
>The coach/player metaphor is an extremely weak analogy for Software Engineering. Sports aren't changing nearly as rapidly as software engineering is. If you don't watch a soccer/basketball/football/baseball for 10 years and come back, it's basically the same game. The last 10 years of software engineering have changed so much with mobile, map-reduce, responsive design, P/B/S/I/A - aaS offerings, dev-ops tools, cloud computing systems, new languages, etc...
Watching? perhaps. Coaching? No. And that is why I don't think the analogy is weak.
I'm very familiar with two sports, basketball and football. I'm intimately familiar with football. The subtle changes that most fans, particularly casual fans, don't see is what makes coaches who they are and what makes great coaches worth their weight in gold. Not to mention coaches that can get the most out of specific skillsets of players[1].
As just one example. The pistol became all the rage last year with several running QBs running it for their teams. The good teams could, for the most part, coach their players on this style of offense and how to counter it. It was a different style of offense that wasn't used in the NFL and the teams and players had to react...the coaches had to to actually coach them on how to play the zone reads etc etc.
Even further, a coach has to be ready to adapt mid-game, mid-drive and in situations. Game conditions dictate them be ready for quite a bit and ready to coach up their players at an instant...or better still...have previously coached them on such a situation. The game, to the fan, might look the same, but not to the coaches.
This is why for people who are familiar with coaching and managing software, they do hold up. Both are at their core about leading a group of people to a common goal, articulating the goal, the way and (sometimes) the how.
So, in summation, you still don't want your coach running routes. You want your coach getting ready for the game and coaching everyone in that manner.
[1] - I mentioned specific skillsets of players. The pistol was an example of this. You have young, inexperienced mobile QBs who can do a few things well. You adapt to their skills b/c you know, while they have potential, they don't have Peyton Manning's situational football IQ yet (if ever) and ability to read defenses. So you simplify, mold the system around their skills. Good managers do this with developers as well. A manager is not going to just "off you go" to a developer. They need to know strengths and weaknesses. Even with my experienced managers, directors and such, I have a firm grasp on personalities, trigger points, strengths and weaknesses.
I remember a specific example of a manager I had (great Guy) who wanted to build a searchable database of public certificates. When he asked me about what we should build, I said -- Just make one search box (like Google) and allow them to type in whatever they want and we can do the parsing on the backend. He counters saying, well I think we should go with the 50+ input form (That's what he was used to building on all of his old projects). If it was now, I would definitely be more vocal about his software design decisions because he was just rusty and not in touch with the current state of design/dev. I actually got permission to build both interfaces, since it wasn't really much work to build the single search box, and 95% of the usage came though the single search box.
I don't think managers need to program, but they need to be doing the equivalent of watching tape, studying other teams, understanding new/changing game rules, learning tradeoffs of different equipment, and keeping up with their domain. All of my experiences with managers that are active in the development community have been amazing. Managers that weren't have always been terrible.