My experience as well. It sounds nice at first, but since it’s tied to org flattening these “player-coaches” end up with 15-20 reports, which is way too many for even a pure manager.
replyI noticed it was especially bad for on-call and incident response; these managers get pulled in to all the incidents because of their status and supposed involvement, but are not particularly useful in those rooms, adding even more cooks to the already crowded kitchen.
I worked somewhere once where every once in a while we'd have to create a new deploy meeting because 1) our code was deployed manually over the course of hours and 2) every manager imaginable wanted to be in the meeting asking questions and directing people... you couldn't actually speak to anyone you had to talk through their manager.
replyI experienced a flavor of this, too. We had some outages, management said no more daytime deploys, so we had after-hours “deploy parties” whose scope and participant count increased weekly. The smarter managers said it was temporary, but couldn’t say how we’d move back towards continuous deployment. If anything went wrong in any service, you’d end up with a dozen or so folks on a zoom call for 3 hours. We did this once or twice a week.
replyWent on for about a year, worse each week, before i left.
I've experienced this as well. I call it the "better safe than sorry" strategy, and the issue is it ignores the very real cost of all the extra effort and work, from the literal costs to the slow releases to the loss of people who just can't take it anymore.
replyI haven’t had it turn out well with pure managers either, so I’m not sure how much the distinction helps.
replyYeah I don't know - my experience is that a manager's competence is essentially the toss of a coin. The only non-technical manager I've had was great and the only hands-on player-coach manager I've had was terrible so not enough of a sample size to drill down.
replyDo you mean not an engineer at the same time as a manager, or never an engineer?
replyIn my experience, managers don't have to be hands-on, but they need to be able to recognize people with talent and unblock them do their jobs, to be able to spot process improvements, including channelling the AI hype to productive outcomes, and to be a steadying influence in a crisis (without adding noise). If a manager doesn't have technical ability, its impossible for them to do those things.
replyEverything but the AI bit are on my list of manager qualities too, but the best managers I've had weren't active programmers, and one had zero coding background.
replyKnowing what you don't know and knowing how to get qualified information from people around you makes up for a lot of not having a programming background.
If anything, the managers with technical backgrounds who weren't active programmers tended to significantly underestimate the difficulty of doing something because back in their day, things were different or some such nonsense.
Being a great manager requires being good at a whole set of specific skills, and that takes effort and some natural talent.
replyIt can certainly overlap with what makes a great engineer, but not most of the time.
I think I am a better manager than engineer, not because I'm a shitty engineer but because I recognize the superior strength in my team and do waht I can to leverage the basic principle that if someone is better than you in many things, they should still specialize in the thing they are best at.
replyThey're still going to have upwards of 5 levels in their hierarchy, so this is obviously for the plebs who are front-line managers, not the several layers above them, as (for example) I'm not sure what a strong player-coach VP of Engineering would exactly look like. I got to Director and quit because it was impossible to be a true contributor at that level or higher. You can see this when you're in critical mode like downtime or a breach; senior management is useless.
replyFor me this is all about team size. It works if you have small teams, maybe max 6 people. But anything above 8-10 this is a total no go. Because management tasks just are not able to be done well at that point.
replyYou right, but there is a very real coordination problem above the team when you're doing bigger things. I've recently experienced an organization with approx. 25 teams of 5-8, and because of their organization they had way too many concurrent initiatives. It was very hard to effectively swarm multiple teams on fewer (bigger) projects.
reply[dead]
reply