I've strongly disliked every team where this was the case. The people in those positions ended up being neither good managers nor good engineers.

YMMV, I suppose, but this combined with the AI nonsense just makes the dislike even harder.

▲

claytonjy 5 hours ago | parent | next [-]

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.

I 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.

▲

colechristensen 4 hours ago | parent [-]

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.

▲

claytonjy 4 hours ago | parent [-]

I 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.

Went on for about a year, worse each week, before i left.

	▲	duzer65657 4 hours ago \| parent [-]
		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.

▲

Aeolun 5 hours ago | parent | prev | next [-]

I haven’t had it turn out well with pure managers either, so I’m not sure how much the distinction helps.

	▲	jamesfinlayson 3 hours ago \| parent \| next [-]
		Yeah 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.
	▲	lokar 4 hours ago \| parent \| prev [-]
		Do you mean not an engineer at the same time as a manager, or never an engineer?

▲

ern 4 hours ago | parent | prev | next [-]

In 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.

	▲	zdragnar an hour ago \| parent [-]
		Everything 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. Knowing 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.

▲

lokar 4 hours ago | parent | prev | next [-]

Being a great manager requires being good at a whole set of specific skills, and that takes effort and some natural talent.

It can certainly overlap with what makes a great engineer, but not most of the time.

	▲	duzer65657 4 hours ago \| parent [-]
		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.

▲

duzer65657 4 hours ago | parent | prev | next [-]

They'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.

▲

rowanG077 4 hours ago | parent | prev | next [-]

For 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.

	▲	duzer65657 4 hours ago \| parent [-]
		You 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.

▲

operatingthetan 5 hours ago | parent | prev [-]

[dead]