How to get hired as a team lead

I see people make three huge mistakes when trying to transition from a developer position to a leadership position.

1 – being a “good” developer with lots of experience makes you qualified to run a project or a team. It’s just not true. Being a “good” developer with lots of experience is necessary, but not sufficient, to successfully make this transition.

2 – the idea that you actually know what a well-run, effective project actually looks like. Most people have never even seen a well-run, effective project. They have little idea of the results regularly achieved by the best teams.

3 – not adjusting your interview answers to reflect the kind of thinking and strategizing effective leader engage in to be successful.

In this post I’ll show you things from the employer’s perspective and help you get on the right track to get hired as a team lead.

Note: I work in a small business environment where team leads operate with high levels of autonomy and responsibility. There is no architect, security group, CTO, CIO, QA group, DB admins, etc. The team lead wears all those hats and more in a small business. That’s the context of the advice that follows.

Why technical skills aren’t enough

The skills required to be a good individual contributor look something like this:

The ratios will change depending on what kind of work you are doing and how senior you are but I think most people would agree that this breakdown of skills more or less conforms to their expectations (technical skills dominate).

But the skills required to effectively run a team/project look more like this:

Again, you could quibble about the ratios, but I think most people who have actually run effective projects would more or less agree with this breakdown of skills (a broad range of several skills).

I also want to point out that the pie graph for the manager/leader role is much larger than pie chart for the individual contributor because you need to know so much more to be successful in a leadership role.

So what does this mean?

You need several new, large, difficult to master skills sets that are only semi-unrelated to the focus in the first phase of your career as an individual contributor.

You can’t just wing it and expect that everything will all work out, because leading a successful project is hard and counter-intuitive. And the odds of a successful outcome are very much against you.

If you can work your way into that position with a mentor in your current organization, you can probably acquire at least some of these skills as you rise through the ranks of your organization. If not, you have lots of reading and thinking ahead of you. And even then, you need to find an employer willing to take a chance on an unproven leader. That will put you ahead of the people who make “mistake 1” but behind the people who had a mentor and leadership experience.

Why you’ve probably never seen a well-run, effective project:

Steve McConnell has a great talk that covers this: The Business Case for Better Software Practices.

(I wrote a whole post about it if you want a quick summary).

Here’s a screenshot from that talk:

Most people intuitively think that the range of effectiveness of teams is basically normally distributed with an average about half-way between ineffective and extremely effective projects (red plot). So if you’ve worked for 5 or 10 software shops, you might reach the conclusion that you more or less have seen what an effective team looks like and what an ineffective team looks like. And if you think you can achieve similar results to the best team you’ve seen, you’ll assess yourself as quite effective.

But the actual distribution of effectiveness across our industry is massively skewed to the left toward ineffective practices (blue plot). So, if you’ve worked for 5 or 10 software shops, you might realize that it’s extremely unlikely you’ve seen a well-run, effective project because those teams are operating in the last couple of percent of the distribution on the far right side of the plot.

In fact, since the average of the real distributions is skewed so far to the left (blue plot), you’ve most likely only seen pretty ineffective teams.

Now, there’s nothing magical about being on the far right side of the plot. Just about any team that makes getting on the right side of that plot their goal can at least move in that direction. The real problem is that most people can’t imagine that those results are even possible.

But you don’t have to take my word for it. Check out the next section to see how effective you really are.

How to calibrate your effectiveness experience:

Does your experience look like the typical project (orange) or the healthy project (yellow)?

How much rework do your projects create?

More questions:

• do your projects progress smoothly from start to finish or is there a massive crunch at the end?
• do your projects finish on time, on budget, with the agreed upon functionality and quality levels?
• would an observer characterize your process as orderly and/or boring or is it chaotic and punctuated by drama and fire fighting?
• is the code base getting easier to maintain or harder?
• is your team getting faster at delivering features over time in the same project or getting slower?
• are your people growing and supporting each other or are they grumpy, stressed, and territorial?

