[zzalpha]

It means you give that top developer the protection and time she needs to get her shit done.

But not to the exclusion of all else.

Again: a team is a team. I, as a manager, need the team to functional optimally. If one developer is a 10x hotshot, but she makes the lives of everyone else substantially worse, I don't give a crap how much code she can write, she can find another team.

The top developer doesn't get to be a silo, a dictator, or a troublemaker. As a high-skilled individual, they are expected to produce code, collaborate with team members effectively, provide mentoring and training, and generally lead by example.

Again, if they can't handle that, they can find a company where their style is a better fit.

[noobiemcfoob]

> But not to the exclusion of all else.

No, that's where you're wrong. If that developer is really your top producer, the bottleneck of production, you isolate and protect her exactly to the exclusion of all else. She becomes the worker that cannot, will not, be bothered. It seems counter-intuitive, but read on industrial engineering practices around optimizing an assembly line and you'll see it shown all around.

To get your team to function optimally, you must protect the core assets. And given that those assets are people, they have to feel protected. In the end, the rest of your team exists to support whatever it is that actually creates value. If that happens to be one developer who has their hands in 50% of the code (that others couldn't support if they wanted), then the rest of your team exists to support that one developer.

Ideally, though, no team is so one sided. There are no true 10x developers. And those that exist utterly fail at the rest of team management. At the end of the day, give your workers work they can actually do.

[zzalpha]

It seems counter-intuitive, but read on industrial engineering practices around optimizing an assembly line and you'll see it shown all around.

Development isn't an assembly line, and the fact you'd use that analogy says a lot...

If that happens to be one developer who has their hands in 50% of the code (that others couldn't support if they wanted), then the rest of your team exists to support that one developer.

Oh heck no.

If one person or only a few people are creating most of the value on the team, the team is dysfunctional and you've exposed yourself to enormous risk. If those people leave, fall ill, get injured, or go on vacation, you and the team are screwed. If you, as a manager, have put yourself in that situation, you have failed.

[noobiemcfoob]

All work is an assembly line. It's not a value statement, and it doesn't take the art away from the work. Work is work is work. Developers just have their head shoved too fair to get away from feeling like special snowflakes.

You're talking about risk management, not individual worker ability. Yes, it is a poor idea to have any one portion of a system maintained by only one person. So don't. It is a poor idea to have only one person who understands the system architecture. So don't. It's a poor idea to not recognize the different strengths and weaknesses of all your workers regardless of context. So don't.

[itscrunchtime]

I wouldn't want to work for you.

[noobiemcfoob]

Good to know.

[metaphorm]

this is the kind of batshit insane "logic" that produces cultures like the one at Uber.

[noobiemcfoob]

The idea of protecting your most productive asset so that it can continue to be your most productive asset instead of burning out solving problems its poorly suited for is "batshit insane logic" that prevails Uber? No, no its not.

Just because I label development an assembly line doesn't mean treat your developers like machines. They are machines, human machines. Meaning they have feelings and a whole host of things that must be managed in addition to keeping them well oiled.

[fao_]

"Just because I label development an assembly line doesn't mean treat your developers like machines."

"They are machines, human machines."

Contradiction.

[metaphorm]

no, people aren't machines of any kind. software development is more like creative design than assembly line work. your metaphor is flawed and the way you talk about the process and the people is misguided.