Mixing
Managing very senior individual contributors?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
16
down vote
favorite
I will be interviewing for a new position where I may be managing a software engineering team of very senior principal individual contributors (non-managers), like with 30+ years of experience. They simply don't want any more promotions to management or higher roles.
How do I motivate / incentivize them? I am probably 10-20 years younger than them.
interviewing management team
asked Nov 10 '14 at 23:18
stackoverflowuser2010
25025
suggest improvements |Â
up vote
16
down vote
favorite
I will be interviewing for a new position where I may be managing a software engineering team of very senior principal individual contributors (non-managers), like with 30+ years of experience. They simply don't want any more promotions to management or higher roles.
How do I motivate / incentivize them? I am probably 10-20 years younger than them.
interviewing management team
asked Nov 10 '14 at 23:18
stackoverflowuser2010
25025
6
Why don't you try to get to know them first so that you have some idea what makes them tick, instead of trying to get an answer like the one you're seeking without having any facts to work with?
– Vietnhi Phuvan
Nov 11 '14 at 0:52
2
That's a good point. I would like to know some more detail. Why do you think you have to do anything at all to motivate people with 30 years of experience, who you haven't even met?
– Jasmine
Nov 11 '14 at 1:24
@VietnhiPhuvan: As I've never been in this situation before, I just want to make sure I avoid making any obviously wrong first steps. Of course, it's best to get to know people first.
– stackoverflowuser2010
Nov 11 '14 at 2:00
2
You are MUCH more likely to FUBAR it when you act before you get to know the people you are managing. Because you are operating blind.
– Vietnhi Phuvan
Nov 11 '14 at 5:17
suggest improvements |Â
up vote
16
down vote
favorite
up vote
16
down vote
favorite
I will be interviewing for a new position where I may be managing a software engineering team of very senior principal individual contributors (non-managers), like with 30+ years of experience. They simply don't want any more promotions to management or higher roles.
How do I motivate / incentivize them? I am probably 10-20 years younger than them.
interviewing management team
asked Nov 10 '14 at 23:18
stackoverflowuser2010
25025
I will be interviewing for a new position where I may be managing a software engineering team of very senior principal individual contributors (non-managers), like with 30+ years of experience. They simply don't want any more promotions to management or higher roles.
How do I motivate / incentivize them? I am probably 10-20 years younger than them.
interviewing management team
asked Nov 10 '14 at 23:18
stackoverflowuser2010
25025
asked Nov 10 '14 at 23:18
stackoverflowuser2010
25025
asked Nov 10 '14 at 23:18
stackoverflowuser2010
25025
asked Nov 10 '14 at 23:18
stackoverflowuser2010
25025
25025
6
Why don't you try to get to know them first so that you have some idea what makes them tick, instead of trying to get an answer like the one you're seeking without having any facts to work with?
– Vietnhi Phuvan
Nov 11 '14 at 0:52
2
That's a good point. I would like to know some more detail. Why do you think you have to do anything at all to motivate people with 30 years of experience, who you haven't even met?
– Jasmine
Nov 11 '14 at 1:24
@VietnhiPhuvan: As I've never been in this situation before, I just want to make sure I avoid making any obviously wrong first steps. Of course, it's best to get to know people first.
– stackoverflowuser2010
Nov 11 '14 at 2:00
2
You are MUCH more likely to FUBAR it when you act before you get to know the people you are managing. Because you are operating blind.
– Vietnhi Phuvan
Nov 11 '14 at 5:17
suggest improvements |Â
6
Why don't you try to get to know them first so that you have some idea what makes them tick, instead of trying to get an answer like the one you're seeking without having any facts to work with?
– Vietnhi Phuvan
Nov 11 '14 at 0:52
2
That's a good point. I would like to know some more detail. Why do you think you have to do anything at all to motivate people with 30 years of experience, who you haven't even met?
– Jasmine
Nov 11 '14 at 1:24
@VietnhiPhuvan: As I've never been in this situation before, I just want to make sure I avoid making any obviously wrong first steps. Of course, it's best to get to know people first.
– stackoverflowuser2010
Nov 11 '14 at 2:00
2
You are MUCH more likely to FUBAR it when you act before you get to know the people you are managing. Because you are operating blind.
– Vietnhi Phuvan
Nov 11 '14 at 5:17
6
6
Why don't you try to get to know them first so that you have some idea what makes them tick, instead of trying to get an answer like the one you're seeking without having any facts to work with?
– Vietnhi Phuvan
Nov 11 '14 at 0:52
Why don't you try to get to know them first so that you have some idea what makes them tick, instead of trying to get an answer like the one you're seeking without having any facts to work with?
– Vietnhi Phuvan
Nov 11 '14 at 0:52
2
2
That's a good point. I would like to know some more detail. Why do you think you have to do anything at all to motivate people with 30 years of experience, who you haven't even met?
– Jasmine
Nov 11 '14 at 1:24
That's a good point. I would like to know some more detail. Why do you think you have to do anything at all to motivate people with 30 years of experience, who you haven't even met?
– Jasmine
Nov 11 '14 at 1:24
@VietnhiPhuvan: As I've never been in this situation before, I just want to make sure I avoid making any obviously wrong first steps. Of course, it's best to get to know people first.
– stackoverflowuser2010
Nov 11 '14 at 2:00
@VietnhiPhuvan: As I've never been in this situation before, I just want to make sure I avoid making any obviously wrong first steps. Of course, it's best to get to know people first.
– stackoverflowuser2010
Nov 11 '14 at 2:00
2
2
You are MUCH more likely to FUBAR it when you act before you get to know the people you are managing. Because you are operating blind.
– Vietnhi Phuvan
Nov 11 '14 at 5:17
You are MUCH more likely to FUBAR it when you act before you get to know the people you are managing. Because you are operating blind.
– Vietnhi Phuvan
Nov 11 '14 at 5:17
suggest improvements |Â
2 Answers
2
active
oldest
votes
up vote
41
down vote
Developers at that level of skill want a few things:
Autonomy Do not tell them how to do things. Tell them what to do and let them work out the how. However, get them to talk you through it beforehand so you have the high level understanding (e.g. 15 minutes in front of a whiteboard). After all, you need to know what is going on and want to minimize later disruptions.
Context Give them the why not just the what. I am not saying given them detailed financials. I am saying tell them the end goal. Similarly, make sure you include any assumed requirements, particularly non-functionals (e.g. performance, availability, robustness, security) where senior developers may over optimize.
Deference Involve them when making technical decisions. Do not speak for them or assume you know more. Similarly, make it clear to them that you need to be involved in cross team communication and goal setting.
Respect If the developers truly are extremely good at what they do, particularly if they have been managers or other senior roles previously, do not treat them like employees. Treat them like volunteers. Conversely, ensure they treat others with respect. It can be easy for them to talk down to people without that much experience. It can also be easy for them to "demonize" other teams. Work hard to foster good inter-team communication, particularly for remote teams.
Accountability If a developer with that much experience starts making rookie mistakes or their productivity is not where you expect it to be, make sure you let that developer know (in private) you expect more. One way of subtly achieving this is to throw in a few good passionate, talented medium level developers for the seniors to "mentor". This can use the senior developers' innate competitiveness to stop them slacking off. Otherwise, existing measures of productivity are still useful (e.g. lines of code per day, bugs per 1000 lines of code), if not to prove to other teams how good they are. Senior developers have a strong ego and you need to balance that carefully.
Focus Some developers want to encase themselves in a bubble and just code. Your job as a manager is to stop unnecessary interruptions but keep the team coherent and aligned. Good ways include enforcing code reviews (with spot checks to ensure they happen) and regular short, focused team meetings (e.g. a scrum's stand ups). If the developers do not care for things like performance reviews that HR or management mandate, make them as short and painless as possible. You also need to ensure documentation and other non-code deliverables are up to scratch and great developers may not be good at communication. This may lead to some difficult conversations.
As for incentives:
- Say thank you when they go above and beyond, which may be quite often. When they help others or fix problems without being asked, do not dismiss it as expected. It does not cost the manager anything and is great positive reinforcement.
Respect goes a long way.
Conferences and training are great rewards for the top performers. Yes, it is generally more effective as an incentive than to help under performing staff. If the developer likes presenting at these conferences, help them. They are an advertisement for your organization.
Subscriptions like O'Reily or MSDN are great. This satisfies developers' desire to learn at their own pace on a variety of subjects.- A monthly award for someone that goes out of their way to do something great (e.g. rewrite the build process, improve testing automation). Once again, this leverages developers' innate competitiveness. Similarly, if you have a culture that accepts it, a monthly award for something bad (e.g. breaking the build) can help too.
Flexibility People with lots of experience often have families or other responsibilities they are juggling. If you can, let them work from home occasionally or leave early and catch up over the weekend. Of course, the usual productivity measurements still apply. Introduce it in a trial basis with a few staff if needed.
As for yourself, managing a team of very senior individual contributors may be a big change. The team will need less management (e.g. organizing, helping under performers) but more leadership (e.g. direction, avoiding less productive activities). Do not worry about the age gap too much, as long as you do not mind the occasional quip about punch cards.
Similarly, while these developers may not chose to play the management game, they probably know a bit about how things work and how decisions are made. They can be a great resource for yourself if used carefully.
edited Jan 11 '15 at 1:45
Andrew Medico
44749
answered Nov 11 '14 at 0:13
akton
5,4811732
4
Very good answer. That's exactly what I want from my managers. We totally understand they will be younger and it's really not an issue as long as they follow these guidelines. I would change #3 to simply "Never make technical decisions" for a manager anyway. Title is important to some of us - if his title is manager, he should manage, not design or build.
– Jasmine
Nov 11 '14 at 1:21
2
The phrase "challenge me then get the hell out of my way" comes to mind :) . +1 great answer
– Radu Murzea
Jan 11 '15 at 17:51
1
+1 for all except the monthly award. That'd feel so "kindergarten" to me. If someone does something great like rewriting the build process, mention it a couple of times, e.g. in the next scrum, in the next sprint review and the next time it saves someone some serious headache. If they aren't already doing it, encourage them to thank each other whenever they get a benefit out of their colleagues extra effort.
– Sumyrda
Jan 26 '15 at 22:48
suggest improvements |Â
up vote
6
down vote
In my experience the "very senior" individual contributors are not managers for different reasons:
- They genuinely value technical contributions and development work over management
- There is some "flaw" in their skill set: Could be that they are a pain in the neck to work with and not team players, could be that they have a hard time self managing and organizing (likes to work on everything), could be that they have unconventional communication styles, want too much attention, etc.
The people in the first category are a huge asset and relatively easy to manage: Set fairly broad goals and metrics, make sure they understand and are aligned and then leave them alone. Meet once a week for a quick check in and/or chit chat.
The second category can be a real challenge. You need to find out what the main issue is, figure out whether they know about and/or acknowledge it, assess how it may affect the work and than come up with a management strategy around it. This need to be done on a case by case basis. If the person acknowledges the issue and genuinely wants to work on it, than you can design a plan to mentor and coach them through the process. If the person acknowledges the issue ("I really don't like meetings and e-mail") but has no interest in changing this, than you need to agree on the scope of work that's appropriate for this. A person like this can be great for writing a mind-boggling complicated device driver but is probably not great for a cross functional architecture team.
The most difficult case are the ones who won't acknowledge the issue. At that level they probably have been made aware of it multiple times in their career, but they simple disagree with the assessment or believe that's it's not important. In this case you will probably have to strongly tailor the assignments around the issue. If they are technically brilliant, you can still get a lot of good work done, but it's important to structure this carefully, to avoid constant frustration and conflict.
In any case, good management practices will help
- State clearly and explicitly what the ground rules are, what behavior is acceptable and what isn't.
- Set clear goals with well defined deliverables.
- Make sure the employees understand the goal and the deliverable. Make sure that they agree, that this is the right thing to work on and the right way to measure it. Work through any misalignments when needed.
- Listen to their input and feedback. Take it to heart and act on it, if appropriate
answered Jan 11 '15 at 13:54
Hilmar
23.1k65770
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
41
down vote
Developers at that level of skill want a few things:
Autonomy Do not tell them how to do things. Tell them what to do and let them work out the how. However, get them to talk you through it beforehand so you have the high level understanding (e.g. 15 minutes in front of a whiteboard). After all, you need to know what is going on and want to minimize later disruptions.
Context Give them the why not just the what. I am not saying given them detailed financials. I am saying tell them the end goal. Similarly, make sure you include any assumed requirements, particularly non-functionals (e.g. performance, availability, robustness, security) where senior developers may over optimize.
Deference Involve them when making technical decisions. Do not speak for them or assume you know more. Similarly, make it clear to them that you need to be involved in cross team communication and goal setting.
Respect If the developers truly are extremely good at what they do, particularly if they have been managers or other senior roles previously, do not treat them like employees. Treat them like volunteers. Conversely, ensure they treat others with respect. It can be easy for them to talk down to people without that much experience. It can also be easy for them to "demonize" other teams. Work hard to foster good inter-team communication, particularly for remote teams.
Accountability If a developer with that much experience starts making rookie mistakes or their productivity is not where you expect it to be, make sure you let that developer know (in private) you expect more. One way of subtly achieving this is to throw in a few good passionate, talented medium level developers for the seniors to "mentor". This can use the senior developers' innate competitiveness to stop them slacking off. Otherwise, existing measures of productivity are still useful (e.g. lines of code per day, bugs per 1000 lines of code), if not to prove to other teams how good they are. Senior developers have a strong ego and you need to balance that carefully.
Focus Some developers want to encase themselves in a bubble and just code. Your job as a manager is to stop unnecessary interruptions but keep the team coherent and aligned. Good ways include enforcing code reviews (with spot checks to ensure they happen) and regular short, focused team meetings (e.g. a scrum's stand ups). If the developers do not care for things like performance reviews that HR or management mandate, make them as short and painless as possible. You also need to ensure documentation and other non-code deliverables are up to scratch and great developers may not be good at communication. This may lead to some difficult conversations.
As for incentives:
- Say thank you when they go above and beyond, which may be quite often. When they help others or fix problems without being asked, do not dismiss it as expected. It does not cost the manager anything and is great positive reinforcement.
Respect goes a long way.
Conferences and training are great rewards for the top performers. Yes, it is generally more effective as an incentive than to help under performing staff. If the developer likes presenting at these conferences, help them. They are an advertisement for your organization.
Subscriptions like O'Reily or MSDN are great. This satisfies developers' desire to learn at their own pace on a variety of subjects.- A monthly award for someone that goes out of their way to do something great (e.g. rewrite the build process, improve testing automation). Once again, this leverages developers' innate competitiveness. Similarly, if you have a culture that accepts it, a monthly award for something bad (e.g. breaking the build) can help too.
Flexibility People with lots of experience often have families or other responsibilities they are juggling. If you can, let them work from home occasionally or leave early and catch up over the weekend. Of course, the usual productivity measurements still apply. Introduce it in a trial basis with a few staff if needed.
As for yourself, managing a team of very senior individual contributors may be a big change. The team will need less management (e.g. organizing, helping under performers) but more leadership (e.g. direction, avoiding less productive activities). Do not worry about the age gap too much, as long as you do not mind the occasional quip about punch cards.
Similarly, while these developers may not chose to play the management game, they probably know a bit about how things work and how decisions are made. They can be a great resource for yourself if used carefully.
edited Jan 11 '15 at 1:45
Andrew Medico
44749
answered Nov 11 '14 at 0:13
akton
5,4811732
4
Very good answer. That's exactly what I want from my managers. We totally understand they will be younger and it's really not an issue as long as they follow these guidelines. I would change #3 to simply "Never make technical decisions" for a manager anyway. Title is important to some of us - if his title is manager, he should manage, not design or build.
– Jasmine
Nov 11 '14 at 1:21
2
The phrase "challenge me then get the hell out of my way" comes to mind :) . +1 great answer
– Radu Murzea
Jan 11 '15 at 17:51
1
+1 for all except the monthly award. That'd feel so "kindergarten" to me. If someone does something great like rewriting the build process, mention it a couple of times, e.g. in the next scrum, in the next sprint review and the next time it saves someone some serious headache. If they aren't already doing it, encourage them to thank each other whenever they get a benefit out of their colleagues extra effort.
– Sumyrda
Jan 26 '15 at 22:48
suggest improvements |Â
up vote
41
down vote
Developers at that level of skill want a few things:
Autonomy Do not tell them how to do things. Tell them what to do and let them work out the how. However, get them to talk you through it beforehand so you have the high level understanding (e.g. 15 minutes in front of a whiteboard). After all, you need to know what is going on and want to minimize later disruptions.
Context Give them the why not just the what. I am not saying given them detailed financials. I am saying tell them the end goal. Similarly, make sure you include any assumed requirements, particularly non-functionals (e.g. performance, availability, robustness, security) where senior developers may over optimize.
Deference Involve them when making technical decisions. Do not speak for them or assume you know more. Similarly, make it clear to them that you need to be involved in cross team communication and goal setting.
Respect If the developers truly are extremely good at what they do, particularly if they have been managers or other senior roles previously, do not treat them like employees. Treat them like volunteers. Conversely, ensure they treat others with respect. It can be easy for them to talk down to people without that much experience. It can also be easy for them to "demonize" other teams. Work hard to foster good inter-team communication, particularly for remote teams.
Accountability If a developer with that much experience starts making rookie mistakes or their productivity is not where you expect it to be, make sure you let that developer know (in private) you expect more. One way of subtly achieving this is to throw in a few good passionate, talented medium level developers for the seniors to "mentor". This can use the senior developers' innate competitiveness to stop them slacking off. Otherwise, existing measures of productivity are still useful (e.g. lines of code per day, bugs per 1000 lines of code), if not to prove to other teams how good they are. Senior developers have a strong ego and you need to balance that carefully.
Focus Some developers want to encase themselves in a bubble and just code. Your job as a manager is to stop unnecessary interruptions but keep the team coherent and aligned. Good ways include enforcing code reviews (with spot checks to ensure they happen) and regular short, focused team meetings (e.g. a scrum's stand ups). If the developers do not care for things like performance reviews that HR or management mandate, make them as short and painless as possible. You also need to ensure documentation and other non-code deliverables are up to scratch and great developers may not be good at communication. This may lead to some difficult conversations.
As for incentives:
- Say thank you when they go above and beyond, which may be quite often. When they help others or fix problems without being asked, do not dismiss it as expected. It does not cost the manager anything and is great positive reinforcement.
Respect goes a long way.
Conferences and training are great rewards for the top performers. Yes, it is generally more effective as an incentive than to help under performing staff. If the developer likes presenting at these conferences, help them. They are an advertisement for your organization.
Subscriptions like O'Reily or MSDN are great. This satisfies developers' desire to learn at their own pace on a variety of subjects.- A monthly award for someone that goes out of their way to do something great (e.g. rewrite the build process, improve testing automation). Once again, this leverages developers' innate competitiveness. Similarly, if you have a culture that accepts it, a monthly award for something bad (e.g. breaking the build) can help too.
Flexibility People with lots of experience often have families or other responsibilities they are juggling. If you can, let them work from home occasionally or leave early and catch up over the weekend. Of course, the usual productivity measurements still apply. Introduce it in a trial basis with a few staff if needed.
As for yourself, managing a team of very senior individual contributors may be a big change. The team will need less management (e.g. organizing, helping under performers) but more leadership (e.g. direction, avoiding less productive activities). Do not worry about the age gap too much, as long as you do not mind the occasional quip about punch cards.
Similarly, while these developers may not chose to play the management game, they probably know a bit about how things work and how decisions are made. They can be a great resource for yourself if used carefully.
edited Jan 11 '15 at 1:45
Andrew Medico
44749
answered Nov 11 '14 at 0:13
akton
5,4811732
4
Very good answer. That's exactly what I want from my managers. We totally understand they will be younger and it's really not an issue as long as they follow these guidelines. I would change #3 to simply "Never make technical decisions" for a manager anyway. Title is important to some of us - if his title is manager, he should manage, not design or build.
– Jasmine
Nov 11 '14 at 1:21
2
The phrase "challenge me then get the hell out of my way" comes to mind :) . +1 great answer
– Radu Murzea
Jan 11 '15 at 17:51
1
+1 for all except the monthly award. That'd feel so "kindergarten" to me. If someone does something great like rewriting the build process, mention it a couple of times, e.g. in the next scrum, in the next sprint review and the next time it saves someone some serious headache. If they aren't already doing it, encourage them to thank each other whenever they get a benefit out of their colleagues extra effort.
– Sumyrda
Jan 26 '15 at 22:48
suggest improvements |Â
up vote
41
down vote
up vote
41
down vote
Developers at that level of skill want a few things:
Autonomy Do not tell them how to do things. Tell them what to do and let them work out the how. However, get them to talk you through it beforehand so you have the high level understanding (e.g. 15 minutes in front of a whiteboard). After all, you need to know what is going on and want to minimize later disruptions.
Context Give them the why not just the what. I am not saying given them detailed financials. I am saying tell them the end goal. Similarly, make sure you include any assumed requirements, particularly non-functionals (e.g. performance, availability, robustness, security) where senior developers may over optimize.
Deference Involve them when making technical decisions. Do not speak for them or assume you know more. Similarly, make it clear to them that you need to be involved in cross team communication and goal setting.
Respect If the developers truly are extremely good at what they do, particularly if they have been managers or other senior roles previously, do not treat them like employees. Treat them like volunteers. Conversely, ensure they treat others with respect. It can be easy for them to talk down to people without that much experience. It can also be easy for them to "demonize" other teams. Work hard to foster good inter-team communication, particularly for remote teams.
Accountability If a developer with that much experience starts making rookie mistakes or their productivity is not where you expect it to be, make sure you let that developer know (in private) you expect more. One way of subtly achieving this is to throw in a few good passionate, talented medium level developers for the seniors to "mentor". This can use the senior developers' innate competitiveness to stop them slacking off. Otherwise, existing measures of productivity are still useful (e.g. lines of code per day, bugs per 1000 lines of code), if not to prove to other teams how good they are. Senior developers have a strong ego and you need to balance that carefully.
Focus Some developers want to encase themselves in a bubble and just code. Your job as a manager is to stop unnecessary interruptions but keep the team coherent and aligned. Good ways include enforcing code reviews (with spot checks to ensure they happen) and regular short, focused team meetings (e.g. a scrum's stand ups). If the developers do not care for things like performance reviews that HR or management mandate, make them as short and painless as possible. You also need to ensure documentation and other non-code deliverables are up to scratch and great developers may not be good at communication. This may lead to some difficult conversations.
As for incentives:
- Say thank you when they go above and beyond, which may be quite often. When they help others or fix problems without being asked, do not dismiss it as expected. It does not cost the manager anything and is great positive reinforcement.
Respect goes a long way.
Conferences and training are great rewards for the top performers. Yes, it is generally more effective as an incentive than to help under performing staff. If the developer likes presenting at these conferences, help them. They are an advertisement for your organization.
Subscriptions like O'Reily or MSDN are great. This satisfies developers' desire to learn at their own pace on a variety of subjects.- A monthly award for someone that goes out of their way to do something great (e.g. rewrite the build process, improve testing automation). Once again, this leverages developers' innate competitiveness. Similarly, if you have a culture that accepts it, a monthly award for something bad (e.g. breaking the build) can help too.
Flexibility People with lots of experience often have families or other responsibilities they are juggling. If you can, let them work from home occasionally or leave early and catch up over the weekend. Of course, the usual productivity measurements still apply. Introduce it in a trial basis with a few staff if needed.
As for yourself, managing a team of very senior individual contributors may be a big change. The team will need less management (e.g. organizing, helping under performers) but more leadership (e.g. direction, avoiding less productive activities). Do not worry about the age gap too much, as long as you do not mind the occasional quip about punch cards.
Similarly, while these developers may not chose to play the management game, they probably know a bit about how things work and how decisions are made. They can be a great resource for yourself if used carefully.
edited Jan 11 '15 at 1:45
Andrew Medico
44749
answered Nov 11 '14 at 0:13
akton
5,4811732
Developers at that level of skill want a few things:
Autonomy Do not tell them how to do things. Tell them what to do and let them work out the how. However, get them to talk you through it beforehand so you have the high level understanding (e.g. 15 minutes in front of a whiteboard). After all, you need to know what is going on and want to minimize later disruptions.
Context Give them the why not just the what. I am not saying given them detailed financials. I am saying tell them the end goal. Similarly, make sure you include any assumed requirements, particularly non-functionals (e.g. performance, availability, robustness, security) where senior developers may over optimize.
Deference Involve them when making technical decisions. Do not speak for them or assume you know more. Similarly, make it clear to them that you need to be involved in cross team communication and goal setting.
Respect If the developers truly are extremely good at what they do, particularly if they have been managers or other senior roles previously, do not treat them like employees. Treat them like volunteers. Conversely, ensure they treat others with respect. It can be easy for them to talk down to people without that much experience. It can also be easy for them to "demonize" other teams. Work hard to foster good inter-team communication, particularly for remote teams.
Accountability If a developer with that much experience starts making rookie mistakes or their productivity is not where you expect it to be, make sure you let that developer know (in private) you expect more. One way of subtly achieving this is to throw in a few good passionate, talented medium level developers for the seniors to "mentor". This can use the senior developers' innate competitiveness to stop them slacking off. Otherwise, existing measures of productivity are still useful (e.g. lines of code per day, bugs per 1000 lines of code), if not to prove to other teams how good they are. Senior developers have a strong ego and you need to balance that carefully.
Focus Some developers want to encase themselves in a bubble and just code. Your job as a manager is to stop unnecessary interruptions but keep the team coherent and aligned. Good ways include enforcing code reviews (with spot checks to ensure they happen) and regular short, focused team meetings (e.g. a scrum's stand ups). If the developers do not care for things like performance reviews that HR or management mandate, make them as short and painless as possible. You also need to ensure documentation and other non-code deliverables are up to scratch and great developers may not be good at communication. This may lead to some difficult conversations.
As for incentives:
- Say thank you when they go above and beyond, which may be quite often. When they help others or fix problems without being asked, do not dismiss it as expected. It does not cost the manager anything and is great positive reinforcement.
Respect goes a long way.
Conferences and training are great rewards for the top performers. Yes, it is generally more effective as an incentive than to help under performing staff. If the developer likes presenting at these conferences, help them. They are an advertisement for your organization.
Subscriptions like O'Reily or MSDN are great. This satisfies developers' desire to learn at their own pace on a variety of subjects.- A monthly award for someone that goes out of their way to do something great (e.g. rewrite the build process, improve testing automation). Once again, this leverages developers' innate competitiveness. Similarly, if you have a culture that accepts it, a monthly award for something bad (e.g. breaking the build) can help too.
Flexibility People with lots of experience often have families or other responsibilities they are juggling. If you can, let them work from home occasionally or leave early and catch up over the weekend. Of course, the usual productivity measurements still apply. Introduce it in a trial basis with a few staff if needed.
As for yourself, managing a team of very senior individual contributors may be a big change. The team will need less management (e.g. organizing, helping under performers) but more leadership (e.g. direction, avoiding less productive activities). Do not worry about the age gap too much, as long as you do not mind the occasional quip about punch cards.
Similarly, while these developers may not chose to play the management game, they probably know a bit about how things work and how decisions are made. They can be a great resource for yourself if used carefully.
edited Jan 11 '15 at 1:45
Andrew Medico
44749
answered Nov 11 '14 at 0:13
akton
5,4811732
edited Jan 11 '15 at 1:45
Andrew Medico
44749
edited Jan 11 '15 at 1:45
Andrew Medico
44749
edited Jan 11 '15 at 1:45
Andrew Medico
44749
44749
answered Nov 11 '14 at 0:13
akton
5,4811732
answered Nov 11 '14 at 0:13
akton
5,4811732
answered Nov 11 '14 at 0:13
akton
5,4811732
5,4811732
4
Very good answer. That's exactly what I want from my managers. We totally understand they will be younger and it's really not an issue as long as they follow these guidelines. I would change #3 to simply "Never make technical decisions" for a manager anyway. Title is important to some of us - if his title is manager, he should manage, not design or build.
– Jasmine
Nov 11 '14 at 1:21
2
The phrase "challenge me then get the hell out of my way" comes to mind :) . +1 great answer
– Radu Murzea
Jan 11 '15 at 17:51
1
+1 for all except the monthly award. That'd feel so "kindergarten" to me. If someone does something great like rewriting the build process, mention it a couple of times, e.g. in the next scrum, in the next sprint review and the next time it saves someone some serious headache. If they aren't already doing it, encourage them to thank each other whenever they get a benefit out of their colleagues extra effort.
– Sumyrda
Jan 26 '15 at 22:48
suggest improvements |Â
4
Very good answer. That's exactly what I want from my managers. We totally understand they will be younger and it's really not an issue as long as they follow these guidelines. I would change #3 to simply "Never make technical decisions" for a manager anyway. Title is important to some of us - if his title is manager, he should manage, not design or build.
– Jasmine
Nov 11 '14 at 1:21
2
The phrase "challenge me then get the hell out of my way" comes to mind :) . +1 great answer
– Radu Murzea
Jan 11 '15 at 17:51
1
+1 for all except the monthly award. That'd feel so "kindergarten" to me. If someone does something great like rewriting the build process, mention it a couple of times, e.g. in the next scrum, in the next sprint review and the next time it saves someone some serious headache. If they aren't already doing it, encourage them to thank each other whenever they get a benefit out of their colleagues extra effort.
– Sumyrda
Jan 26 '15 at 22:48
4
4
Very good answer. That's exactly what I want from my managers. We totally understand they will be younger and it's really not an issue as long as they follow these guidelines. I would change #3 to simply "Never make technical decisions" for a manager anyway. Title is important to some of us - if his title is manager, he should manage, not design or build.
– Jasmine
Nov 11 '14 at 1:21
Very good answer. That's exactly what I want from my managers. We totally understand they will be younger and it's really not an issue as long as they follow these guidelines. I would change #3 to simply "Never make technical decisions" for a manager anyway. Title is important to some of us - if his title is manager, he should manage, not design or build.
– Jasmine
Nov 11 '14 at 1:21
2
2
The phrase "challenge me then get the hell out of my way" comes to mind :) . +1 great answer
– Radu Murzea
Jan 11 '15 at 17:51
The phrase "challenge me then get the hell out of my way" comes to mind :) . +1 great answer
– Radu Murzea
Jan 11 '15 at 17:51
1
1
+1 for all except the monthly award. That'd feel so "kindergarten" to me. If someone does something great like rewriting the build process, mention it a couple of times, e.g. in the next scrum, in the next sprint review and the next time it saves someone some serious headache. If they aren't already doing it, encourage them to thank each other whenever they get a benefit out of their colleagues extra effort.
– Sumyrda
Jan 26 '15 at 22:48
+1 for all except the monthly award. That'd feel so "kindergarten" to me. If someone does something great like rewriting the build process, mention it a couple of times, e.g. in the next scrum, in the next sprint review and the next time it saves someone some serious headache. If they aren't already doing it, encourage them to thank each other whenever they get a benefit out of their colleagues extra effort.
– Sumyrda
Jan 26 '15 at 22:48
suggest improvements |Â
up vote
6
down vote
In my experience the "very senior" individual contributors are not managers for different reasons:
- They genuinely value technical contributions and development work over management
- There is some "flaw" in their skill set: Could be that they are a pain in the neck to work with and not team players, could be that they have a hard time self managing and organizing (likes to work on everything), could be that they have unconventional communication styles, want too much attention, etc.
The people in the first category are a huge asset and relatively easy to manage: Set fairly broad goals and metrics, make sure they understand and are aligned and then leave them alone. Meet once a week for a quick check in and/or chit chat.
The second category can be a real challenge. You need to find out what the main issue is, figure out whether they know about and/or acknowledge it, assess how it may affect the work and than come up with a management strategy around it. This need to be done on a case by case basis. If the person acknowledges the issue and genuinely wants to work on it, than you can design a plan to mentor and coach them through the process. If the person acknowledges the issue ("I really don't like meetings and e-mail") but has no interest in changing this, than you need to agree on the scope of work that's appropriate for this. A person like this can be great for writing a mind-boggling complicated device driver but is probably not great for a cross functional architecture team.
The most difficult case are the ones who won't acknowledge the issue. At that level they probably have been made aware of it multiple times in their career, but they simple disagree with the assessment or believe that's it's not important. In this case you will probably have to strongly tailor the assignments around the issue. If they are technically brilliant, you can still get a lot of good work done, but it's important to structure this carefully, to avoid constant frustration and conflict.
In any case, good management practices will help
- State clearly and explicitly what the ground rules are, what behavior is acceptable and what isn't.
- Set clear goals with well defined deliverables.
- Make sure the employees understand the goal and the deliverable. Make sure that they agree, that this is the right thing to work on and the right way to measure it. Work through any misalignments when needed.
- Listen to their input and feedback. Take it to heart and act on it, if appropriate
answered Jan 11 '15 at 13:54
Hilmar
23.1k65770
suggest improvements |Â
up vote
6
down vote
In my experience the "very senior" individual contributors are not managers for different reasons:
- They genuinely value technical contributions and development work over management
- There is some "flaw" in their skill set: Could be that they are a pain in the neck to work with and not team players, could be that they have a hard time self managing and organizing (likes to work on everything), could be that they have unconventional communication styles, want too much attention, etc.
The people in the first category are a huge asset and relatively easy to manage: Set fairly broad goals and metrics, make sure they understand and are aligned and then leave them alone. Meet once a week for a quick check in and/or chit chat.
The second category can be a real challenge. You need to find out what the main issue is, figure out whether they know about and/or acknowledge it, assess how it may affect the work and than come up with a management strategy around it. This need to be done on a case by case basis. If the person acknowledges the issue and genuinely wants to work on it, than you can design a plan to mentor and coach them through the process. If the person acknowledges the issue ("I really don't like meetings and e-mail") but has no interest in changing this, than you need to agree on the scope of work that's appropriate for this. A person like this can be great for writing a mind-boggling complicated device driver but is probably not great for a cross functional architecture team.
The most difficult case are the ones who won't acknowledge the issue. At that level they probably have been made aware of it multiple times in their career, but they simple disagree with the assessment or believe that's it's not important. In this case you will probably have to strongly tailor the assignments around the issue. If they are technically brilliant, you can still get a lot of good work done, but it's important to structure this carefully, to avoid constant frustration and conflict.
In any case, good management practices will help
- State clearly and explicitly what the ground rules are, what behavior is acceptable and what isn't.
- Set clear goals with well defined deliverables.
- Make sure the employees understand the goal and the deliverable. Make sure that they agree, that this is the right thing to work on and the right way to measure it. Work through any misalignments when needed.
- Listen to their input and feedback. Take it to heart and act on it, if appropriate
answered Jan 11 '15 at 13:54
Hilmar
23.1k65770
suggest improvements |Â
up vote
6
down vote
up vote
6
down vote
In my experience the "very senior" individual contributors are not managers for different reasons:
- They genuinely value technical contributions and development work over management
- There is some "flaw" in their skill set: Could be that they are a pain in the neck to work with and not team players, could be that they have a hard time self managing and organizing (likes to work on everything), could be that they have unconventional communication styles, want too much attention, etc.
The people in the first category are a huge asset and relatively easy to manage: Set fairly broad goals and metrics, make sure they understand and are aligned and then leave them alone. Meet once a week for a quick check in and/or chit chat.
The second category can be a real challenge. You need to find out what the main issue is, figure out whether they know about and/or acknowledge it, assess how it may affect the work and than come up with a management strategy around it. This need to be done on a case by case basis. If the person acknowledges the issue and genuinely wants to work on it, than you can design a plan to mentor and coach them through the process. If the person acknowledges the issue ("I really don't like meetings and e-mail") but has no interest in changing this, than you need to agree on the scope of work that's appropriate for this. A person like this can be great for writing a mind-boggling complicated device driver but is probably not great for a cross functional architecture team.
The most difficult case are the ones who won't acknowledge the issue. At that level they probably have been made aware of it multiple times in their career, but they simple disagree with the assessment or believe that's it's not important. In this case you will probably have to strongly tailor the assignments around the issue. If they are technically brilliant, you can still get a lot of good work done, but it's important to structure this carefully, to avoid constant frustration and conflict.
In any case, good management practices will help
- State clearly and explicitly what the ground rules are, what behavior is acceptable and what isn't.
- Set clear goals with well defined deliverables.
- Make sure the employees understand the goal and the deliverable. Make sure that they agree, that this is the right thing to work on and the right way to measure it. Work through any misalignments when needed.
- Listen to their input and feedback. Take it to heart and act on it, if appropriate
answered Jan 11 '15 at 13:54
Hilmar
23.1k65770
In my experience the "very senior" individual contributors are not managers for different reasons:
- They genuinely value technical contributions and development work over management
- There is some "flaw" in their skill set: Could be that they are a pain in the neck to work with and not team players, could be that they have a hard time self managing and organizing (likes to work on everything), could be that they have unconventional communication styles, want too much attention, etc.
The people in the first category are a huge asset and relatively easy to manage: Set fairly broad goals and metrics, make sure they understand and are aligned and then leave them alone. Meet once a week for a quick check in and/or chit chat.
The second category can be a real challenge. You need to find out what the main issue is, figure out whether they know about and/or acknowledge it, assess how it may affect the work and than come up with a management strategy around it. This need to be done on a case by case basis. If the person acknowledges the issue and genuinely wants to work on it, than you can design a plan to mentor and coach them through the process. If the person acknowledges the issue ("I really don't like meetings and e-mail") but has no interest in changing this, than you need to agree on the scope of work that's appropriate for this. A person like this can be great for writing a mind-boggling complicated device driver but is probably not great for a cross functional architecture team.
The most difficult case are the ones who won't acknowledge the issue. At that level they probably have been made aware of it multiple times in their career, but they simple disagree with the assessment or believe that's it's not important. In this case you will probably have to strongly tailor the assignments around the issue. If they are technically brilliant, you can still get a lot of good work done, but it's important to structure this carefully, to avoid constant frustration and conflict.
In any case, good management practices will help
- State clearly and explicitly what the ground rules are, what behavior is acceptable and what isn't.
- Set clear goals with well defined deliverables.
- Make sure the employees understand the goal and the deliverable. Make sure that they agree, that this is the right thing to work on and the right way to measure it. Work through any misalignments when needed.
- Listen to their input and feedback. Take it to heart and act on it, if appropriate
answered Jan 11 '15 at 13:54
Hilmar
23.1k65770
answered Jan 11 '15 at 13:54
Hilmar
23.1k65770
answered Jan 11 '15 at 13:54
Hilmar
23.1k65770
answered Jan 11 '15 at 13:54
Hilmar
23.1k65770
23.1k65770
suggest improvements |Â
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f36080%2fmanaging-very-senior-individual-contributors%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
6
Why don't you try to get to know them first so that you have some idea what makes them tick, instead of trying to get an answer like the one you're seeking without having any facts to work with?
– Vietnhi Phuvan
Nov 11 '14 at 0:52
2
That's a good point. I would like to know some more detail. Why do you think you have to do anything at all to motivate people with 30 years of experience, who you haven't even met?
– Jasmine
Nov 11 '14 at 1:24
@VietnhiPhuvan: As I've never been in this situation before, I just want to make sure I avoid making any obviously wrong first steps. Of course, it's best to get to know people first.
– stackoverflowuser2010
Nov 11 '14 at 2:00
2
You are MUCH more likely to FUBAR it when you act before you get to know the people you are managing. Because you are operating blind.
– Vietnhi Phuvan
Nov 11 '14 at 5:17