Scale is another factor. How difficult were the projects you’ve succeeded at? Bigger projects with bigger teams, longer durations, higher quality requirements, tight schedules, etc. require exponentially more skill to lead than simple, small, projects with lax deadlines.

What employers are looking for in a team lead

Employers want someone with

a proven track record of repeatedly leading a team to successful project outcomes from idea to a high quality, maintainable solution running in production.

They’d prefer to hire someone who has a history of that kind of performance in a number of contexts, teams, and code bases and project sizes because past performance is the best predictor of future performance.

In short, they want someone who can consistently deliver the results on the right side of the effectiveness graph.

So, if your resume looks like that and you can communicate your past achievements effectively in interviews, the offers are going to pour in because people like you tend to be rare.

Because employers don’t come across people like that very often, they have to relax their requirements somewhat, or they’ll never fill those leadership positions. That makes employers nervous.

In fact, finding qualified leaders is so challenging that many employers would rather leave positions unfilled than take a chance on someone with questionable qualifications.

Why are employers reluctant to take a chance on people for leadership positions?

I see four main reasons:

1 – It’s difficult to determine if someone really knows what they are doing in an interview. They can say all the right things and not be able to deliver. Or it can go the other way where the person is a weak interviewer but would actually make an excellent hire.

Hiring managers know hiring in software development is badly broken and that the best companies maybe get it right half the time. But the risk is asymmetrical. Passing on a good candidate carries much less risk than hiring a bad candidate and having them make a mess in your company. So employers are biased to pass on people who they aren’t sure about, especially for leadership positions.

2 – Being an effective leader is way harder than being an effective individual contributor. You need so many more skill sets and you have to be sufficiently skillful in all of them to consistently deliver successful outcomes.

3 – The consequences of failure are so much greater for leaders than individual contributors so there’s even more incentive for employers to pass on people they aren’t sure about for leadership positions as compared to regular developer positions.

Employers can identify a weak individual contributor and corrective action can be taken. That will likely take the form of additional training, coaching, and supervision. That person may also be assigned tasks where their weaknesses will not place the project at risk. And if that person still cannot make a positive contribution, they can be removed from the project as a last resort. But a weak leader can and likely will endanger the whole project.

4 – Once a project is in trouble it’s really difficult to kill it or replace a weak leader and save it. First, there is already a shortage of strong leaders so it’s unlikely you have a strong leader just sitting around who could take over.

But it’s also really difficult for an employer to say that “it’s not working out”, fire the weak leader, and cancel the project after hundreds of thousands of dollars have been spent without trying to save it. Everyone has a boss and the person who makes that bold call–even if it’s the right call–is going to end up with a blemish on their record.

Let’s look at how this typically plays out and why it’s such a problem for employers.

A nightmare scenario for employers

Suppose Acme Inc. has a software project they want to do, but they don’t have a team lead to run it. So they advertise the position and can’t find someone with a proven track record of repeatedly leading a team to successful project outcomes from idea to a high quality, maintainable solution running in production. After a few months, they decide to take a chance on Jerry who was a great individual contributor in his past position, but he has limited leadership experience.

So Jerry joins Acme Inc. and gets assigned a team and a problem to solve. Jerry and his team scope the project, gather the requirements, create a design, decompose the design into tasks, and make an estimate. Jerry thinks he and four other developers will complete the project in one year and it will cost $500K (5 people who cost $100K on average per year). (BTW: nice round estimates like “one year” should always be a red flag that someone isn’t doing proper estimation.)

Anyway, back to the story. This a serious amount of money for Acme Inc. but the expected value of the project far outweighs the projected cost so the project is approved and the team starts the project.

Half a year into the project, management wakes up to the fact that Jerry is struggling after several deadlines were missed and several complaints from his team.

Management starts coaching and pressuring Jerry to get the project back and track. But Jerry’s already trying his best. He tries this and that but the project is getting further behind because he doesn’t really understand why this isn’t working. He’s a great coder, and he’s worked on projects more complicated than this one, but he’s too busy to really do much coding and his people can’t seem to get it together. So he’s spends most of his time in meetings, putting out fires, and trying to get his increasingly frustrated team members to get stuff done.

