Tech Lead - Circles of Responsibility

A Tech Lead is a developer who is a Leader

A Tech Lead wouldn’t be the same without being technical and there are a whole bunch of development skills I would expect any capable Tech Lead of having. In today’s age of agile development practices, there are a whole set of engineering practices, I would expect Tech Leads capable of doing such as refactoring and Behaviour/Test-Driven Development.

What makes a Tech Lead different from developers is their breadth and depth using leadership skills to help the team move towards a goal. Unlike developers who can avoid giving feedback to their peers, a leader must be able to give and receive feedback to help people develop and be more effective. This means not only focusing on the technical aspects, but also the team and people aspects such as relationship building, motivating, delegating, and influencing.

Developing skills in the Leader role

Developers have little opportunity to practice leadership skills. Tech Leads are fortunate to have many resources that address the leadership circle. Leadership skills are important to all leaders regardless of industry or position and you can find a plethora of books, training courses, and websites.

A Tech Lead is hands-on Architect

Developers spend much of their time in the code, but unless they start thinking of the bigger picture, it is difficult for them to start thinking beyond that. Tech Leads must help the team to:

Build systems, not software

This mindset shift helps developers think about a lot more than just the software – to start thinking of the quality attributes of software systems (or the Cross-Functional/Non-Functional Requirements) as well as the whole interaction with the deployment environment in which the software lives.

When someone plays the Architect role, he or she is naturally taking a broader view of the software – how long it’s going to last for and how it is going to evolve over time.

Developing skills in the Architect role

The Software Architect role is much newer compared to general leadership and although there are some resources available, I cannot recommend many of them because they either focus on the tooling, or they teach little that help people bridge the gap.

What is the area to focus on

Most of the developers focus on a single approach but rarely focus on a broad view that also gives developers a better understanding of the Tech Lead, particularly the Architect side to the role.

I present some tips for being an effective Tech Lead.

Learn to Delegate

As a developer, you get a kick from working out what the hard, technical problem is to solve. You research different ways to solve the problem, seek the most simple solution and celebrate a victory when you want that red, failing test going green.

As a Tech Lead, you cannot take on all the coding tasks, and cannot take on all the hard or interesting problems, regardless of your experience. You have many more responsibilities that need time and attention, and if you are focused solely on a single task, those other responsibilities will fail to be fulfilled. When you take on the harder problems, it also misses opportunities for other developers to grow and problem solve, which will lead to frustration and potentially people leaving your team!

Of course, there are some problems when your experience and knowledge are important, but you do not want to be a bottleneck in solving problems, so you want to find a way to delegate and still be involved. Solutions might include kicking off a design session with developers to talk about general approaches and reviewing progress with the developer on a regular basis to see if things are on track.

As you and the developer build trust with each other, you can be less involved and fully delegate an activity to let you focus on more important tasks.

Find Time to Code

The role is called "Tech Lead" for a reason, and it is essential that you find some time to spend in the codebase. If you do not spend time with the code, you end up leading technical decisions without understanding their real implications for implementation. This has numerous side effects including destroying trust with developers, increasing the development time of new features, and increasing the accidental complexity of your software systems.

Visualise Your Architecture

I have worked in several teams where developers had no idea how their task fit into a bigger picture. A small technical decision made by a developer might have a wider architectural impact but is impossible to prevent if developers do not understand the broader picture.

A whole-team whiteboard session is often a useful exercise for reviewing the overall architecture, as it evolves over time to meet differing requirements and the discussion during the session is even more important than the diagram. Focus on key quality attributes that drive out your architectural vision (scalability, performance, usability concerns, etc) and how they have shaped your architecture. Call out assumptions and the historical context to help developers guide their everyday decisions.

Spend Time 1-on-1 with Team Members

Sit down with members of your team to understand their backgrounds, their strengths, their interests and their goals to understand how the people in your team fit together as a group. Encourage people sharing knowledge across the team and find ways to help each team member connect with each other.

Learn to Speak the Language of the Business

An effective Tech Lead finds ways for non-technical people to understand technical concepts, and the best way to do that is to find the terms that business people use and find ways to explain tasks in those terms.