Should you apply for a team lead role if you're not 'technical'?
Tags: career, leadership, management
Published: 2020-01-13 10:23:28

---
title: Should you apply for a team lead role if you're not 'technical'?
published: true
date: 13/01/2020
tags: #career #leadership #management
canonical_url: https://darraghoriordan.com/2020/01/13/non-technical-team-lead/
---

I was asked for some advice recently - "Should I apply for this open team lead role if I am not technical?"

In this case I found out that "technical" meant "is a software engineer".

If you're employed in a software product development organisation already then the short answer is yes, you absolutely should.

If you're coming from outside tech you might have a more difficult time because tech is a little bit weird but still consider it if you have leadership experience.

> A team lead must be able to encourage people to work together collaboratively, so they arrive at the best solution for your business, given all the other constraints at the time.

You absolutely do not have to be an ex-software engineer to achieve this outcome.

Having the humility to ask the right questions like this one is a significant indicator you will be a great team lead. Just asking the right questions is an important part of the job.

The more detailed answer involves defining some of the terms and breaking down the things that might happen if you are not an ex or current software engineer.

## Defining the role

In some organisations a team lead is a people focused role and other times it is both a people and technical focused role.

You should talk to the hiring manager to understand what kind of role it is.

Here are some of the responsibilities for team leads and technical leads.

### People focused responsibilities

- Can manage time well, for yourself and others
- Must be positive and solution focused
- Genuinely care about your team's well being, including career (even after of your organisation)
- Ensuring team commits to agreed outcomes
- Identifying and mitigating risks
- Handling crises calmly
- Future work planning and capability planning
- Hiring and employer branding
- Promoting self organisation for the team
- Facilitating communication, ceremonies and meetings

### Technical focused responsibilities

- Defining and executing solution architecture
- Coaching and mentoring technical roles directly
- Designing and implementing software development practices
- Research and selection of technologies and tools
- Leadership through applying standards
- Usually a hands on coder

### Either one

- Estimating and delivering to schedule
- Facilitating customer training and support

The point is that organisations often need the person to be more focused on the people rather than the technical. The team is already full of senior engineers who love to focus on the technical.

You can usually identify and work with the other members of your team and organisation to cover the software architecture portion of the role.

I haven't worked in an org where senior engineers and team leads wouldn't be happy to help you out.

In fact most senior engineers I've worked with would probably prefer to work with a team lead who supported them in all the people stuff and left them to get on with designing and building cool stuff without interference.

## Are you 'technical'

You might not be a software engineer by trade but the fact that you're working for a software product development organisation means you're almost certainly already technical.

Don't sell yourself short.

Doing UX and design for a product is technical, testing the product is technical, marketing software in 2020 is super technical, all analysis is technical. We work in an industry where we all have to have a good understanding of how each role affects the product outcomes - we're all technical.

I'm reasonably technical but I emphasise to my team that while I'm happy to help with technical direction my focus is on the wellbeing of the team.

I care about the who and the why in our job. I'm happy to leave the how up to the team unless they ask (or I see a risk).

## Understand the risks and mitigate

Talk to the hiring manager and listen to any concerns they have. Don't try to resolve them there and then. Note them down and give yourself time to think them through and respond later.

Understand that almost no one will tick all the boxes on any given job description. The hiring manager will have priorities for all the requirements they need the candidate to meet and will compromise for a good candidate.

In a team lead role the people stuff is usually more important. Not always, but usually.

### Diversity of knowledge

If all the team leads in your org are ex-software engineers there is a diversity problem there.

Diversity in that first team of team leads is the same as diversity of knowledge in a product development team. The different perspectives are just as important all the way up the org as they are in a single team of individual contributors.

### Help with architecture and software specifics

You should have a chat to some of the other team members and team leads that you trust. They will support you with some software architecture help if you need it.

If you get the job and there are team members that are giving you a hard time for not being an ex-software engineer, just understand that it is almost certainly them and not you that have a problem. There are various ways you can try to resolve the conflict and you should read about that and work hard at it.

In general just make it clear that the technical stuff is up to the team to resolve together. You will do everything you can to help them work together to get the best outcome. That's the role as team lead.

### Estimating and risk in software

The hiring manager might be worried about your ability to accurately estimate and identify risk if you haven't written software before.

The thing is that you just have to facilitate and make sure that these things regularly happen. There are well known techniques for facilitating group estimation and encouraging communication in the team, including risks. Describe how you will learn and apply them to the hiring manager.

After working on a product for a while you quickly learn things like which areas are risky or how working on bad legacy code vs good legacy code vs greenfield can affect a schedule.

These things will be somewhat unique to your organisation anyway so an experienced software engineer/team lead from outside the organisation would be starting from a similar, or even worse, position to someone internally who didn't code but knew the system, business and customers very well.

## For devs

And if you're a developer that has a team lead without software engineering experience then don't be an ass to them. They are supporting you in ways you don't even see, support them when it comes to software engineering related knowledge! :)

Their job is to make the team more effective and create a better place to work, if they're doing that they're doing their job.

Enjoy your technical freedom!