How to lead a group of developers who have much more talent than you

Question

I recently was asked to take a hybrid leadership/development role with the client I am working for. I will be billing at a higher rate and responsible for reporting and other administrative tasks.

I am not concerned about my leadership skills, as I have led teams before. However, in this role I am not really the boss of the team -- I can't make staffing decisions and am largely only responsible for reporting on my teams status to the next level up. I will be billing at ~150% of what my teammates are billing.

My concern is that my team consists of people who all started before me and have a tremendous amount of development experience that I lack. How will this team respect me when they know my technical skills are, well, lacking at best -- at least in comparison with them. All of them would have been good choices for the leadership position I am taking.

Are these justifiable concerns? How can I help to alleviate the frustration that some of my team members could potentially feel?

Related: this question, however, these aren't expert senior level teammates i'll be looking after. Entry level and a step above.

EDIT: I really want to clarify based off some of the comments/answers. I am not moving to a management position. I am also not worried in my ability to lead the team. I largely was worried about how my former equals will feel about this transition and how I can alleviate some of the concerns they will have. And as many posters have pointed out, for the most part -- be a good leader and let them get over it is plenty of advice.

Answer 1

As a developer these are things I hate:

1. Requesting software/resources taking forever and needing loads of forms etc.
2. Stupid requirements that are contradictory to other features or tecnically not possible due to existing functionality.
3. Unreasonable and arbitrary/pulled out of thin air deadlines being set.
4. Not knowing the priority of my work.

So, if you can sort the above out, then I wouldn't give a damn what you're on. If you make my life easier, when you ask me to do X/Y, then i'm going to be much more inclined to do my best to help you out.

Use your technical knowledge to ensure the developers get what they need and the business knowledge to sort out when stuff is getting done.

There will be people who don't like it (i.e. those who wanted it etc). Treat that as usual management practice (so look for relevant questions on here for guidance).

You aren't being picked to do "management tasks" because you are the best developer. You are being picked to do them because you have been deemed as the person to do that role most effectively.

Answer 2

You do not have to be the best developer on the team to be the lead. It is important that you are technically competent to maintain respect, as you are in a hybrid role. Never lose sight that you are a developer too, as I would gather that it will remain at least 50% of your role.

IMHO most good developers have no interest in being burdened with administrative work, so you have nothing to worry about in that regard. Do what you need to do to fulfill the new "lead" responsibilities, but focus on remaining a good team mate.

Answer 3

A team of talented developers look to their dev manager not to be better than them at development, but to be a defender against drains on efficiency. Your administrative work will be critical.

Director comes down asking for X coworker's time when that coworker is already 100% allocated to another project? Be there to talk to the director, explaining priorities, and prevent interruption to the coworker.

Additionally, if there is a technical decision to be made, enlist your talented coworkers to give you their opinion. Knowing they are stronger technically than you, and showing it by asking for their input on decisions, is important.

Answer 4

My advice to you is not to sell yourself short.

Immediately drop the attitude that you're somehow inferior to them, and never, ever express that idea to the team, or let it show that you've even once thought it.

The guy in charge doesn't need to be an expert tech, he needs to provide direction and leadership. Solve conflicts, assign tasks, generate performance metrics, etc. If they could do your job they would be the ones billing at 150%. They're not.

As far as "alleviating frustration" goes, don't be afraid to acknowledge that some of them have more knowledge than you, and always give credit where its due. If there's an issue and [X] solves it, praise him, and acknowledge to management/the client that [X] saved the day. However, do not tolerate any challenge to your leadership. Sure, you're not the best developer, but you're the leader, and that's not negotiable.

Answer 5

Do you think a football Coach is a better thrower than the star quarterback?

Although both of the above know how to play football, they have different functions - and skills - on the team.

Your description sounds like the "servant-leader" model - and your lack of technical skills in relation to your team will actually help you to be successful.

You will earn the respect of the team by recognizing their talents and leveraging them appropriately.

For example, if someone is smarter than you on "Subject X" then consult with them about "Subject X" when making a decision. This shows several things: (1) you recognize their talent, (2) you respect their talent, (3) you want the team to be successful - not you.

Let them lead you technically, while you lead them professionally.

Success indicator: When your project is done, it should feel as if the Team accomplished it - not you - or any one person.

Answer 6

So... here's the deal. You work with developers who are better at developing than you are. That's perfectly fine! In fact, you understanding this right away puts you ahead of a big chunk of middle managers out there who never get to this point, either because they purposefully hire people who aren't as good as they are or because they're so consumed with Dunning-Krueger that they never "get" how much better the people around them are.

But you aren't being paid to write code, you're being paid to manage other people writing code. So... maybe this will help: think of yourself as less of a "leader" in the sense of a team captain and more of a support staff for them. Be that screen between the upper management and your guys: if someone up top has issues with your team's work or if they need a certain job done in X amount of time, make sure that you and not one of the devs is the person getting that info (and then log the issue and prioritize it). If you don't have a BA, act as one. Speaking as a dev, if I have to talk to non-devs I will but I know that I really, really appreciate it when there's someone in between me and the hoi polloi.

