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
    Commented Feb 22, 2017 at 19:38
  • 90
    Re "my technical skills are, well, lacking at best", isn't this the definition of a manager? Seriously, do your management tasks well.
    – jamesqf
    Commented Feb 22, 2017 at 19:41
  • 5
    @jamesqf A better rephrase of this would be "my confidence in my technical skills is lacking at best" Commented Feb 22, 2017 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. Commented Feb 22, 2017 at 20:31
  • 47
    Those who can, do. Those who can't, lead.
    – dotancohen
    Commented Feb 23, 2017 at 6:39

12 Answers 12


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.

  • 109
    Yep, act as an expediter, and your team will love you. +1 Commented Feb 22, 2017 at 17:54
  • 76
    +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
    Commented Feb 22, 2017 at 21:21
  • 57
    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
    Commented Feb 22, 2017 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
    Commented Feb 23, 2017 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.)
    – user541686
    Commented Feb 23, 2017 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.

  • 62
    You don't even need to be competent, as long as you listen to competent developers and don't claim to know better.
    – gnasher729
    Commented Feb 22, 2017 at 19:19
  • 13
    Yes, +1 for retaining a generous dose of humility Commented Feb 22, 2017 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
    Commented Feb 23, 2017 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
    Commented Feb 25, 2017 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
    Commented Feb 26, 2017 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
    Commented Feb 23, 2017 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.) Commented Feb 23, 2017 at 15:57
  • 2
    This needs quadruple emphasis on the be there part.
    – user
    Commented Feb 23, 2017 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
    Commented Feb 22, 2017 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
    Commented Feb 22, 2017 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
    Commented Feb 22, 2017 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
    Commented Feb 23, 2017 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
    Commented Mar 4, 2017 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
    Commented Feb 23, 2017 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
    Commented Feb 23, 2017 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.
    – Neo
    Commented Feb 22, 2017 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
    Commented Feb 26, 2017 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? Commented Feb 27, 2017 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 Commented Feb 27, 2017 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!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .