Thursday, January 31, 2008

Technical Lead role

"I made the typical blunder that many first-time technical leads do. I put the headphones on and hunkered down with what I thought were the most difficult pieces of code and did them. I gave the other developers what I thought were easier tasks and generally ignored them as much as I could."

I read Jeremy Miller's blog entry, Classic Technical Lead Blunders the other day which got me thinking about the Technical Lead role. I've been the technical lead on a half-dozen or so projects. Some 4-5 people, others with 15-20. I too made many mistakes the first few times around. I'm sure I still do make mistakes today.

One of the best pieces of advice I've received was from a colleague, John Kordyback. He told me that I had to learn to delegate. In many ways, that is very similar to the quote taken from Jeremy's blog. I was doing a pretty good job leading a team of 4-5 people, but as the projects got bigger, and the number of people got larger, I had to learn to delegate to others. I could not take on all the difficult things myself. I had to learn to trust others. I learned to let others stretch themselves.

So, if a Technical Lead is constantly delegating, what exactly should a Technical Lead be doing? Surf the internet in a cozy office/cubicle? I've realized that a Technical Lead is much like a Project Manager. One of your duties is to remove (technical) barriers. An effective technical lead will be able to recognize barriers, and figure out how to remove them. That doesn't always mean that you should be the one fixing them. Solicit advise/solutions from the team. Make them think about the problems too.

An effective technical lead is never happy with the status-quo, and is constantly looking for ways to increase the team's velocity. Some would equate this to the Lean Software Engineering phrase, "eliminate the muda." "Muda" roughly translates from Japanesse to English as "waste."

Another idea that comes from Lean Thinking is a Value Stream Map. As a Technical Lead you should always have a mental picture of your delivery value stream map. You should understand where the waste is. Your role is to eliminate muda. From a technical standpoint, this could be many things. Some examples of muda that I've seen over and over on projects:
  • Tests take 45+ minutes to run. Thus, developers are wasting hours in the day simply waiting for tests to run.
  • Unbeknownst to the developers, the DBA applies a change to the development database. All of the developers stop writing code, and instead are trying to figure out why the application has stopped working.
  • The deployment process to the test environment takes a developer away from the project for half the day.
  • Merging a feature back into the code takes more time than actually implementing the feature.
  • The time to write the unit tests take exponentially longer than implementing the feature.
All of these lead to massive waste on a project. As a Technical Lead, it's your responsibility to recognize these types of issues that negatively effect the project's velocity. Find solutions. Weigh the time it takes to implement changes against the waste it will remove. With the help and support of the team, apply the changes. Continue to re-evaluate your Value Stream Mapping, and implement new improvements.


Jason Yip said...

Depending on what is meant by "technical lead", you may also be in a position to deal with issues of unevenness in scheduling leading to unreasonable demands leading to wasteful activity.

I'd also suggest that a technical lead should be able to help identify which aspects of the solution deserve maintaining multiple options and which you can just choose one and go with it.

Ankit Jain said...

"The time to write the unit tests take exponentially longer than implementing the feature." is this always true? As a developer I do see it takes a lot of time to implement unit tests. Just wanted to know if there are some ways to reduce that time involved???

David Kaspar said...

Just found this by chance (via Mark Derricutt FriendFeed).

Some profound thoughts... I guess I too focus on implementing all the hardest parts of a project myself to enable the team to work faster.

But maybe this is incorrect thinking; I shall try an delegate more in the future and focus on minimising "muda" (after surfing the Internet in my cubicle is done).

Bil Simser said...

The term can be interpreted many ways but lots of good stuff to watch for in yours and Jeremy's posts. I'll step in for things like getting that nasty ClickOnce deploy down from 1/2 day to 10 minutes (something I'm working on now) that I don't want my team to be writing powershell scripts (which would also mean learning powershell). Not that learning and new stuff is a bad thing, however if we as leads can help drive developers to develop the end result to the business user is much better off ("Oh, we're sorry we didn't implement feature X we were building infrastructure and a message bus").

dilip said...

I was working as a Team Lead handling a team of 5-6 people and I have 6 years of experience.My Project Manager (newly appointed 3 months ago.) appointed one of the junior programmer (2 yrs exp.) working under me , whom I trained, as Team Lead and promoted me to Tech Lead saying it is promotion to my career.But now,I have to report to my newly appointed Team Lead and take permission for each thing.Due to this my personal life is also being effected.
I am confused and do not know actually Tech Lead reports to whom?

Jessica said...

Great artcile! I've worked as a technical lead for almost 9 years on projects ranging from small to large in size and scope. I really liked how you summarized the core essence of what a good technical lead does for their team.

One thing to point out is that obstacles aren't always technical in nature. And that a good technical lead will identify (and often help to work through) these as well. Specifically, working through issues with your business counterparts - if their requirements are incomplete, unclear, etc. this can be one of the biggest "muda" creating parts of a project.

Code can be perfect, but a project will still fail if you don't meet your organization's need. Fostering relationships and communication across the IT/business line can be one of the best things you can do for your team.