The “tech” of a tech lead

This is the first article of a three-part series exploring the important role of the tech lead.

When developers are promoted to the role of architect or tech lead, it is easy for them to focus on only writing code because that is what they are used to.

Although an effective tech lead still writes code, the role is accountable for a broader set of technical responsibilities, some of which are explored in this article.

Engender the technical vision

Whether a team is building a web application or a large data warehouse and analytics system, it is important that each developer understands how his or her work fits into the bigger picture. Sometimes a seemingly small decision, such as a particular tool, can have a broader impact on the overall system architecture.

A consistent system architecture can lead to increased productivity as it should be easier for developers to add new features, or make changes to existing parts within the system.

A tech lead might achieve this understanding by gathering developers in front of a whiteboard to collectively draw a logical view of the system architecture. He or she might also draw on other perspectives such as a physical deployment view or an interactive sequence diagram to explore boundaries and constraints. A good system architecture helps developers understand how the software they build interacts with end users, summarising what key responsibilities each part of the system has, and more importantly what parts of the system should not be doing.

Champion of system quality attributes

As a developer, it’s easy to focus on building features and functionality, as after all, this is often all business people ask of the development team. A tech lead must, however, champion the quality attributes of the system or the non-functional requirements (NFRs).

In some circles, these are often called cross-functional requirements (CFRs) because all systems components should exhibit these attributes. Some typical quality attributes a tech lead encounters include:

  • Authentication - Who you are
  • Authorisation - What you’re allowed to do
  • Monitoring - The ability to detect when system behaviour is unusual
  • Performance - How fast or scalable is it
  • Security – The ability to guard against external threats; and
  • Usability - How easily can users complete the task they need to do

Every software system has its own unique set of attributes depending on who the users are, what the problem being solved is, and how an organisation is structured. When a system does not meet its minimum quality attributes, the developed features are worthless.

Building systems, not software

In many technology firms, one part of the company runs the operations and infrastructure, while another part, the developers, program new functionality. Many developers write code never knowing how their software runs in production.

Tech leads are responsible for the success of the software system, which is only possible once the software sits in production and is used by end users. Understanding how the code interacts with its operating environment brings a different perspective to writing code, and tech leads should help their developers understand the operational world.

They can do this by ensuring developers experience some level of production support and understand how their users actually use their system.

Focus on technical principles, not implementation

A tech lead may feel like he or she needs to understand how a particular feature will be implemented, but this is unpractical as the team grows in size. Instead, an effective tech lead should find principles that guide the team as it makes individual decisions along the way.

A principle such as, “Use open source libraries where possible instead of proprietary products” sets expectations without taking away the important decision-making power of an individual developer.

Good principles provide clear direction without constant intervention. Unlike rules, principles allow for exceptions where a more appropriate solution fits better in a particular context. Principles set clearer boundaries without setting hard borders, which tend to scale better than focusing on every implementation.

It’s okay to write less code

As a developer, it is easy to feel as though the value you generate is through the amount of code you write. Therefore, when a developer moves into the tech lead role, it is natural for the person to immediately feel like he or she is contributing less to the team because he or she is writing less code. Although a tech lead will spend less time writing code, when he or she fulfills new tech lead responsibilities well, he or she adds significant value in a different way.

A tech lead adds tremendous value when he or she surfaces conflicts within the team to uncover the pros and cons of different approaches, identifies and manages technical risks, and navigates the corporate world to remove obstacles. Finding consensus is by no means easy, but when a tech lead facilitates this process, the team saves time on arguing and improves the productivity overall.


The tech lead owns a broader set of responsibilities that reach beyond writing code. Unlike other managers, the tech lead is responsible for a number of technical aspects that include setting and maintaining a technical vision, championing quality attributes and helping the team build systems, not just software.

Tech leads can do this successfully by communicating technical principles and being comfortable with how they add value to the team in their new roles.

Patrick Kua is a speaker, author and tech lead currently working at ThoughtWorks