What Does it Mean to Be a Tech Lead in a Lean Software Company?

What Does it Mean to Be a Tech Lead in a Lean Software Company?

In the fall of 2020, I tentatively tapped the “join” button, hearing the now familiar “ding” tone, to enter a Google Meets call to interview for my full-stack software engineer role. I was apprehensive, as it seemed to be an exciting and unique culture filled with highly driven, young experts who wanted to get stuff done. After being admitted to the company, I learned that the “secret sauce” of the culture stemmed from roots in studying Lean manufacturing.

Many of the gestures I have been practising daily since joining originate from Lean which, in itself, is rooted in the Toyota Production System developed by Taiichi Ohno in post-war Japan. At first, I admit, I did not understand or appreciate the system we were using at work. Parts of the methodology we were taught made sense independently - we used (what we called) a Kanban board, estimated ticket complexity to create an indicator (burn-down chart) for weekly development speed, and did daily problem-solving if we fell behind on the indicator - but it didn’t fit into a cohesive system for me from the start.

I’m fortunate to have been able to experience the inner workings of a Lean software company and, since those earlier days, I’ve expanded my understanding and I now want to share my experience as it might differ from a “regular” software company (I’ve worked on projects within many). I want to zoom in on how my understanding of the role of Tech Lead (TL) has developed and how it relates to Lean.

The more I learn about Lean, the more it makes sense, but the harder it becomes to explain. I’m reminded of Plato’s allegory of the cave when explaining Lean to others; I get the sense that you can’t understand it until you see it for yourself and then you say “Hmm, that just seems like common sense”.

My experience of being a Tech Lead vastly differs to as it is typically experienced - I don’t claim to be an expert, but I’ll try my best to explain what it’s like to be a Teach Lead inside a “real” Lean organisation!

Not a Senior Dev!

As I progressed as a developer, I mostly just imitated the Lean gestures, without understanding the why behind each one, or how they each fit into the larger picture. For example, the main interaction with my own Tech Lead was through a mechanism called “Andon”. In Lean manufacturing, when a worker detects a defect on the line that they cannot fix within a single cycle time, they pull a chord that stops the entire production line(!) which then gathers to solve the problem.

Within the world of my work (and my misconception at the time) this roughly translated as “ask for help”. The implication here being that we should have the humility to ask for help sooner rather than later to minimise waste and so that the TL can teach us “how to fish” rather than “giving us a fish”. As Andon was the main interface with my own TL, I started to see the role as “an experienced developer, who can answer my questions when I get stuck“.

As I transitioned into the Tech Lead role myself, I was introduced to the role as roughly “ensuring that the team has everything they need to succeed”. My first attempt at achieving this was to continue my regular role as a developer working on tickets, but also being the main recipient of Andons, jumping in to unblock the team as needed during the day.

The result - burnout!

I ended up alternating between devving and firefighting issues on the project when they arose. My daily development was severely disrupted by the context switching and further, after a firefighting session, because I now needed to catch up on my ticket, I didn’t invest in addressing the root cause of the problem which led to it rearing its ugly head later on.

Reframe: Developer as Maker, Tech Lead as Manager

Many months after my first project as Tech Lead, settling into the role, I was in a dojo - a Lean training artefact enabling workers to practice gestures in a simulation that closely resembles their daily working conditions - when the CEO offhandedly asked the managers to raise their hands.

I didn’t raise mine.

I didn’t see myself as a “manager” - it seemed like a dirty word, however in retrospect, it seems obvious that I was struggling to master a management role (whilst also being in denial about being in one myself). Many in tech might identify with this knee-jerk reaction to “management” through negative experiences with dysfunctional managers they’ve known. Managers are seen as aloof and out of touch, whereas it always felt like I was in the trenches with my devs.

“Come on, James, you’re a manager - you’re a Tech Lead”, she said.

My definition of “manager” at the time was “someone who coordinates the work within their team”, which I didn’t identify with. I sensed a gap in our mental models, which got me thinking more about my role and what it should be.

It wasn’t until, as one of the more senior Tech Leads, I asked to be part of a Lean management training with Regis Medina and spent more time consciously reflecting that I got my next breakthrough. There were only two technical participants on the course (me and a CTO in the group) - the rest were non-technical.

At the time, my definition of Tech Lead was “ensuring that the tech team have everything they need to succeed on their project” but Regis managed to frame my role as one of a manager within Lean: a manager creates the working conditions for the team to deliver value effortlessly.

💡

Let’s make a clear distinction between two types of jobs:

Maker: directly engineering value for the end customer.

Manager: creating the conditions for the Makers to deliver value effortlessly.

By this definition, my assertion is this: as a Tech Lead, you are a manager!

This might sound alarming to many/ most techies reading this - it might sound like I’m saying that as a Tech Lead, it’s not your job to code! Don’t panic - I’m not saying that!