After month nine, he calls a meeting with his employer, claims unforeseeable circumstances are making the project late and harder than anticipated (not taking responsibility is another red flag), and begs for another four months, which he receives. So now the project deadline is 16 months and the cost estimate increased by 33%.

But–and I’m sure you know where this is going–after month 12 it’s clear that they won’t finish in 16 months. So Jerry goes to his employers and begs for permission to cut features. The employer reasons that some solution is better than no solution and nobody wants to throw out $500K of work. They don’t really have any better option, so they agree to cut features and pray that Jerry can deliver (hope is not a plan).

After month 15 they finally get to testing and the system is buggy as hell. Testing was originally scheduled to take two months but that number was based on the assumption that they wouldn’t find any serious problems in testing. Bad assumption!

So the project gets extended to 19 months. But the bugs just keep coming. A single planned round of full testing turns into several rounds of full testing and month 19 comes and goes and the project still isn’t finished.

If you’ve been around long enough, you’ve seen a least one project that looks something like this. In fact, this scenario is surprisingly common for typical projects up to this point (late, buggy, reduced scope, dissatisfied customers, discord among the team, etc.).

There are several possible ways this ends. The project could drag on for months and never get out of testing. Or they just stop testing and release it, bugs and all. Or the project could be cancelled. Or the team is so burned out after this death march under a weak leader that half the team quits after the project. Or the released software doesn’t meet the customer’s needs and nobody wants to use it and/or the customer doesn’t want to pay for it. Or the code was so rushed and so disorganized that it’s going to cost a fortune to maintain it.

The most likely scenario is probably a lot of all the above. And, let me tell you, that really scares the pants off of employers because most of them all been burned by a project like this or know somebody who has.

So, how do employers respond after having lived through something like this? They vow never to hire an unqualified leader again. They reason that the risk is just too great. So those positions go unfilled until they can’t tolerate the lack of progress.

Eventually, however, the pain of the previous failed project under a weak leader fades or a new manager joins the team, or the boss’s boss just directs the boss to hire someone and the cycle repeats.

Does the team lead’s skill really matter than much?

YES! 100%! Let me tell you a story of a three person team with a weak leader.

This developer, with over 20 years of experience, got internally promoted to team lead. He eventually ended up with two junior developers basically straight out of school working for him. And they didn’t ship anything substantial for almost two years.

Nothing this team lead’s boss tried seemed to make any difference. They just couldn’t finish their project. But it was worse than that. As the pressure mounted on the team lead to deliver, the team lead took the team dark. They stopped reporting their status and their boss lost almost all visibility on the project. He had no idea when or even if the team would ever finish their project.

Out of desperation, they brought in another experienced team lead consult on the project and help get it back on track. We’ll call that second lead the “coach.”

The coach quickly realized what was going on. The team lead was completely lost. There was:

• no plan
• no schedule
• no list of tasks
• no project management fundamentals
• no technical fundamentals
• no quality assurance program
• no risk management program
• no coherent testing plan
• no development program for the junior developers
• etc.

And there were piles of work in progress. They started something over here and then started something over there, and then they’d start something somewhere else, but they’d rarely finish anything.

The team lead was likely running on fear and adrenaline, which is not conducive to higher cognitive function. The boss asked the coach to coach all three members of the team.

The juniors were receptive and took the coach’s advice and started improving immediately. But the team lead, despite declaring repeatedly he wanted coaching, didn’t do the homework, didn’t prepare for meetings, and he followed about 3% of the advice the coach offered.

Now, to be fair, the team lead was trying his best. But, by this point, he likely feared for his job and was so stressed by the demands of running this troubled project that there was no realistic possibility he would have been able to recover.

After months of coaching the team lead without getting anywhere, the coach tried to have him removed from the project. The boss was reluctant at first, but he eventually agreed with the coach. He removed the team lead and put the coach in charge of the team.

The coach immediately stopped all work on the struggling project and shifted the team to another project with no baggage and a hard end date that was coming fast.

