For the New Team Lead: The First Six Things You Should Know

SmartBear

March 02, 2011

Congratulations! You’ve been promoted from developer or QA tester to Team Lead. It’s your first management job — which means you need new leadership skills. Before you do anything else, immerse yourself in these hard-won lessons.

They are words that bring joy and terror to the any techie’s heart: “We’ve decided you should be the team lead for this project.”

Oh no!

Can you bring the project in on time so your boss doesn’t hate you? Can you maintain your programming chops? And most important, can you do it without alienating all your colleagues on the development team?

Yes, you really can, to all three questions. As always, the best source of information is people in the trenches, people who have been there, people who have been team leads and survived to tell the tale – even if one of the lessons learned was that they really weren’t cut out to be a team lead.

1. Focus on the people issues, not the programming

Certainly, there are technical aspects of being a team lead. But while technical problems crop up, most current and former tech leads say that in their first leadership role, they were more likely to run into problems with business process and with managing people. The position is made more difficult because typically, team lead is neither fish nor fowl. You’re managing the project, but not the people, so you have responsibility without authority.

The team lead, especially a first-time one, may not have skills or training in managing people. “Too often, the team member with the most seniority is given the team lead position,” says Mike Honeycutt, technology support specialist for the University of North Carolina at Asheville. “That could be a mistake. The strong technical skills that come with seniority don’t automatically mean a person knows how to lead people.”

2. Learn to let go

Don’t expect that being the team lead means being in charge. “The big surprise for me was that the lead has less control, rather than more control, of the details of the team’s product,” says Chuck Karish, a release engineer at Google who develops tools for internal use. “This can be hard for someone who enjoys the power a programmer has over all the internals of the code they write. Leading requires taking a step back, defining requirements at a higher level, and accepting that what other people contribute doesn’t look like what you would have done.”

“A team lead position is fundamentally a support position,” agrees Mitsuharu Hadeishi, principal architect at DonorsChoose.org, a New York nonprofit that raises money for teachers and students, and who has led teams since 1989 for clients including Disney and Sony. “You’re there to make your team members more successful. Advise, listen, teach, help. Your job isn’t to micromanage every aspect of the way they code, but it is important to set up the processes: unit tests, code reviews, design reviews, allow enough time for QA, and so on.”

3. Think through your decisions

Expect to do a lot of juggling. “For me, the hardest part is always having to be the link between the technical decisions the team makes and everything else,” says Linda Branagan, who worked as a team lead in the late 1990s at Construct Internet Design. Even a simple decision – such as deciding to take Approach X to solve a problem – might have a number of ramifications, she says:

Oh crap. Approach X means interface Y. Programmer Q is going to want to do interface Y, but that would make it by far the most complex thing Programmer Q has done yet. And Programmer Q so far has been mostly fine but far from rock star. Do I take resources from some other part of the effort to make sure he’s got oversight, or give him something more clearly within his skill set, or do something else entirely?

Oh crap. At the sales and marketing meeting last week, Product Manager A noted with some glee that there was demand forming in Market B for users who want to be able to do C. Approach X, while ideal based on our current set of requirements, isn’t going to expand easily to support C. Who do I mention this to? What course of action do I advocate?

Oh crap. Approach X is going to be awesome, but it’s seven large and discrete chunks of work. I have four programmers and a QA guy who would love to write code. We can’t possibly pull this off based on our current schedule. Should I push for an extended schedule, request more people, or do we find a way to do a partial implementation of X now and then do the rest in X.1?

4. Ask for advice

Never hesitate to ask questions or check with other people, advise team leads who have learned this lesson the hard way. Google organizes recurring get-togethers for graduates of its leadership training program. Karish says it is a great way to stay in touch with people who are good to talk to when he has a problem that might be too sensitive to discuss on a mailing list. “We’ve all been through the same training on how to solve team problems, and we’ve all learned our own lessons on the basis of that training,” he says.

5. Keep the lines of communication open

Typically, a team lead acts as the liaison between the technical developers and the marketing and business managers. “You serve two masters: your bosses and your staff,” says Jonathan Bach, a Seattle software tester.

As a result, you need to remember to “manage up,” and to keep your boss satisfied without allowing the boss to micro-manage the team, Honeycutt says.

At the same time, it’s important to protect your people, says Mary Anne Wolf, a contractor for Dell Services, formerly Perot Systems, who has been a team lead since 1992. When someone messes up, he or she may blame it on someone else, including you. “If someone with authority over you insists that your team do things in a way that makes you or the team vulnerable to someone else’s inability to do their job correctly, make sure that the person in authority is cited in writing. That way, when the [fecal matter] hits the fan, you can prove that they did not allow you to do the right thing.” Your boss upstairs may claim that the problem is your fault for not persuading him not to be an idiot. Sometimes it is better not to do what you are told, Wolf says, and to have things work out well, than to do something that you know is wrong because you are told to, and then have things work out badly.

Acting as the liaison can be particularly challenging when management makes a decision you know the team won’t like. If that’s the case, getting the team’s buy-in from the beginning may make it easier. At a previous job, “My managers insisted on having lots of closed-door meetings where we decided things,” grumbles Hadeishi. “I much preferred open meetings where the whole team would discuss issues, but they thought that was too egalitarian. Naturally, all the decisions we made in the closed-door meetings met with much more resistance and resentment, even if they were decisions people would ultimately have agreed to had we done them in the open.” Keeping everyone in the loop with frequent group meetings — once or twice a week — helps keep the team cohesive, gets rid of politics, and keeps things collaborative, he says. “Gossip and innuendo can really be a serious problem on a team.”

6. Agree on the details ahead of time

Whenever you can, work to build consensus, especially in technical areas. For example, get agreement before people start coding on product features and the user interface – right down to the color scheme, fonts, and button sizes – from everyone who matters, recommends Mike Scanlin, CEO of Born to Sell, a Mountain View, Calif.-based company that develops covered call investment tools, and a team lead for such venerable firms as T/Maker and General Magic.

In particular, get end-user feedback as soon as possible — preferably during the design phase, but at least during the alpha phase, Scanlin says. “Nothing is worse than working for a year and then springing it on everyone and having eight of the first ten people all say ‘That’s nice, but what about X, Y, and Z?’” he says. “You want to know about their needs before you write too much code.”

Accept that you can’t always please everyone. “There are going to be times when you make decisions that are unpopular with some people,” Hadeishi says. “I’ve found there’s not much that can be done about that, other than sometimes I’ll take the person who objects the most out to lunch and we talk about it in depth.”

At the end of the project, you may decide that being a team lead isn’t for you. “Being a team lead means that, at some point, you’re going to have to make judgments about people, which is inherently confrontational,” says Steve Morse, a support engineer at Tealeaf Technology in San Francisco, which makes and sells customer experience management software, and who has served as team lead at a major New York bank. “Not everyone is temperamentally suited for this, which can come as a surprise.” But it could end up being, as the saying goes, an opportunity for growth.