Managing very senior individual contributors?

Question

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.

Answer 1

Developers at that level of skill want a few things:

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

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

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

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

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

6. 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:

1. 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.
2. Respect goes a long way.
3. 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.
4. Subscriptions like O'Reily or MSDN are great. This satisfies developers' desire to learn at their own pace on a variety of subjects.
5. 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.
6. 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.

Answer 2

In my experience the "very senior" individual contributors are not managers for different reasons:

1. They genuinely value technical contributions and development work over management
2. 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

1. State clearly and explicitly what the ground rules are, what behavior is acceptable and what isn't.
2. Set clear goals with well defined deliverables.
3. 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.
4. Listen to their input and feedback. Take it to heart and act on it, if appropriate