He applied all his leadership skills and knowledge to this new project and the two junior developers cranked out a major feature on time, on budget, and with the agreed upon features. And that project had zero customer reported defects (it did have one super minor defect caught by the coach after release and was fixed in minutes).

That team then took on an even bigger and more complicated project. This second project had a fixed scope and externally imposed fixed end date 8 months in the future. And the team succeeded again. They delivered that project on time, on budget, with zero customer reported defects despite several interruptions.

So, just think about that for a minute. You have the same company, the same boss, the same developers, the same code base, the same tools, and the only real difference is the team lead. The first team lead couldn’t ship despite his best efforts. And the new team lead shipped two fantastically successful projects back-to-back.

What’s the lesson here? Leadership matters a lot.

Another problem for employers: these two team leads have very similar resumes

Both these team leads have resumes that look strikingly similar. They both have decades of development experience in similar technologies, and they both can say they’ve been team leads.

The weak team lead is hard to spot in an interview because he actually knows much of the theory. He can talk about quality assure plans, risk management, scrum, etc. in an interview and you’d be left with the impression that he knows what he’s doing.

But, I think you’d agree, you’d want to hire the second team lead and avoid the first.

This is yet another of the many challenges employers face in hiring for leadership positions.

How to prepare for a leadership role

Theory and experience gained under the supervision of a good mentor is best. Some people can get that at their current job. Remember, employers are desperate for people who can lead so there’s a good chance that if you are interested in going that route, that you can arrange on-the-job training.

However, the caveat is that you might have to do a lot of the learning on your own time at least in the beginning to prove to your employer that you are committed to becoming a leader and are taking the first steps on your own.

But, if you have no path to leadership in your current position, I strongly recommend at least immersing yourself in the techniques and methods used by the most effective software development organizations in our industry.

Take the theory and see how it would play out in your current position. What are your current leaders doing right and what are they doing wrong? Could a challenging area for your project be improved with one of the techniques you learned? Does your team have enough psychological safety for you to bring it up without someone getting defensive? Could you get some informal mentoring by picking your leader’s brain on coffee breaks?

See the resources section at the bottom of this post for suggested learning resources.

How to present yourself in the interview

If you are accustomed to interviewing for individual contributor positions, you are likely used to attempting to convey your technical competence in interviews.

For individual contributors I’m mostly looking for code-level, tactical skills in interviews, with some emphasis on interpersonal skill and past projects. Can you talk about this design pattern? Can you solve this toy problem? Do you know these language features? Can you write unit tests? Are you someone we can see ourselves working with?

But you need a different mindset for an interview for a leadership position. The exact image you are trying to project will vary from company to company and if you can figure that out before the interview and customize your approach, so much the better.

But if you are going into the interview blind, I recommend you focus on trying to convey that you know what a well-run project looks like and you hopefully have a bunch of stories and examples prepared to show that you have a history of leading well-run, effective, successful projects.

For leadership positions, I’m looking for all the skills in that pie chart above but I’m especially interested in project/business-level, strategic thinking in interviews. You’d do well to weave this way of thinking into both your questions and answers.

Some examples of things you might try to fit into the conversation:

• stats from your previous successful projects (hopefully on time, on budget, with agreed upon features and low defect rates)
• your QA program and how it was tailored this way to the specific needs of project x but adjusted in this other way because of the special requirements of project y
• how you tailored the project to meet the many needs and wants of your stakeholders
• how you dealt with problems with customers, missed deadlines, changing requirements, etc.
• specific countermeasures you employed to keep project x on track when the requirements or deadline changed
• how you developed your team members’ skills
• how you managed team dynamics when interpersonal issues presented themselves
• how you handled a mental health or performance issue with one of your team members
• how you tracked and reported progress on project y and determined months in advance that you needed to cut scope to finish the project on time, which was the most important factor for your employer on that project
• and so on…

An example of the two approaches to the same question

Question for an individual contributor: Tell me about the unit testing program on your last project.

Answer:

I’m good at writing unit tests. We wrote quite a few unit tests for this business domain logic in that project and my unit tests were the cleaner and I wrote more unit test than anybody else on my team. I use TDD sometimes too.

