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.

  • 3
    Possible duplicate of Managing very senior individual contributors? – gnat Feb 22 '17 at 19:38
  • 88
    Re "my technical skills are, well, lacking at best", isn't this the definition of a manager? Seriously, do your management tasks well. – jamesqf Feb 22 '17 at 19:41
  • 5
    @jamesqf A better rephrase of this would be "my confidence in my technical skills is lacking at best" – USER_8675309 Feb 22 '17 at 20:23
  • 14
    @USER_8675309 - That doesn't change the meaning that much. Most technical people are managed by non-technical people. Just because you started in a technical position does not mean you won't be respected as a manager. Really, the only way to lose respect is if you flaunt your "technical knowledge" and are wrong. A.K.A. "We should do it this way" when you only personally believe that due to your lack of technical skill. If you don't know, just defer to someone who does. That's not only okay, but it is, in fact, good practice. – EvSunWoodard Feb 22 '17 at 20:31
  • 47
    Those who can, do. Those who can't, lead. – dotancohen Feb 23 '17 at 6:39

12 Answers 12

up vote 281 down vote accepted

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.

  • 108
    Yep, act as an expediter, and your team will love you. +1 – Richard U Feb 22 '17 at 17:54
  • 74
    +1 from me too. My favorite boss ever didn't know the first thing about writing code, but he was an advocate for me. I knew he always had my back and would be a buffer between me and the client or management. I wouldn't trade that for any amount of technical excellence. – Kat Feb 22 '17 at 21:21
  • 56
    Bonus points: it can sometimes be counterproductive to have the best developer doing "management tasks"- they're spending time managing that they could be using to write more/better code. Ideally, you want the "management" guy to be the least good developer that can do the management effectively. – Delioth Feb 22 '17 at 22:05
  • 11
    "You aren't being picked to do "management tasks" because you are the best developer." +1. The set of skills of a good manager are different from a good developer. Be a good manager and they won't care about your tech skills. – angarg12 Feb 23 '17 at 7:59
  • 26
    5. Don't do stupid things like not giving developers admin access to their own machines. (This almost falls under #1 but not quite.) – Mehrdad Feb 23 '17 at 11:08

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.

  • 61
    You don't even need to be competent, as long as you listen to competent developers and don't claim to know better. – gnasher729 Feb 22 '17 at 19:19
  • 12
    Yes, +1 for retaining a generous dose of humility – G. Ann - SonarSource Team Feb 22 '17 at 20:30
  • 4
    @gnasher729 Being somewhat competent is advantageous here. It enables you to weed out BS, and make smarter decisions that impact your team more positively. Simply listening to someone who seems to know what they are talking about, but being unable to filter through that information intelligently, will lead to poor decision making. For example, all the developers that get all worked up over the latest hotness/buzz technology, but don't really consider if it's actually practical to use or the best technology for the task. If you don't know any better, you'll make that mistake, then regret later. – SnakeDoc Feb 23 '17 at 19:13
  • 2
    @gnasher729, being completely incompetent will be a problem. It will be very hard to understand the developers. This leads (at lease from what I've seen) technically incompetent managers to over-planning and over-documentation. "I don't understand it, but at least I have it written down" fallacy. And that's assuming that developers have best intentions; they might not, they might see manager as incompetent and try to BS them. – Akavall Feb 25 '17 at 18:37
  • @SnakeDoc + Akavail: The OP is working with people who have "much more talent" then he does, as developers. He doesn't need competence as a developer, but as a manager. A good manager will detect bullshit without being competent at development. And competent developers will do anything to support someone who is competent as a manager who keeps all the things away that developers hate. – gnasher729 Feb 26 '17 at 1:17

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.

  • 4
    I agree a lot with this advice. Rather than thinking of yourself as a boss who's supposed to boss people around, see yourself as a team member who's working with the team, use your team's strengths instead of trying to belittle them or put yourself above them. You're in charge of things, but you're allowed to use the tools at hand in the way they're intended, ask for technical advice when needed and trust your team. – Gemtastic Feb 23 '17 at 8:16
  • 2
    This matches my experience as a technical lead of a team containing people with skills superior to mine. The lead's role is to make things happen (and insulate the team), not necessarily to do them personally. (On my team it also involved some of the custodial work; I did all the branch integrations back to main, for example.) – Monica Cellio Feb 23 '17 at 15:57
  • 2
    This needs quadruple emphasis on the be there part. – a CVn Feb 23 '17 at 21:22

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.

  • I agree with that, however, I think it lacks some things that OP should avoif. Personally, when I have someone above me which has some background tech but is clearly lacking, I really don't like when he's trying to circumvent some things I affirm (ex : estimation) by saying things that are either wrong or not enough precise. The best project manager I ever had was a 100% no technic one. He asked us for an estimation, he wouldn't discuss it. TL;DR don't try to do some tech work as a manager, let us handle that and trust us and focus on your leading and management. – Walfrat Feb 22 '17 at 16:12
  • 5
    @walfrat - I never suggested that the OP ignore technical advice. My own manager is a former self-taught dev who's lost touch with tech in order to transition to full time management. He asks for clarification, but will back up my decisions when he realizes he's out of his depth. However, when he makes a decision, I follow his lead. I may argue in private that it's a poor decision, but he's still the boss. – AndreiROM Feb 22 '17 at 16:15
  • 1
    +1 for the first two lines. If you don't have confidence in yourself, then nobody else will either. That doesn't mean you should ignore the skills of your devs, but do not ever imply that you think you are unsuited for the job, or that they would be better at it. – Kat Feb 22 '17 at 21:13
  • I didn't say you suggested that. My point was saying that you say things that OP should do, but I think it lacks some suggestions about what the OP should not do against the type of profile he has to manage. – Walfrat Feb 23 '17 at 8:24
  • Good advice. It would help to also include some info on what you perceive as the "challenge to your leadership" you mentioned, and how to tackle it without burning the house down. There's a saying "If you have to say you are the leader, it's pretty obvious you are not". – Nav Mar 4 '17 at 14:29

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.

  • You do realise that not everyone knows who Bill Belichick and Tom Brady are. Sports analogies are rarely useful. – adelphus Feb 23 '17 at 0:53
  • 3
    @adelphus The answer itself makes it obvious that Tom Brady is a quarterback. My first guess was that Bill Belichick is a coach, and a 2 second Google search confirmed it. If you're worried about it, turn the names into Wikipedia links or something. – jpmc26 Feb 23 '17 at 8:08

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.

  • 1
    The OP is serving in a hybrid role, so he does get paid to write code a good portion of the time. The OP is a lead, not a manager. – Mister Positive Feb 22 '17 at 19:06

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.

  • @antipattern I need to learn something from what you are asking. I see leeches in management, but how can a programmer be leech? – DanAllen Feb 26 '17 at 7:39
  • 1
    Perhaps leech is a bad wording. What I was refering to was that guy who appears to work very fast and always "finishes" in time. If a manager is not capable of judging the quality of the work, this guy might have just worked on the main code path, and left a ton of bugs / unhandled minor cases in there. It is a part of the managers job to make sure that not only there is an implementation, but also that this implementation works as advertised. Did that make it clearer to you? – antipattern Feb 27 '17 at 13:10

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.

  • This is good advice. There's two things here -- 1) my billing rate increase is very well known to the rest of the team and 2) our salaries are not directly impacted by our billing rates. Basically, I can't hide that I'm billing at a higher rate but wage information is not readily available regardless of what you bill at – USER_8675309 Feb 27 '17 at 12:13

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.

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.

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.

@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!

protected by Jane S Feb 27 '17 at 2:06

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.