Being a Development Team Leader?

I’d like to become a Development Team Leader

Hopefully most will have actually considered the change of role and be looking for new challenges and ways to contribute more to their chosen profession. However, for some this is an automatic response to a question that is particularly difficult to answer in an industry with no clear career path. For others it’s simply a way to move up the pay scale.

Before you start talking to your manager or applying for your next job it’s worth considering what you’re getting yourself into. Depending on where you work there will be different definitions of a Development Team Leader (DTL). To put this post in perspective this is my interpretation,

A Development Team Leader is someone who owns the technical delivery of a solution. They need to understand the business drivers behind the project and be able to lead a team of Developers to realise these drivers in working software.They are (IMHO) the central player in a project team and need to maintain excellent communication with all members of the team from Client to Developers and everyone in between.

I tend to distinguish between what I call a Senior Developer (SD) and a DTL. A SD is someone who still does the tasks of a developer but does them really well and has lots of experience. They don’t tend to have the added responsibilities of a DTL. DTL’s often (but not necessarily) have a SD background.

Assuming you’re a developer this is what I reckon your job entails.

Let’s face it the life of your average developer is focused around cutting code. Sure you might have daily Scrums or other team meetings to attend but your main focus is writing software. And you love it!

When you become a DTL you work balance is up for a bit of a change.

Other than the coding slice don’t place to much attention on the relative weights of the pie slices – suffice to say you won’t be zoning out for 8 hours a day to your favourite tunes – you’re the one that gets interrupted, you’re the one putting out the fires and making sure the wheels are oiled. Your head is on the line if the solution doesn’t meet expectations or is delivered late. You have some responsibilities and influence now.

Coding – don’t worry, you still get to practice your craft but just not as much as you used to. There are now lots of other things that you need to be involved in too.
Documentation – even with the increasing popularity of Agile methodologies and a move away from excessive documentation there are still times when (technical) documentation is necessary – and guess what? You will be first in line to do it.
Meetings – if you thought you were in lots of meetings as a developer then you ain’t seen nothing yet. Depending on the size of the project you are involved in you will be the main participant in a wide variety of meetings. Whether it’s a meeting with the client, the delivery team, the PM, you are the one with the most knowledge of both the requirements and the implementation of the solution.
Communications – beyond official meetings you will also be heavily involved with communicating to others via emails, issue tracking software, the phone and face to face catch ups on progress. It’s a bit of a cliche but good communication skills really are the key to succeeding in many professions – and for any leadership role it’s essential.
Delegation – because of your other duties it’s an essential part of your role to be able to delegate work to others. Someone once told me that the job of the DTL is to make themselves redundant – an apparent contradiction to your pivotal role on the project but one that sums up the responsibility you have to ensure the project moves forward even when you can’t personally be there to solve an issue. The more you delegate responsibility to others in your team the more involved and productive they become. Don’t try and do everything yourself.
Mentoring – part of reason for delegating tasks to others is to provide them with opportunities for personal growth and development. Mentoring carries this idea further and is a key part of your role. No-one is an island and you must be prepared to share your knowledge with others. As an aside you should also be prepared to learn from your team – DTL’s who think they know it all are usually wrong and always disruptive to the morale and effectiveness of the team.

How to Become a Development Team Leader?

As Development Manager to a team of incredibly motivated and talented individuals I often have conversations that begin,

    Hey Tokes, I really want to move my career to the next step and want to know what I can do to become a Development Team Leader.

My response,

    Act like one!

That’s right, it’s that simple. Wherever possible take it upon yourself to assume some of the tasks that would normally be expected of a DTL. The more DTL skills you display the more likely others will see you in that light and give you the opportunity to perform the role for real. Whatever you do, don’t sit quietly behind your desk with the headphones on and expect someone to recognise your leadership potential and tap you on the shoulder – it won’t happen. Similarly don’t assume that because you’re a technical genius that becoming a DTL is the natural next step in your career or something you deserve in recognition of your talents. The skills of a DTL go beyond the technical and require you to have other skills like great communication, the ability to delegate, confidence, being level headed, acting in a professionalism manner…

So what can you do I hear you ask? You’re only a developer, right? Wrong, the act of developing is only part of what you have to offer.

Let it Be Known – it seems obvious but you should let your manager/PM/peers or anyone else who will listen that you want to become a DTL. Don’t be a nag about it but just plant the seed in people’s minds.

Understand the Big Picture – one of the big differences between a good developer and a great one is their ability (or interest) to understand the big picture. They understand the business goals and pain points the system is addressing. They understand the entire solution, not just their part of it. They understand how the code they are writing benefits the client and the solution as a whole. They understand the client and what is important to them. They understand that the code is a means to an end and that project success will be primarily measured by client satisfaction.

Ask Questions – I love working with people who ask questions. It shows you are attempting to understand things thoroughly. It shows you’re not afraid to question why something is being done in a certain way. It show’s, that as a DTL, I’m not the only one thinking things through and that there’s more chance the team is on the right track. Understanding the Big Picture is crucial to being able to ask the right questions.

Don’t Wait to Be Asked – while you should always be on top of the tasks delegated to you, don’t stop there. Be hungry like a wolf, hunting out ways in which you can add value, help others and identify issues. Do not wait for your own DTL to ask you to do something, try and always be one step ahead without, of course, second guessing their authority.

Be Approachable – DTL’s are often the go-to guys (or gals) but they’re also pulled away from the team to attend meetings etc. Be approachable (i.e. take off the headphones now and then!) and aim to be the one people seek out when the DTL’s away – this is a great sign that you have the respect of the team. If you’re doing the things above this will be a natural consequence and shouldn’t require you to do anything specific.

Stay Calm – what was it that Mr Kipling said? "If you can keep your head when all about you Are losing theirs… you’ll be a DTL my son!". Software development can be a stressful business. Look around at DTL’s you respect – guaranteed they will be the level headed ones, the ones that don’t let the pressure get the better of them (or at least are good at hiding it!)

1 I like it
0 I don't like it