The other thing I think that really works that a lot of devs don't necessarily do on their own is lots and lots of communication. Are you working in Agile/Scrum? If not, I'd consider it strongly. Even if you're doing pure Waterfall because your company dictates that you do, there's no reason not to add in some aspects of Agile/Scrum like the daily standup or estimating workload by "sprint" in terms of points. If someone is struggling with a task, grab a more senior dev to talk with them about how to get through it, and try to foster an attitude of "we succeed and fail as a team" so that the folks who might fall behind can catch up with the help of those who are ahead.

Finally, you're the person in charge of the systems, stuff like the code base, the check-in process, testing, etc. As a programmer with ADHD, I am a. really, really disorganized at times, and b. I am far, far, far from the only person working in this profession with that particular condition. I personally benefit a lot from having a management/support team willing and able to provide structure. The less I have to think about that stuff, the more I can concentrate on writing code - oh look! Bird!

You can also use this place to try out new things, and I feel like the more of this you do, the more your people below you will appreciate the effort. Have you all tried pair programming? There are folks out there who say that it's actually just as efficient if not more efficient in terms of lines written per man-hour than man-to-man coding. Maybe it'll work well for your guys, maybe it won't. You'll never know until you try! How deeply is your team committed to test-driven development? How about code review? I can't say that any one of these things will work for your team but a willingness to be open and try new things will trickle down, I think.

Answer 7

It is rare for a manager to be much of a developer in the eyes of subordinates, because managers can't spend much time programming, causing their knowledge to fade. I don't care if a manager has ever programmed,

On the other hand, I can't manage emptying a glass of water with the instructions written on the bottom. Without a good manager, I am big in trouble. I always prioritize and read people the way I think is right and no one ever agrees. Without a manager to help me with that, I always die from political causes. If I am lucky, my manager helps and protects me so I can focus on my job.

I have a question for you. Why did you get this job, instead of the other guys? What justifies your time being billed for 150% the other folks? If you don't know the answers, you need to figure it out.

Here is a hint. Programming is easy compared to management. Computers are great, people are a pain in the butt. You will be dealing with economic and time pressures the programmers cannot do much about. They are always working their butt off and generally cannot speed up. Your project is going to be under pressure to take too long and cost too much. Someone, hopefully you, will need to figure what to change in plans so you can cut work and still meet the critical objectives of your clients. If you are not good at that, you will be replaced.

To get the best from your team, they are going to need to be inspired by your project, either for the nature of system, the objectives supported by the system, or the money they will get by completing the work. To facilitate, you need to be excited by the work, or accept that the work environment and objectives aren't that great.

Answer 8

I think Andrew Berry already hit the nail on the head, this answer is really an extended comment. I wouldn't disclose to them you are making more money as a result of the new managerial tasks you perform.

A friend told me about something similar that happened at her company.The developers were happy have someone to take care of the administrative work which was something they despised. They didn't see the person as a boss more as a colleague who was in charge of running scrum and making some power-point reports for management etc, and nothing really changed in their relationship. Until somehow the money information was leaked, and suddenly there was a lot of resentment towards the person running in the 'management' position.

Moral of the story, your salary information should be confidential to your co-workers.

Answer 9

Developers will usually recognise that any team needs someone to take care of the administrative tasks and management things. If you can become recognised as the team member who does that, you will have succeeded.

To achieve this, what you need to do is: do the work. Make plans. Execute them. Make sure all the things that you are responsible for stay working. After a while, you will be appreciated.

Answer 10

As most answers are pretty long I'd like to add a simple one.

You can't expect to be better at everything as your team. Which is obvious and could be a good thing. Discuss targets with your team, engage with them. They'll make clear what you can and can not do. If you make sure you value their opinions but also make clear which things are not important it should be perfectly fine.

As far as I know as developer I just want people to know what I'm capable of and be heard when I think my opinion has value, I think most developers are like this.

Answer 11

I'd say, relax.

I was a consultant for over 20 years, and have been both manager and managee, and it's exceedingly rare that the manager is the best or sharpest developer in a team.

The role of a development manager is to get the best out of his team, and doing this requires 20% technical skills, and 80% people skills. Your job is to understand the relative strengths of each member of your team, to nurture productive communication, to help them flourish and grow in their roles, to protect them from the hailstorms of bullshit that most organizations generate, and to make each feel acknowledged and appreciated in their work.

These are all "soft" skills: your technical skills help you understand the development process, and the larger design choices your project entails. But these are really helpful only to the degree that you can help keep your team happy, focused and productive.

Just please, please don't pretend to have knowledge or skills that you do not. It sounds like you're a bit intimidated by the skill level of your team, but your role is not to be the smartest guy in the room. It's to plant the seeds, fertilize the soil, and keep the locusts away. And if you do that well, you will have earned your pay and the respect of your team.

Answer 12

@USER_8675309 - You can be a great leader regardless of how your developer skills compare to your team. You lead by supporting your team and leading from behind rather than the front. In this case rather than giving orders and taking a machiavellian approach to leadership you should focus on providing the team with enough resources and time to ensure that the results achieved are the result of true collaborative and creative thinking. Remember that each of your team has their own individual skills and talents. Its for you to recognise these talents and identify emerging leaders. Do the right thing rather than do by the right thing! Good luck dude...you got this!