What is a Tech Lead?

August 25, 2015 @ 10:27 am Posted to .Net, Agile, Consultancy by Antony Koch

The tech lead role seems to be used in wider and wider circles, with each company defining the role in different ways. So what is a tech lead, and what are their responsibilities?

To my mind, the responsibility flows in three directions:

  1. Upwards: Responsibile to the board for delivering the project to a high technical standard, an architecture that adheres to the company’s core principles and a solution that befits the budget and scope
  2. Downwards: Ensuring the team follows rigourous coding practices by laying out the framework for them to do so. Ensuring TDD is used and that the acceptance tests are kept up to date.
  3. Outwards: To the client. Ensuring their internal infrastructure is able to support the solution as designed, that they feel engageged in the creation and delivery of their project from a technical level, and that they have adequate access to see their work progressing steadily.

In my previous role the tech lead was the most senior technical consultant assigned to a project, and ultimately the person who hands the keys over to the client. They are responsible for defining the architecture,  assuring sign off from the other tech leads, and defining the engineering standards to be followed by the development team.

Ensuring a good solution at the code level is critical in order to avoid major refactors down the line. Rigor around coding also ensures new features can be added with minimal risk by maximising code reuse. Taken to the next level, the tech lead’s job is to look ahead and build a solution that takes the future into account while not holding back development work. This can be a bit of a juggling act sometimes, with some observers feeling that work is being done that is not of direct benefit in terms of features to the client. This plays into the consultancy part of the role – talking clients round to doing something now for a payoff in the future.

The final piece of the puzzle for me is to ensure that the financial implications of any solution are considered. One example from my own experience is to consider high usage rates of a system as a pointer to high costs if not caught soon enough. Large numbers of files with a high number of requests can quickly become very expensive, meaning compression and minification of static assets takes on more meaning that simply performance. It means cold, hard cash to clients.

No comments (click to be first!)