I am a People and Culture person for a medium sized tech company (300 developers). We have the usual turnover most tech companies have so are constantly replacing people.

One of the challenges we face is in replacing software and machine learning team leads. They leave just as often as anyone else. We usually start by offering the position to a member of the existing team, but 8 times out of 10, they decline.

While we can hire candidates externally, the lack of leadership by the engineers also shows through here. They usually are not up to speed and the engineers seem willing to let them make mistakes and take projects in disastrous directions. One exec sat in a meeting where the engineers let a team lead completely misunderstand who the customer was for the project and set project goals which made no sense but they went along with anyway.

We have had a few utterly disastrous projects because a new team lead misunderstood something, nobody really tried to correct him, and this went on for months with the engineers at most offering small corrections and if that was not heard or was ignored the first time around, just going with it.

I am not an engineer, so I am mostly just repeating notes and a few of my own observations, but I have been tasked with solving this.

Any ideas? Ideally we want them to lead the teams as they know about the products and the engineering considerations. But even if they do not we would like them to be less passive.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – DarkCygnus
    Dec 23, 2020 at 3:22
  • Did you consider publish some of your source code with an open source license? This might attract developers Dec 27, 2020 at 16:56
  • Does the company show some sort of "you shall listen to your superiors" culture? Or alternatively, a "he who smelt it, dealt it" attitude to problems that are reported? I'm asking because the predominant reason for team members not speaking up is a history of being ignored or told not to speak up; or when speaking up lands them in trouble or makes them responsible for something they did not cause.
    – Flater
    Jan 7, 2021 at 14:39

12 Answers 12


First of all, a disclosure : I am a Software Engineer.  

Been there, Done (exactly) that.
Within the teams I worked with, I was the go-to person for answers or advice (generally work related but not always) as I was in friendly terms with -almost- all the team members.
I was proposed for the Team Lead role. I left the company a couple of months later for the following reasons:

  1. More workload with the same pay grade & title. Pay rises were declined. I was better off with my role within the team helping as I could (time wise).
  2. No training offered, formal or not. (soft skills, project leadership, ... ). Not that I had difficulties in those areas, but I saw it as benefits as I want to constantly improve and gain new knowledge
  3. Also, there was no tutoring by management and constructive follow ups.
  4. No room for decisions : when I intended to implement features that would benefit the project in a certain technical way, management got in the way & demanded the old twisted way as it brought more money (but destroyed the team)
  5. Advice & Recommendation not heard (goes with the previous point) : In my first 2 weeks in the role, I recommended much needed changes, but got passive rejection, then a HARD one. As I learned after two years, management was obliged to make these changes after 2 years.

I left to the same position in a different company, but with not a single issue from those above, while doing pretty much the same job/responsibilities.
I think that's a bias thing where in-house candidates do not benefit from the same appreciation as external ones.

My recommendation is to address the 5 points above and offer more help to in-house candidates.


You ask how to get your engineers to lead, but I think you have a different underlying problem. As you mention:

One exec sat in a meeting where the engineers let a team lead completely misunderstand who the customer was for the project and set project goals which made no sense but they went along with anyway.

We have had a few utterly disastrous projects because a new team lead misunderstood something, nobody really tried to correct him, and this went on for months with the engineers at most offering small corrections and if that was not heard or was ignored the first time around, just going with it.

I'm not sure what's going on here, but this indicates you have a big problem. Your engineers aren't speaking up when they know the project is heading for failure. Why is that?

  • Is it because they're not invested in the success of projects? Why not? Most good engineers like their projects to be successful.
  • Is it because they're afraid of speaking up in the presence of execs?
  • Do they expect their comments to go unheeded anyway? Are you actually listening to your engineers?

I don't think you can solve the problem of engineers being willing to lead if they're not even willing to speak up about the projects at all. You need to figure this out first.