As a Tech Lead, you need to focus beyond yourself as an individual contributor (IC) - early on in my role, I considered myself to be an IC whilst also balancing my time to spend on creating the conditions for team success (this involves project setup, devOps, supporting the team’s training needs, ensuring high standards of tech quality, complex technical discovery, and architectural decisions). Trying to walk the line to find the balance of time as a 50:50 maker:manager led to burnout for me, with context switching also disrupting the 50% of maker time I carved out.

So, if your primary job isn’t to code, let me try to frame what it is.

Achieving Tech Lead as Manager

Let’s assume, at first, that you have somewhat stable working conditions - a steady team that is onboarded onto a project that is actually trying to deliver value with very few external dependencies.

Just as entrepreneurs are told to be obsessed with the customer, to create the conditions for the developers to deliver value effortlessly, we must also have an obsession with the experience of developers on our projects.

The developers are the customers of the TL (the makers are the customers of the managers)!

An important part of this definition of “manager” is the word effortlessly - it’s not sufficient for you to be enabling the delivery of value, you need to be enabling your makers to deliver value effortlessly - to not be interrupted by those daily disruptions (context switching, waiting ages for CI or tests to run, having to chase up someone in product to clarify obscure requirements, etc.). You want your developers to be working in a flow state of delivering increments of value.

In stable conditions, the TL essentially lives in a cycle of:

Let’s look at both of these steps!

Identifying a Problem in Developer Working Conditions

Most aspects of the TPS model exist to illicit problems in the delivery of value (e.g. through visual management), however, two of the lesser-known tools that don’t exist outside Lean are:

Andon: developers will reach out to you for help proactively if they get stuck. This signifies a break in their flow state - there’s a problem with the conditions enabling them to produce value.

📖

Andon: a worker on the production line detects an abnormal situation (e.g. a defect) and stops production to prevent further defects. With the Team Lead (i.e. Tech Lead), they act on the immediate issue then the Team Lead problem-solves the root cause to prevent reoccurrence. Andon is the surfacing and visualisation of problems that occur on the production line.

Genchi Genbutsu (at the Gemba): translates as “go and see the real work and seek to understand (on the shop floor)”. Just because the devs have stopped asking for help, it doesn’t mean that everything is hunky-dory! The devs are probably experiencing problems they can solve themselves but which still disrupt their work. To discover them, we must sit next to the dev and watch them code (this can be done during pair programming).

The precise point at which the developer writes the line of code that goes into production and is used by the customer is the “value-added time”. In the ideal world, a developer wouldn’t need to spend time figuring out obscure requirements or pouring over docs to figure out why the API does something unexpected - think how much accumulated time is wasted on these ancillary tasks, not to mention the disruption to developer flow they cause!

Whilst we are on the Gemba, it’s our job to identify the problems and understand why the work is being done in this way (don’t blame the dev if they haven’t been given the working conditions they need to succeed - it’s the TL’s job to provide this). You will see that only a tiny fraction of total time is spent on value-adding tasks (maybe 5% or less).

Of course, some non-value added time will always required, but it’s about identifying which parts of this time constitute a “problem” with the working conditions - this is one area where your own prior experience as a developer is vital.

Another way of approaching the Gemba is doing a small ticket for yourself - I enjoy programming, plus it’s an effective way of figuring out whether or not I think the conditions on the project are optimal. This might seem like I’m just being a dev and might be the root of some confusion about the difference between a TL and senior dev, but the intention in taking the ticket is different: in the case of the dev, it’s to deliver that increment of value to the customer, for the TL, it’s to identify things that are holding back the delivery of features.

Every Andon or Gemba will reveal new opportunities for problem-solving.

Here are some key points for identifying problems in this context that you need to not fail:

Problems should be small(!): people often think that solving bigger problems results in a bigger impact, but in reality, big (or even moderately sized) problems have many causes which interact in complex ways. This means the actions we take to mitigate them often have unforeseen consequences and unexpected results, so our efforts often go wasted and we get disheartened. In reality, we should focus on small problems (smaller than you’re picturing now!) that we can predictably solve by changing a single variable - if we continue to do this, we can solve many problems, which has a compounding positive impact.

Examine a defect in a real piece created: look at something specific that one of the devs produced - this allows you to look at the code and have a genuinely interesting conversation about tech quality on the project and make meaningful improvements to the codebase. It must be specific enough that you can point to the line of code and say “Look, here is what we’re talking about”.

Problems that exist in our daily work: important problems rear their heads frequently in many forms - solving the last problem you experienced, means it’s probably frequently occurring, which means it’s important to solve. This is a form of auto-prioritisation.

Write it down: get your thoughts in order as if you intend to explain the problem, causes, and plan of action (both short-term and long-term preventative actions), then get someone to challenge your train of thought.

Using PDCA to Improve Working Conditions

Once you’ve identified a problem, it’s time to solve it!

PDCA stands for plan, do, check, act which describes an incremental, scientific approach to taking actions to solve problems.

