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.