In addition to that, being a team lead brings more responsibilities and requires different skills. Are you offering -

  • Appropriate salary increase?
  • Training in the required (soft) skills?
  • Respect for the team lead's technical knowledge? I.e. if the team lead says what a customer wants is technologically difficult, can your salesperson overrule them?
  • Public support? It's okay for management and team leads to have different views on where the team should go, but that should be discussed behind closed doors. In public the management should support the team lead's authority.
  1. A lot of engineers simply have no interest. I haven't written it off, but from what I can tell it is a job I would find difficult as person to person interaction is very taxing of me. I suspect I will give it a try at some point as ambition will outweigh my annoyance, but if I get the job, I will go into it knowing that I will probably leave it within a year and could easily underperform while doing it. Some engineers have done it already, have left, and are satisfied on the technical side. You see this showing up in questions frequently. If you have a technical promotion track, then this exacerbates it to a certain extent.

  2. There could be something wrong on the teams that causes the engineers to not be interested. Are you sure that the problems started when the new team leads arrived or did they just become more noticeable? The engineers on those teams could very well know about issues that you are unaware of and that could be the reason they are turning down your offer.

  3. Why would you expect an ignored point to be pressed? The engineer tried to warn them and was ignored. You saw it once, but it could easily have happened many times. Why do you blame the engineer for not repeating themselves rather than blaming the lead for ignoring important information?


set project goals which made no sense but they went along with anyway

No offense, but being asked to go along with goals that make no sense to us is par for the course for an engineer. We point out risks and raise objections, and if those objections are overruled, we do our best to move as far toward the goal as possible.

We "go along" with crazy-sounding goals because we realize we have a different view of the project. We can see technical flaws, and know technical improvements we'd like to make, but usually have little to no insight into what will actually make the company money.

That's why project management exists and engineers don't just build what they want. You'd end up with a technically elegant product that no one will buy. Conversely, if you don't listen to engineers enough, you end up with a product that ticks all the marketing boxes, but doesn't work well.

If you want engineers to lead, you need to recognize where they are good at leading, and where they are not. To lead well, engineers need to be given clear business priorities but latitude in how those priorities are carried out.


I am a strong technical person and also have been in consulting and leadership positions, both home and abroad.

I was also "invited" to take over another department in the past, behind closed doors, with no official announcement, and was naive enough to accept that. Same salary rank, but with 4x more responsibilities, working with two-three unexperienced coworkers, who should be bellow my rank but were actively encouraged not to report to me, not having tasks assigned by me, and undermine my work, due to internal political power plays. Ultimately, I got fed up, ended up leaving, and they placed two job adverts for replacing me.

On other two occasions, was also hired as a "sysadmin" and ended up as a network+system manager+IT director answering directly to upper management. Luckily one of those positions, abroad, came with the corresponding pay grade, power and respect, and support/mentorship from the CEO, the first one in my second job did not.

There is zero incentive having the added responsibility of "leading" people and not having a significant pay increase; and also being a paper tiger, not appointed officially. Thus, I would prefer keeping doing the technical stuff, and leaving the annoying political and bureaucratic stuff to my superiors. And tend to avoid it, even more if I will end up doing two jobs.

I had two job offers, after the current (well paid) job where basically I would be an effective technical manager+IT director+system/network manager, leading 15-20 people earning the same salary range (or less) as of today, and told the interviewing persons "I like it where I am now, been there, done that, no title, not doubling my net salary, forget about it.".

In addition, I have witnessed other type of problems in organisations where the main business is not IT oriented, in which IT people is dealt with as cogs, even HR being very rigid with them, and at the same time management wanting flexibility back. If you deal with them as yet another cog in your organization, your wishes come true, congratulations, you have cogs.

So, actually, the "problem" might not be your engineers being passive, if there is not:

  • a significant pay raise;
  • an official promotion;
  • a well defined chain of command;
  • a visible endorsement and support from the upper echelons of the organisation;
  • them having not the power and space to take decisions concerning their source of expertise.

Offer some motivation to be a Team Lead: pay and / or benefits (this can be career path or other things - perhaps evaluate what they want).

Otherwise the engineers will look at the Team lead post as being more work / responsibility for the same benefit so come to the conclusion of “why should I work extra for free”?

Unless this is what you already do, and then the compensation may just be too small for the perceived work (which, as engineers, they probably evaluate rapidly). Have you estimated the extra work in being a Team Lead?