Notice the vague, qualitative answer. This doesn’t really tell the interviewer much of anything. And when I run into an answer like this, and then we do a little coding in the interview and I ask how the candidate would unit test what they just wrote, I often get a blank stare or a fumbling attempt to write some test cases. So that’s not a great answer for any kind of job interview but it’s a particularly poor answer for a leadership position.

Question for a potential leader: Tell me about the unit testing program on your last project.

Answer:

Our customer really wanted the shortest schedule for that project. So I set our QA goal as finding and removing 95% of defects from our software before we released it because the research says that leads to the shortest development schedule.

Because we were extending a legacy project and some members of my team was just learning unit testing, we needed to take a pragmatic, layered approach to quality assurance to meet our goal (no single QA technique removes 95% of all defects from a project).

We know from industry research that unit tests don’t actually catch that many defects in code when they are written by people with limited unit testing experience. Plus, unit tests catch 0% of requirements and design defects. We also know from the research that code reviews often offer a better bang for the buck than unit tests and my team did have a reasonable amount of experience with them.

So our plan was as follows: we used a code style tool to ensure all code was formatted automatically and used static analysis and code inspections in our IDEs, so we didn’t have to waste developer time dealing with those concerns. Then we systematically tried to remove as many defects as possible from the project at every stage before moving on. We made cheap mock ups of all the screens and reports and got feedback from the customers before we coded anything to flush out issues in the design phase when it was the cheapest to deal with them.

We also did informal design reviews, strict code reviews for all code, and unit testing where that was within my team’s skill set. We augmented that with automated integration/acceptance tests and/or manual testing where it was too difficult or costly for my people to get automated tests around a particular piece of code. I know that’s not ideal but that was the best we could do with the people we had and the time we had available.

We conducted retrospectives at the end of each sprint and adjusted our approach as we learned more about the project and each other.

Each feature was released as it was completed, and we immediately solicited feedback and adjustments from the customer. However, because we had already developed the features from approved mock ups, post-release feature change effort made up a very small percentage of the overall project effort. I also took on some exploratory testing at the end of the project because nobody on the team had much experience with that.

The results were great. Final system testing went smoothly. We only found a couple of minor issues, which we fixed in a couple of days. We didn’t formally track the defects we removed pre-release because we didn’t have time to set that system up during the project, so we don’t know if we actually achieved 95% pre-release defect removal. But we did track post-release defects and there were two minor defects discovered in the six months after the project was put into production and both of those defects where repaired in under two hours each.

The customer was thrilled with the outcome because we finished on time but also because they were expecting multiple follow-up bug-fix and enhancement releases based on their previous experience with other software teams. But we didn’t need any of that because of the mock-ups we made, the feedback we solicited as we released each feature, and the high quality of the design and implementation.

There are always more features you could add to any system but the customer was very satisfied with the software we delivered, and we completely avoided the dreaded “that’s not what we meant” conversation so many customers have with their developers after the software is released.

Do you see the difference there? Do you see how much more information that gives your potential employer about your thought processes, skills, and competencies? Do you see how I discussed the trade offs I made with the tight schedule and adjustments I made for a team with suboptimal unit testing experience? Do you see how I tied in customer requirements and then customer satisfaction? Do you see how I based our QA plan on industry statistics?

I know the second answer went way out of scope for the question but I guarantee no interviewer is going to cut you off if you are giving that kind of answer. That’s the kind of information I’m trying to get out of my interviewees and I rarely get an answer like that even once during an interview. But I do get a lot of answers like the first response.

I recommend trying to give as many of the second type of answers as you can as opposed to the first.

The questions you ask the interviewer might be almost as important as the answers you give

Most candidates miss a major opportunity to sell themselves to the interviewer with the questions they ask.

Typical questions:

• do you use Jira?
• when do you hold your meetings?
• how long are your sprints?

Pretty much every interviewee asks me some version of these questions. Not very deep thinking there, don’t you agree?

Excellent questions:

