I have been programming for about 9 years and want to move into leading a small team. I have a good technical knowledge & qualifications, a number of successful projects and have decent interpersonal skills.
I like the comapny I work with and do not want to change jobs. Most other team leader jobs seem to want management experience anyway which creates a chicken and egg scenario.
Thanks
I would suggest you sit down with your manager (not your team lead) and discuss your carreer goals. Bring up the points you mentioned above and ask what else is needed for you to be considered for a team lead position.
If your manager thinks you are valuable asset for the company and knows how to do his job well, he will give you valuable practical advice on how to advance.
Also, if your company offers any classes on project management, you might want to take them. If not, you might consider taking a collecge certification program instead.
This is a tough one. I tell folks I work with that if they desire to be a team leader they should act like one in whatever position they are currently in. This does not mean to start bossing folks around (a team lead shouldn't do that anyway) but rather to demonstrate an ability to think and act like a leader and help guide other team members. Voice your design ideas and concerns. Suggest technologies and techniques that can improve your product or development process. Read, study, and learn about technology and concepts that supplement your current knowledge, rarely can team leaders succeed without at least a basic understanding of all parts of the system. Once all that is in place, make it known to your boss and to project management that you are interested in leadership opportunities.
You definitely want to sit down with your manager. Part of his job is to enable your career growth.
Are there many junior programmers around? If not, there may not be room for another team lead. If there are, be active in mentoring them. If they come to you with a question, be vocal and expansive on telling them how to find out the answer (even if you already know it). Does your team have a knowledge-share (either a Wiki or some such)? If so, be sure to add to it whenever you can with white-papers or just tutorials on how to do common tasks at your company. Don't forget to publish the fact that you've written these things. Lower level workers won't always go looking.
Making yourself a team lead is a combination of knowledge and the ability to get others to learn and contribute. Does your division have a weekly or bi-weekly "lunch and learn"? If not, start one. If you're seen to be someone driving the team to learn new things, only good things can follow.
First, I would talk to a team lead you trust. Ask them if they like it, and what the pros and cons are. You may wish to stay as a senior developer unless you are thinking of moving into management down the road.
I would then go talk to your manager as others have commented. Bring up your desires with s/he.
Something else you can look at doing is obtaining some project management education or a project management certification.
On a personal note, I have been a project manager and a team lead, and have found management much less rewarding than working in an architectural or software development role. Some companies glue the concept of management of people, management of the project, and project architecture together, some do not. Make sure you are after what you want. Is it the money (perfectly valid)? Is it more project ownership? Do you want to be able to have more input on design? Do you want to mentor younger developers?
Talk to your manager to see if there are any immediate opportunities in your company. If there aren't, or if your manager does not think you may be ready for them, ask to own a large component of the project you are working on now, or a large new component that needs to get done. "Large" enough so that it requires more than 1 person (your team), and small enough so that the company will let you own it. If you do a kick-ass job (deliver on time, surpass expectations, and finish with your team's respect) you'll get something larger and more important the next time.
All the advice above it great and if I were you I would also do some navel gazing.
Turn it backwards. First evaluate why you want to be a team leader. Instead of looking first at the 'extra benefit' that would come to you from the company in that role, consider what it is in you that is innate and would bring benefit to a team and the company as a leader.
Are you someone that people in your group seek out for your opinion or for advice?
Are you someone that people outside your group come to for the same? Do others in the company send people to you on certain issues. "Hmm, Alex is the one to talk to about that"
Are your design decisions, code, test cases, and documentation referred to, and sometimes referenced by others, as good practice?
Are you the kind of person who rolls his eyes or worse, makes behind the back comments, about situations or assignments?
Does your current boss regard you as a solid asset in the team? Has she ever pulled you into the 'sticky' areas because she knows by doing so the problem is as good as solved?
Do you readily seek out and accept responsibility? When task assigment is occuring are you the one who steps up or waits for the "Alex, you want this one" questions?
Be honest. If you are weak in any, an honest effort at self improvement can help. Satisfy yourself that you are an extraordinary member of the team with qualities you can offer your company as a new leader.
Only at that point should you approach your manager.
All the great developers I've seen move up to become great team leads were the folks who excelled at all the points above and more. Indeed, they were the kind of people where if you or your manager were put on the spot and asked "Who in this group is a potential team lead?" - they would be picked out without any hesitation.
They were already leaders; with everything except the title.
To many of these good suggestions, I'd say a good primer is to read Steve McConnell's "Rapid Development". It had excellent summaries of what you'll need to know from a process and technical perspective. Also, try to find a good resource on focusing on win-win (7 habits of highly effective people is such a book), and on communication. They will be critical.
Also, for your sanity, probaby you should read link text, just to not take on more than you can chew. Pace yourself!!
You become team leader when you're sure enough everyone else is not doing things as well as you would like, or your vision of the architecture for a project is clear enough in your head you want to see it completed that way.
A slightly more non-flippant answer is, you simply start leading. If a company or more specifically your managers) do not realize someone trying to lead should be allowed to do so, then you should seek either a different manager or a different company. Internal transfers can be both easier (in that you do not have to interview so much) and harder (in that managers are usually reluctant to let headcount go).
I liked the answers that asked you to think about what you are looking for from a project management position.
I fought with this for years...delaying being a lead because I didn't want to lose my edge, or reduce coding time.
Now past that point by a few years, I'm still torn...but I enjoy leading technical people and having different challenges.
I'm a one-time software engineer, turned software task manager. Right now, I don't get to do any coding, management is a full time job. In fact, I also look for and promote team leads to help me.
Having been on both sides of the equation, here's some other thoughts.
All of this is demonstrable as an independant contributor. When I think about why people in my company have been promoted, these are the big reasons.
As someone who wants good team leads, I don't need the person to know all the tasks that a team lead has to do - I take on the responsibility for that part of the training myself. And I don't expect perfection - but I do expect the personal dedication to strive to correct past mistakes.
Sadly, there's a second, less fixable, part of the equation - the state of the company. There are times when the most tremendously wonderful potential team leads won't get an opportunity -- namely, when the opportunity isn't available. This was true for several years at a company I worked at - we had enough work to sustain, but not enough work to grow. So, no one was hired, and no one was laid off. But... no one was promoted. Generally, teams stayed together, and moved from one assignment to the next with the same infrastructure.
Concurrently, it's dumb, and I hate to say it - but different companies will have a different, totally unspoken, expectation about how a manager "looks". I hope that most companies these days would not discrimate for any ethically awful reasons - like race, gender, sexual orientation, or family status. But I have suspected cases in my career where these assumptions may have been true:
"managers dress nice" - this is more true in the business end of most companies, but many times, managers dress a slight cut above the rest. In a very old school company, this may be an unrealized, unspoken expecation. It's not completely without merit. In many lead positions, there will more customer facing time. The company may need to know that you have more than the 10 year old Token Nice Suit hanging in your closet.
"managers are old" - we'll call it "experienced". While I would agree that you want to promote a manager who has been around long enough to grasp the nuances of the corporation and to have seen the product go through at least one lifecyle, I'd argue that in some companies, there may be an unspoken age barrier to certain positions.
You can fix the first item by scoping out how managers dress, and imitating them.
The second is not always fixable. I wish I had a solution - I've seen companies loose good employees over this one.
A very good starting point is reading this book:
Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers)