Distributed Teams

Tech Leads

If you have a fast, continuous, distributed team, you will do a lot of communicating around code: code review and code releases. You will get less use from non-technical project managers, because they don’t communicate in code. You need “Technical Leads” - programmers who can communicate in code and lead a small team.

At a Google office the other day, I heard someone say "Tech Leads make all the decisions at Google." They also make the decisions here at Assembla. If you do continuous Agile development, they will make decisions in your organization.

A Tech Lead or Technical Lead is a software engineer who also leads a small programming team. Tech Lead should be able to:

  • Work closely with product managers and story owners to design features and prioritize tasks.
  • Support teams by answering questions and solving problems.
  • Assemble releases and drive improvements in release processes.
  • Help with recruiting and hiring.
  • And – write code.

Why is understanding code a requirement for people who lead development teams? Because teams and contributors are far more efficient when they communicate with code instead of words, especially when contributors are distributed. Because someone who understands code is better able to support teams and manage releases. And because software engineers respect people who can code.

What about Scrum Masters – aren’t they an essential part of Agile? I say no, not at all. You may want to employ a consultant with skills in coaching and “removing impediments.” But they can’t take the responsibility to delivery your product. A tech lead will.

Can engineers manage?

Tech Lead is a tough job, and some say that engineers can’t do it. You might have heard people say “a good engineer is a bad manager.” I don’t believe it. There was a time when people said that engineers made bad entrepreneurs. Today, software engineers run the most successful technology companies, and the hottest startups.

Our campaign to help hackers build tech lead skills is similar to the campaign that Paul Graham has waged at YCombinator to teach hackers how to be good entrepreneurs. The end result will eventually be successful technical CEO’s like Bill Gates and Eric Schmidt.

However, if you have tried to hire leaders for your technical teams, you know that it is hard to get good people. Our goal is to make it easier to train tech leads, by teaching a minimum set of skills that will get a good programmer started as a tech lead.

We think that good developers can become good Tech Leads by practicing a small set of new skills and responsibilities.

The Tech Lead Checklist

We have developed a checklist of daily, weekly and bi-weekly tasks to help our Tech Leads plan their major activities. Here it is:

DAILY

  • Require written standup reports each day. Read ALL standup reports. If someone did not write a standup report, contact them by chat or email, and escalate if they do not respond.
  • Attend a daily chat based on the standup reports. Ask for comments and issues. Make it short. Move long discussions offline.
  • Resolve needs and roadblocks posted in the standup reports and raised in the daily chat.
  • Look at the detailed activity report for each developer.
  • Document requests and agreements on a ticket, in a message, or on a wiki. Do not rely on verbal agreements, because they can’t be tracked.
  • Let team members select their own tasks. Balance the load. Do not let team members work on many tickets concurrently. A team member should select one or two tickets to work on and finish. The rest are available for others to select.
  • If someone has been working for several days on one ticket without committing code, ask him or her to split the ticket into smaller tasks.

WEEKLY

  • Review all tickets currently in process (for Kanban or Lean processes), or in the current iteration or milestone (for Scrum or Scrumban processes). Add or move tickets depending on schedule and capacity.

  • Ask specific developers to take the planning and task breakdown for complex tickets, features, stories. To distribute the load, obtain mockups and stories from non-developer product owners.
  • Write and post a message about what the team did last week and what the team will do next week.

BI-WEEKLY TEAM BUILDING

  • Work with your recruiters to help them locate people with the right skills for the team (but let them handle the details of finding candidates).
  • Do “onboarding.” Make sure every new developer has the information he or she needs, a development environment, and a simple task. Update setup documentation that outlines team processes such as the standup reports, the daily chat, the task planning process and the code management workflow.
  • Evaluate trial developers near the end of the trial period. Assess their productivity and quality. Write a short review. Say whether you want to continue working with them.

Some traditional Scrum Masters will say the Tech Lead process described here is micro-management, and that it is better to set weekly goals and let the team work out its own schedule. I love you guys, and we should get together for a big, warm group hug. But we should do it AFTER we use these tactics to build a highly productive team that feels great because they are doing kickass coding.

Job satisfaction

Developing the Tech Lead role improves everyone’s morale.

Developers interested in career development like the Tech Lead role because they get to take on more responsibilities, develop management skills, and progress in their careers.

Developers who don’t want to become managers still like having managers who are technical.

Business managers love working with development staff who understand both business priorities and technical issues and have a realistic view of schedules and deliverables.

Development executives find that Tech Leads allow them to utilize more distributed teams, more efficient workflows, and better development talent.

Back To The Top ↑