• what are the biggest challenges you face in the next twelve months as a company and how is the programming department going to help solve them?
• if I get the position what would my first project be? What kind of challenges does that project face?
• what are the strengths and weaknesses of the team I’ll be leading? What kind of experience do they have?
• what’s the overall strategy for developing your programming department?
• if you could snap your fingers and change one thing, what would it be?

And now, you can evaluate the interviewer’s answers, which I strongly encourage because a bad employer will make your life very unpleasant:

• do they know how to run successful software teams?
• are programmers valuable resources to be nurtured, protected, and developed or are they interchangeable code monkeys?
• do their programmers like working there?
• does their approach to software development match yours?
• do you think you’ll be happy working there?

One more tip

Please, please don’t suggest “great ideas” for how you will come in and accomplish a massive goal in record time without knowing anything about our business, processes, challenges, or code bases. It really rubs me the wrong way.

Let me give you an example. One candidate asserted that he could convert our website to his favorite content management system in [insert laughably unrealistic estimate here].

Here’s what I heard:

I’m not going to ask questions and gather requirements or do any planning before I offer a recommendation.

I’m going to push my agenda on the organization and promote the use of my favorite technologies without regard for their fit with the code base, the team, or the long term direction of the project (possibly because that’s the only technology I know).

I offer estimates without any reason to think they are accurate and I’m okay with that.

So where does that leave us? I see two options:

• you think you’re hot stuff but you’re actually unprofessional and you don’t know what you’re doing
• you actually know what you’re doing and know your recommendation is unachievable but you’re trying to manipulate me to get the position

Savvy interviewers are probably going to see those “great ideas” like I do so please don’t do that.

Resources

Here are some resources to get you into the right frame of mind to lead a team to successful project outcomes.

(As an Amazon Associate I earn from qualifying purchases.)

• highly recommended – See what well-run software projects look like: The Business Case for Better Software Practices (YouTube video)
• highly recommended – Learn how to actually lead a well-run, successful software project: Construx On Demand courses. The advanced courses will be of particular interest to future leaders (subscription video courses: $1 for the first month, $29/month thereafter)
• Rapid Development (paid link)(book) It’s old but excellent! There are thousands of ways for a project to get into trouble. If you follow the recommendations in this book, that will be much less likely.
• There’s a stubbornly persistent myth in software engineering that high quality (in the form of low defect rates) is expensive and it’s totally wrong. High quality isn’t just cheap, it’s cheaper than creating low quality code and then trying to test the errors or if it (blog post) or you can read a whole book about it: The Economics of Software Quality (paid link)(book)
• I always say that “perfect code that solves our 50th most important problem is worthless” as a way of emphasizing the importance of prioritization, which I think is another critical skill for running successful projects. You can get an introduction to the best way to do prioritization that I have found here. At least watch the 3-minute intro video. From there you can find whole books on the topic. I’ve also written programming specific examples here, here, and here
• 50-60% of the effort on the average software project goes towards unplanned rework. That’s a lot of waste and if you could get that down to something more reasonable like 20%, you’d save piles of time, effort, and money. Implementing Lean Software Development (paid link)(book) will give you lots of ideas to help you find and eliminate that waste. Once you see all the waste in your projects, you won’t be able to unsee it

Wrapping up

Getting hired as a team lead requires a different skill set and interview approach compared to getting hired as an individual contributor.

I showed you that most people have never seen a well-run, effective software project, much less led one. But that doesn’t mean it’s impossible to learn what that looks like, get experience at least moving in that direction, and adjust your interview approach to show you know what you are talking about.

I gave you insight into what employers worry about, what they are thinking, and what they are looking for in an interview for a leadership position. I also explained why it’s so hard to hire someone who is marginally qualified. And I showed you some examples of better and worse approaches to interviewing.

I hope you found this post useful and that you can put all this knowledge together to get hired as a team lead, if that’s your goal.

Cheers.

P.S. If you’ve led projects on the far right of the effectiveness chart, know PHP, and are looking for a full time, permanent, leadership opportunity, please reach out to me through my contact form. My employer is always looking for talented leaders and I want to talk about hiring you for a fully remote position.