Also, what is the culture in the meetings? If an engineer offered a correction and was ignored / not heard / or told be quiet then the phrase “flogging a dead horse” comes to mind. Who controls the meeting? How are suggestions / questions / points dealt with?

  • There is another aspect I would mention since pay isn't the only factor. There also needs to be a clear career path and training support. I have seen a place where being a TL was a career dead end and only 5-10% of TLs ever got to the next career level in management and at the same time weren't considered for senior promotions anymore.
    – Helena
    Dec 20, 2020 at 10:06
  • @Helena perhaps my use of “benefits” is not sufficient - will edit.
    – Solar Mike
    Dec 20, 2020 at 10:44
  • @Helena I have seen that problem several times, and especially in SMB where the core business is non-technical industries...which is why I prefer working for very large organisations/ISPs and tend to avoid pure consulting firms. IT people "are" janitors/cogs. If I see some red flags already in the interview process (and believe me, that if you are looking for them, you will see them), it is a deal breaker. Dec 20, 2020 at 13:28
  • What does TL and SMB stands for? Dec 21, 2020 at 2:34
  • @raffaem TL = Team Lead but why not ask the person that used them? Seems more sensible....
    – Solar Mike
    Dec 21, 2020 at 5:03

Whenever you have a question like this: Examine The Incentives!

Let's take the easy example you laid out: a bunch of engineers in a room with upper execs, and none of them speak out to indicate there's a severe problem in project direction.

Instead of asking, "How do I get them to speak out?", ask yourself, "What incentives are in place preventing them from speaking out?"

I can guarantee you, each of those engineers went through a mental checklist - weighing the pros/cons of pointing out the issue. The problem your organization has is... each of those engineers thought the 'cons' outweighed the 'pros'.

I would take a very careful look at some of the possibilities:

  • Questioning leadership will get you chewed out and/or is dangerous to your career
  • Being negative/cynical/realist is seen as being a bad team member
  • Pointing out issues that help the company isn't recognized/rewarded

I'd suggest doing this for all the related issues you're bringing up, such as why the engineers don't accept internal advancement. Instead of trying to figure out how to 'convince' them, figure out what's convinced them not to.

  • Good answer. One of my pet peeves is when leaders say things like "I don't want to hear about problems, I want solutions!" This kind of attituded is just plain bad leadership. To illustrate, image a captain at sea saying something like this: "Sir, there's an iceberg ahead" -> "Don't come to me with problems, come to me with solutions!" I've seen this so many times. As a leader: if your engineers won't tell you there's an issue until it's too late, the problem is likely with you, not them.
    – JimmyJames
    Dec 31, 2020 at 19:31

First, are you hiring engineers who want to eventually be leaders?

As a People and Culture person, you should be digging into the kinds of interview questions being asked of engineer candidates and the profile of the engineers you eventually hire. If you expect to have a pipeline of future leaders, that starts with hiring the right kinds of people.

Second, what kind of leadership training does your company offer?

It's difficult to expect an individual contributor to magically turn into a leader without some training. Perhaps the People and Culture team should offer leadership training for aspiring or potentially aspiring leaders, to be conducted during company time.

Third, does your company offer a leadership/management career track?

Many engineers view themselves as on a technical career track. They may be very reluctant to leave that track, even temporarily, if they don't see a clear path for long-term career advancement. Some companies offer dual technical/leadership tracks - both having clear advancement steps and equivalent pay advancement steps. And some companies offer the chance to change from one track to another and (importantly) back, if it doesn't work out. As a People and Culture person, you should find a way to make it safe for people to try out new roles.

Finally, and probably most importantly, have you asked the engineers who declined, why?

It's hard to fix a problem if you don't understand the cause. As a People and Culture person, you should always want to get to the bottom of all people issues. If 80% of the engineers decline your offer, it would make sense to find out why. Ask them!


If they don't want the lead position is easy to see why. They lack confidence in themselves and the team as a whole, so don't want the responsibility.

You need to hire experienced professionals or pull in some experienced consultants to put some backbone into things.

Leads that weren't on top of projects and didn't recognise that engineers were not supporting properly are sub par, It's not the fault of the engineers so much, they're just taking the easiest course without responsibility.


Several folks have mentioned that the passivity you are seeing in your engineer's could be due to cultural expectations, and as someone who was born in a non western country, want to expand upon.

Where I was from, cultural traits such as obedience to authority and a collective mindset were the norm. These expectations translated into obedience and deference to senior management such as the executives you mention. The engineers may well be aware of a problem, but dont see it as an issue they need to point out as to do so would be subrogating the authority of superiors. To be clear, I am not saying such mindset is appropriate, and I actually think it could hurt the company in a lot of cases.

I have been working in the USA, and the workplace culture is much different. Traits such as individualism, employee empowerment, and individual creativity us much more valued, with managers often soliciting ideas from their team members, something I see as beneficial and refreshing.

Assuming your engineers are from a different culture, I would suggest you make it clear that an open environment is to be encouraged, perhaps even expected. If engineers have concerns they should be encouraged to speak up and contribute to discussion. Make it clear that groupthink and blind obedience solely due to being an authority figure are to be discouraged. As a people and culture leader, set the vision for the company that enables creativity and open sharing of concerns and ideas.


There are a few reasons why this might be happening, some you can fix, others you can't, some are company-specific, some are not. Here is a non-exhaustive list of things to think about:

  1. Many engineers are technical people, not social people. They are good at what they do, and what they do is building things. In the same way as a plumber might not be the best architect, even though plumbing is a small part of house-building, an engineer might not be the best engineering team lead, even though understanding technology is a small part of being an engineering team lead. The skill sets required are very different, in particular project planning, requirements gathering, devspec writing (sometimes), managing interpersonal issues amongst the team and with other teams, blocking your engineers from silly and weird asks from other departments who have no idea what's going on, and so on. Personally, in a previous job, I was "promoted" to a tech lead position, and I failed horribly at it, because I'm good at engineering but I'm really bad at these other things.

  2. Many engineers don't want responsibility. They like sitting at their desks, working on their own tickets, getting their job done, and that's enough for them. They don't want the headache of additional responsibilities.

  3. They don't see the benefit in becoming a team lead. How are you selling it? Is it a promotion? Does it come with more money? More interesting work? More vacation days? More opportunities to travel (modulo covid)? Why should they accept the offer?

Another thing to look at is why do your engineers not care about the tasks they're doing:

  1. They feel like their input is ignored by management: "Management doesn't even listen when I talk so why should I care?"

  2. They feel like the company is going in the wrong direction as a whole, and fixing one small piece isn't going to help: "This whole company is so backwards, what is one small change going to matter?"

  3. They feel like they are overworked and lack enthusiasm: "I've been working a 60-hour week for 40 hours pay, why should I do more for this company than I absolutely have to?"

There are others, but mostly they revolve around a feeling of being mistreated by the company. You should look into why that is happening, although if it's too ingrained you may get the "management doesn't actually care so why should I waste my time even explaining the problem" answer.


There are a few things that I have learned in this area that I think are generally true:

Engineers do not want to spend time on bureaucracy: approving time sheets and expenses, reviews, management meetings about planning social events, etc. All of these are torture for the engineer. Not only are these hours empty of joy, they erode the engineer's skill and status as a technician.

For someone who is technically-inclined and not socially-inclined, navigating a political landscape can be tricky and unpleasant. In addition, politics tends to have a corrupting effect on technical solutions. Technical usually people prefer to distance their solutions from politics.

Being responsible for people is also often unwanted. John is MIA for the last week, Bill came into work drunk, Fred keeps clipping his toenails at his desk, the new guy's lunch smells terrible, and Mary isn't at work because she's involved with a bird rescue. Why would a competent technical person want to deal with this kind of nonsense when they can as much money (if not more) doing something they actually like doing?

This is not an easy problem to solve. Unless you can find someone with technical chops and leadership skills, it can be difficult to give someone authority without any accountability for the team. Some things that don't work:

  • Let the most aggressive technical person assert control: this is common but generally not good. This is often results in a toxic team environment.
  • Let a non-technical leader pick a technical lead: they will often pick the biggest suck-up or the person with unsophisticated ideas that non-technical people (at least think) they understand.
  • Force someone to take a leadership role they don't want: they will likely leave.

One thing that I have seen work is to bring in a good manager with real technical experience and give them this problem to solve. It's very unlikely that non-technical manager can work out a good long-term structure for a technical team. This is a hard to find and you will need to pay them well: more than you pay their non-technical peers. That alone is often difficult for companies to accept and prevents this from happening.

You must log in to answer this question.

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