To become a technical lead the following are essential

• The ability to mentor staff members at all level of seniority, from someone who has been out of uni for 3 months to a person who has been programming for 30 years

• A good knowledge of your development domain. This includes: languages, frameworks, utilities, development environments

• A solid understanding of issue management systems, project management skills and version control

• Be the go-to bug killer

• Know how to conduct timely code reviews, what to look for and how to minimise the amount of time they take to hold and for the changes to be made

• Keep up-to-date with the developments in your development domain. For example, if you didn’t learn new frameworks or technologies from .NET 2, you’d be doing things in quite a backwards way today.

• How to write unit tests and mocks, and to get your developers to write them too

• Knowledge of what design patterns are and when to use them

• Knowledge of what code smells are and how to mitigate them

• Continuous integration

• The ability to plan projects and releases

Depending on your organisation and whether you have architects on staff, you would probably need to know the following:

• The ability to componentize your projects and break it into functional parts

• A thorough understanding of security, including the correct way of handling passwords, separating systems, securing data, etc

• Enterprise concepts such as service buses, message queues, BizTalk

• Enterprise design patterns

• Service architectures / RPC such as SOAP and REST

• ORM frameworks such as Hibernate, Entity Framework, Doctrine

• Continual deployment

• The cloud

• The ability to recommend the correct technologies to use for a project. This might be difficult if your team / shop only does .NET, or PHP, or Java.

• Design the application in such a way as future enhancements will be easily accommodated

If you are going to be a development manager then you will also need:

• Interviewing skills and how to find the right staff
• How to deal with people problems with your team members
• Managing business directives/goals and converting relevant ones to information for your developers
• The ability to estimate the time for programmers of varying skills
• The ability to allocate tasks to the correct developers based on their skills and abilities

And finally, some other recommended points:

• Learn outside of your development domain

• Learn to say NO when things aren’t possible or are out of scope or conflict with restraints such as budget or time.

Managing a team is a challenging role to be in. You need to be the person that can answer any question, you need to know the right technologies to use (unless you have an architect), you have to have people management skills and be approachable by your staff (assuming a management position). In addition to this, you need to have accurate estimating skills to ensure project profitability and you need to be able to get your hands dirty with anyone’s code to pinpoint problems and fix them quickly. You need to avoid wanting to do everything yourself and to foster a team environment that is not toxic. You need to continually stay on top of your technology stack and learn the latest developments and techniques, as well as broader industry-wide trends.

You should also really know at least one database platform, and know it well. Know how to do replication, stored procedures, how the query optimiser works, and how to design a schema properly, and what fields to index.

Regardless of the exact position, any senior role requires you to have the ability to communicate effectively. If you’re not a confident speaker, look at doing something like Toast Masters (public speaking). Learn how to make and hold eye contact. Be confident. Dress appropriately for the position. Lead by example.

In my experience the Lead has a little bit less to do with the dirty work of hands-on programming and more to do with management. To that end I’d recommend the following

1. Invest more time in design and architectural pursuits and development. As a lead, your function is going to centre around providing technical guidance and direction to your team. You’ll be tasked more to understand how pieces of a whole fit together and less of how the plumbing works. Don’t get me wrong, your require solid technical chops to be an effective and knowledgeable lead, but a higher level view of what’s going on and how it’s going to work is going to be more crucial here. You should know more best practice design patterns and effective coding practices

2. Learn to multi-task and manage time. If you’re good at it now, that’s nice: develop more. As a developer, you have just your current task/project to worry about. As a lead, you’ll have

   • To attend more meetings than you care for. This is perhaps the most mind-numbing part of team leadership
   • Work on resource allocation. If you’re lucky, resources are going to be scarce and projects plentiful.
   • Take the lead on project architecture and design
   • Depending on the size and structure of the organization, provide a myriad of reports, on schedule and on-time. Think of the lead as a low-rent project manager.

3. Prepare yourself to delegate effectively. This IMO will be the most difficult bit to adjust to. As a developer, you’re used to getting your hands dirty, getting things done. Doing all the plumbing and research. That’s going to have to stop or be reduced. The gigs come in, you dish it out to the team. You’ll get a piece of the action, not just as much as you’re used to. And you’ll bite your tongue to resist the temptation to corner more action for yourself.

4. Along the more professional line, consider some training that will not only increase your ability, but change your outlook. A crash course in say software project management won’t hurt. Lean Six Sigma is also a very good training programme (I can testify to it’s efficacy) that will help you look at problem solving from a more logical angle. Not to mention that from the Lead position, you’re poised for even more senior roles that will require less hands-on technical skill and more management ability.

5. Hone your communication and interpersonal skills. You’ll be the main point of entry to your team from the outside world. Your manager or other supervisor will come to you first. Other units/teams in your organisation will interface with you on anything concerning the team first. You’re going to be managing the most difficult and unpredictable resource of all: people. You need to grow a thick skin, learn to swallow large quantities of pride and take responsibility for the failing of your team.

Things that Sam hasn’t said that are also important:

• How to spec stuff up and give other developers work. Part of your job is to keep the other developers 100% utilised. Writing specs that are unambiguous is very important.

• How to build a skeleton/prototype application that everyone else should follow

• How to foster good team morale

• How to attend, drive and lead meetings, how to document action items

• How to estimate, write a project plan and update the project plan

• How to peer into the future – if a problem is going to happen in 3 months you want to try to head it off as early as you can. If a developer is going on holiday for 7 weeks you need to start planning for it now.

• How to speak to management. They speak a different language to us. Give them solutions, not problems. Tell them what the technical stuff means to them.

And while Sam already said this, one of the most important things is learning how to say no. You will be doing this a lot. The other way to look at it is to say yes, but “only if we can get more money/time/resources” – or “that’s for the second release” 🙂

All these are by the book and good answers. Allow me to hit you by reality.
Believe it or not, much of the time you will be spending in explaining managers

• how a problem is hard to solve or
• why it can not be solved in given time line or
• even how less important it is to solve.

For this you need the skills of explaining technical things to non-technical people, in non technical terms. And it’s very difficult. e.g. consider explaining P=NP to 6 year old. Unfortunately there is no formal training for that, and you have to learn it by your own.

Also this is the position where political sh*t starts hitting you. Manager will tell you to favor a person because he/she follows the process, but you know that the person is of no use in your team for various reasons from lack in technical skills to not a good team member. So you still have to not only work with this person but also give good ratings to this person. The opposite is the person who has good skills and a very effective team member but who does not know how to please management and hence gets less ratings.
Then there are useless meetings someone at high position holding from remote location, lecturing about the effective processes and how his/her latest process variation is going to boost the productivity. You must know how to hide your boring face and look energetic.