Once again, let’s take a developer-oriented approach to this. As we look at the root causes of the daily problems faced by the devs, we see four inputs (4Ms) into the value creation process from the developer’s perspective. These are the four things that Tech Leads can focus on improving to affect the developer working conditions:

Man: has the dev been given sufficient training to complete the given task?

Machine: do the tools and existing codebase set them up for success? Are there automated measures of quality which prevent the dev merging bad code?

Method: do we have the right standards for how to produce state-of-the-art quality? Standards help the team identify when we have insufficient quality and help train them.

Material: did the dev get everything they need from people upstream to succeed (e.g. requirements and product designs)?

After identifying a course of action, as the Tech Lead, you can now work with the team to improve these conditions (which very often means going away and doing some coding if it’s a machine problem, or training the dev if it’s a man problem)!

We use two main vehicles for PDCA at work:

Daily problem-solving: when a piece of work does not meet the expected process performance, we problem-solve how we could have met the expected standard and prevent the same from happening in the future.

Here’s my last daily problem-solving from my latest ticket to show you what I mean

Problem: the database seeds for release v20 and v21 were in the same data migration table and the same file (they shouldn’t be) which caused James 2 hours of waste.

Causes:

[Machine] One data table for each seed, rather than doing them in batches (duplication)

[Machine] Random IDs for data table names and very few comments to point to version

[Method] No standardisation for this in the release process → no accountability

Actions:

Short-term: [Machine] refactor the existing code database seeds:

data table named by release number

one data table per command per release

Long-term prevent re-occurrence: [Method] new standard for adding clean database seeds and how to remove them for the release. Link this in the release documentation.

Kaizen: 改 (Kai) 善 (Zen) literally means, “change” (Kai) “good” (Zen) - and can be translated as “continuous improvement”. When the team is producing to the expected performance, it’s time to raise the bar! That’s not to say we raise the expectations of the devs (they only have so many hours in the day!), but we use PDCA to improve the working conditions to enable them to be more productive.

To summarise, the Tech Lead is looking to:

Create stability in the project through standardisation [read more]

Problem-solve with the team when pieces don’t reach the expected standard

When on-standard, Kaizen within the team to raise the bar

Think of the TL as the team value multiplier - while devs are working on tickets, the TL is constantly helping them maintain and improve working conditions to deliver quality faster.

Tech Lead in Unstable Conditions

Of course, it’s a big assumption that you’re working in stable conditions - especially if you’re working for an agency or on lots of short-term contracts. This is where the team will need a capable Tech Lead the most - not only to deliver value effortlessly, but to deliver any value at all!

The main case of unstable conditions that comes to mind is when the team is faced with large technical uncertainty. Here it falls to the Tech Lead to ensure the team is unblocked if the devs are not senior enough for the challenge. This involves getting stuck into the code and generally getting shit done! Before each project at work, one responsibility of our TLs is to onboard before the devs and do a two-week “tech challenge” to clear a path for the devs - this involves bootstrapping the project, deployment, and DevOps on a greenfield project!

In unstable conditions, the Tech Lead needs to identify (usually through experience) when the team is in unusual conditions and step in to guide them back onto the right path. In Lean, standardisation of work is one method used to create stability in work.

Each circumstance will be different and is often due to external dependencies. Use your ingenuity here!

Progression and the Path of the Individual Contributor

Tech Lead seems to be the progression path that most devs I have talked to have in mind, but considering the above, it seems obvious that not all are suited (or would want) to follow the path of the TL. It has been frustrating to see some colleagues who feel that the only way to make career progression is through the path of TL - fortunately, there is another way forward for them (which perhaps doesn’t get the recognition it deserves)!

The progression path of a maker looks more like the extreme mastery of their craft.

As a senior developer, you won’t get a fancy new job title, but you will focus on building your skills (the man of the 4Ms) and making yourself an extremely valuable programmer with a good awareness of different tools and techniques to solve problems. You will also develop the expertise to produce a great codebase (the machine of the 4Ms) and explain highly technical concepts to help other devs (if you want) which will benefit the whole team! As a highly technical person, you will be autonomous (and soon more effective than the TL) at lifting extreme technical uncertainty on your projects.

We can’t all be managers in the sense I have described - the role is meaningless without having competent makers to deliver value. Lean can also inform the path of an IC, but that’s for another post!

The TPS House

Lean is the study of the TPS outside of Toyota and many of the experts we’ve worked with have been trying to separate it from the equations and rigid processes for success that courses like Six Sigma offer and framing it as a learning system which engages everyone in the company.

Everyone at work is familiar with the sight of the TPS house:

At the top, we see that the house supports “Customer Satisfaction”, which means at a broader level, we get everyone (not just the TLs) thinking about how we can improve customer satisfaction. If there’s something we see to achieve this end, we usually use our common sense to speak up and act on it.

I hope this has been an interesting dive into the core framing behind the daily life of a Tech Lead within a Lean software company! My understanding of the role has evolved as I’ve learned more, and this article frames what the TL responsibilities are, rather than how to do these tasks well - I might deep-dive into specifics in the future!