6 ms·

True but what if there's skill gap between team members.

by xylo 9y ago

9point6 9y ago
The employer should endeavour to close those gaps via training or even just advocating things like more pairing. It shouldn't be acceptable for a developer to silo themselves off from the rest of their team (except maybe a non-artificially-short-deadline or start-up type environment).
zzalpha 9y ago
The skilled devs should be coaching the less skilled devs, including pairing on work, code reviews, etc, in order to spread the skills around. Meanwhile, management should provide opportunities for training and so forth to develop their talent.
- infinite8s 9y ago
  Not only that - management should actively provide incentives for the more skilled devs to coach the less skilled ones, otherwise it just becomes extra work.
WWKong 9y ago
Then the higher skilled members should devote a significant amount of time getting others to level up. It is a team. Management should have structure in place to incentivice it. If they don't have a structure in place then the high skilled members should devote time to make a proposal and pitch it. Find a way to win as a team.
noobiemcfoob 9y ago
haha everyone says "just train your employees more!". I do like the the "get them to level up" mentality. BUT... it won't work. We're all on a spectrum of ability. Maybe more so, we're all on a spectrum of ability spectrums. Training, education, these aren't the answer to "my devs aren't as good as that one". You take the ability you have, your team has, and you manage and apply it the best way you can. Most often, that doesn't mean having your top developer spend her time training everyone else. It means you give that top developer the protection and time she needs to get her shit done. If she happens to be the type that gets energy from training and helping others, THEN you have her train others. In computer engineering terms, you have to balance your control path as well as your data path.
- zzalpha 9y ago
  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 9y ago
    > 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 9y ago
      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.

True but what if there's skill gap between team members.

by xylo 9y ago

True but what if there's skill gap between team members.

The employer should endeavour to close those gaps via training or even just advocating things like more pairing. It shouldn't be acceptable for a developer to silo themselves off from the rest of their team (except maybe a non-artificially-short-deadline or start-up type environment).

zzalpha 9y ago

The skilled devs should be coaching the less skilled devs, including pairing on work, code reviews, etc, in order to spread the skills around. Meanwhile, management should provide opportunities for training and so forth to develop their talent.

infinite8s 9y ago
Not only that - management should actively provide incentives for the more skilled devs to coach the less skilled ones, otherwise it just becomes extra work.

WWKong 9y ago

Then the higher skilled members should devote a significant amount of time getting others to level up. It is a team. Management should have structure in place to incentivice it. If they don't have a structure in place then the high skilled members should devote time to make a proposal and pitch it. Find a way to win as a team.

noobiemcfoob 9y ago

haha everyone says "just train your employees more!". I do like the the "get them to level up" mentality. BUT... it won't work. We're all on a spectrum of ability. Maybe more so, we're all on a spectrum of ability spectrums. Training, education, these aren't the answer to "my devs aren't as good as that one". You take the ability you have, your team has, and you manage and apply it the best way you can. Most often, that doesn't mean having your top developer spend her time training everyone else. It means you give that top developer the protection and time she needs to get her shit done. If she happens to be the type that gets energy from training and helping others, THEN you have her train others. In computer engineering terms, you have to balance your control path as well as your data path.

zzalpha 9y ago
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 9y ago
  > 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 9y ago
    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.