Not Your Everyday Tech Lead: What Does It Mean To Be TL in a Lean Software Company?

Today, I want to talk to you about the role of tech lead. You may already have some impressions of the role, both positive and negative. Perhaps you're a developer aspiring to take the next step, or you've recently been promoted and you're finding your feet in the role, or perhaps you've been a tech lead for years. I want to share what I see to be an underrepresented perspective within the industry, and hopefully you can gain some value from that.

That is what it means to be a tech lead in a lean software company. My name is James, and I've been working as a tech lead for the past two years now, building full-stack web and mobile applications at Theodo.uk, which is a lean software consultancy. But actually, I joined Theodo as a developer, so this was me, not this. And consequently, I built a picture of what it meant to be tech lead by paying attention to the tech leads that I had had over the years.

There were a few things that I watched them do. They defined the project architecture and cleared up any difficult technical uncertainty. They helped me when I was stuck. They were always the person to get me out of a sticky situation. They managed to build up really good trust with our clients, and they were also able to drive the project as a whole towards success. And so essentially, I saw the tech lead as a senior developer, a person with the technical experience to solve any technical issue that might arise, rather than an entirely different role within the team. And this was a fundamental misunderstanding of the role that was very costly for me personally.

On my first project as a brand-new tech lead, I was working internationally with a large management consultancy, and we were traveling to see our clients every two weeks or so on-site, building a Greenfield e-commerce platform to sell photovoltaic cells to be installed on private properties. So let's see how this misconception that tech leads are essentially senior developers affected my daily work. I'd pick up a ticket and start coding. After all, I'm a developer, so I should be working on tickets. Often this could be something quite complex. For example, we were working on some pretty unique React components that allowed a user to select their roof on a map and see a visual representation of their solar panels that would be installed on their roof. Then a problem would interrupt my flow, and this was usually a developer asking for help with something.

Perhaps one of the developers was struggling to handle a data coming directly from our CMS. After some time debugging, in the end it turned out that someone had made a change to the data type in Contentful without updating the TypeScript types on the front end, and this had caused a bug. So we updated TypeScript and we fixed the bug. But now I'm behind with my own work. So the components that I'm building are core to our flow, so I hurry back to coding and try and get back in the zone after switching contexts. However, because I only addressed the symptoms, the problem reoccurs, and two weeks later we've got another bug because someone else made a change to Contentful without updating TypeScript. As a result, after about six months on the project, I realized I was starting to burn out. We call this the cycle of firefighting.

Sure, from the outside it seems like we were a highly functional team, and our clients were really happy. We were pushing new features on a daily basis, and I was keeping the developers afloat. But the effort was a lot, and I was definitely working harder and not smarter.

Fortunately, I've got a number of mentors at work to help me grow into the tech lead role, and they help me clarify a mentor model of what I should be aiming for. So after this low point, I actually had a pivotal interaction, which reframed my understanding of what it means to be tech lead.

During a company-wide training, the CEO offhandedly asked the managers to raise their hands, and she was making a point that was geared towards them, and I didn't raise my hand. So she looked around the room, a bit confused, and noticed me. She said, come on, James. Why isn't your hand up? Of course you're a manager. You're a tech lead. The problem was I didn't see myself as a manager. To me, that seemed like a dirty word. I thought that manager was someone who coordinates the work within their team, but doesn't actually do the work themselves. And it turns out that our CEO had a completely different understanding of what the word manager should be.

After that training, through discussion with her and others, I learned about the mentor model of management that we use in our group. The reason that I was struggling with this cycle of firefighting and burnout was because I was trying to do two jobs. On the one hand, I was struggling to be a developer getting my tickets done, because I could be interrupted at any point in the day, needing to jump in, help out with tickets of the developers, which interrupted my own development flow. On the other hand, because I was always behind with my development, I neglected some of the responsibilities of the tech lead in order to play catch up with my tickets. And this meant that the team ran into some problems over and over, and it was a constant uphill battle to stay at our team velocity as the project went on.

So here's the mentor model that we use at work. We can split jobs into two categories. Those are the maker and the manager. The maker directly creates the product or service that brings the customer value, while on the other hand, we have the manager, who creates and maintains the conditions for the makers to deliver that value effortlessly. And this is very precisely worded. It's about creating the holistic conditions for a high performing team to grow, and making sure that all of the inputs that your team needs to succeed are there. It's about success of the team, rather than focusing on your own contributions within the team. And maintaining those conditions where people really enjoy working on your projects, because they can see that the effort that they put in is directly proportional to the outputs of their work, where they're not held back by those daily hindrances of poor devX or small problems. This isn't an easy job at all, especially when there are external factors to consider. So in the context of technical roles at our company, we can see how tech lead and dev fit into this mentor model, with the developers as the makers within the team, and the tech leads as the managers. And this was the main reframe that made me realize I was seeing everything through the perspective of the developer, rather than through the framing of a tech lead.

The developers, who directly create the product or service that brings the customer value, and the tech lead creates and maintains the conditions for developers to deliver value effortlessly. So it's an important distinction to make. Tech leads are not simply senior developers. My advice on this is to understand which you are. Choose maker or manager, and focus your efforts on whichever one you want to be, but not both at once, because trying to do both creates a conflict in how you approach your daily work.

Obviously, the role is different, and influenced greatly by the culture of the company that you're at. And so I want to share how things work at Theodo, which is going to provide the background of some of the concrete mentor models that you can use to approach this vision of what a tech lead is in a lean software consultancy. So, what does it really mean when I say lean company? If you Google lean manufacturing, you'll find that the roots of lean stem from the production lines in the Toyota factories. That's right, I'm talking about how a car manufacturer can teach us about developing software.

Toyota has been the benchmark for reliability for the past 30 years in terms of car manufacturing, so it's actually hard to believe that, in the 1960s, Toyota cars were terrible. But then, when the 80s arrived, Toyota completely turned around their manufacturing process, and all of a sudden, they were some of the best cars. It's not surprising that the study of this turnaround in quality has been foundational in many methodologies that we see today. However, the original concepts get so mixed up with many other related topics that it's difficult to tell what we actually mean by the term lean anymore.

At its heart, the kind of lean that we talk about isn't to do with Agile or the lean startup. It's not about documented processes or procedures like you might learn in a Lean Six Sigma course. Cutting costs and optimizing processes are just a positive byproduct of the system. Instead, what we talk about returns to the study of what made those original Toyota production lines so effective. It's a learning system which can help us think about better ways to work. At the heart of lean, we have this concept of problem solving. It's essentially a scientifically rigorous approach to solving one small problem at once in order to make incremental improvements in our daily work.

For instance, we have 100% TypeScript coverage on a project that I was on at work. However, we still ran into a bug where a property did not exist on an object. And this caused the page to crash at runtime. After finding the source of the error, it was quite quick to fix. However, I thought to myself, TypeScript is trying to be a statically typed language. How is it that this type of error could exist in our code base? And it turns out after some quick Googling, this is a solved problem. We shouldn't have run into this in the first place. It turns out there's a configuration flag called no unchecked index access which was added in TypeScript 4.1 to solve this very problem. It checks that when you access a property of an object, that it takes into account the possibility of that object, that property then being undefined, which forces you to account for this in your code. And by adding this flag to our TypeScript configuration, I didn't just address the symptoms of the problem, but I actually prevented it from reoccurring in our code base.

This is what I really mean by problem solving. When we train everyone in our company to have this methodical approach to solving problems that arise in their daily work, we're empowering the team to improve their working conditions, the quality of their output, and therefore to bring more value to our customers in a shorter amount of time.

Going forward, I'm going to show you how Lean uses this idea of problem solving and how it can help me to understand my own role as tech lead in a Lean software company. So let's go back to our definition of tech lead. We're looking to create the conditions for developers to deliver value effortlessly. If this is our role as tech leads, then our focus should be on two things. First, identifying problems or improvement potentials in the developer working conditions. And then second, problem solving to improve those conditions and allowing the team to deliver more, faster.

So let's look at what Lean tells us about ways that we can identify and raise the visibility of problems that are occurring in the working conditions. Firstly, we have the concept of standardization. That is, defining the state of the art for something that we're producing. In this case, we're talking about things that affect the conditions required for the developers to deliver values effortlessly. The aim of standardization is to create stable conditions for the team. So if you don't create stability, you end up achieving varied results, which makes it very hard to identify what actually is a problem and what isn't a problem. And it turns out that Toyota spend about five times as long detailing work methods and developing the talent of their employees compared to a typical company.

So there are lots of things that you could standardize. For instance, having a CI that runs in less than 10 minutes and practicing continuous delivery. 100% TypeScript coverage has become a standard on all of our projects and making effective choices for tools and frameworks. These are all things that we standardize at work.

And you can see here, I've given you the templates for what I use when I'm starting off creating a standard. It's actually very common for us to ask each other at work, is this thing on standard or is it off standard? And this really helps us to align two people on whether we believe that we're working at state of the art for those conditions, i.e., the best that they can be or the best that we know that they can be for that thing that we're talking about.

So once we've achieved standardization, i.e., we've defined what good looks like, we can start to notice when things are off standard. Lean introduces to us many ways of doing this, but two core ideas that help me on a daily basis as tech lead are firstly Andon, which is the surfacing and visualization of problems that occur on the production line. When a developer notices that something's going wrong on their ticket, it's their obligation to raise this as soon as possible so that they can solve the initial problem and get back on track with the delivery of the ticket with a tech lead and also so that we can do some problem solving and ensure that the root cause of the problem has been addressed. We really make a big effort to ensure that developers can raise as many problems as they need to and work closely with a tech lead to solve these.

But even if you're not receiving any Andons as a tech lead, it doesn't mean that there are no problems happening on the ground, and to discover them, we have to go and experience the real conditions for ourselves, and this is the lean concept of Genshi Kenbutsu. We can do this in a number of ways. We can sit next to the developer and pair program with them on their tickets. We can take in tickets and get a feel for the codebase and identify where it might be going wrong and potential room for improvement within the codebase. I'm still working on tickets on a daily basis, but the focus isn't primarily to deliver value of that specific ticket, but to discover how we can improve our ways of working within the codebase. And it can also be done through code reviews, and when I do code reviews, I try to identify what is the next thing that this developer needs to learn in order to get to that next level. And, of course, this happens in Toyota factories as well. In fact, the managers see this as one of their main jobs, and they get very frustrated when they get called in for meetings just like tech leads. They want to be out there on the floor understanding the real problems faced by the makers, and it's said that the lead managers at Toyota should need to wash their hands before every meal because of the amount of grease they've picked up from the number of times they've been on to the factory floor, not just managing from an office above the production line.

Solving problems well is really difficult, and most people start off by shooting themselves in the foot. They're really tempted at first glance to prioritize their efforts to address the largest problems first, that is, the ones that are most difficult to solve with the most complex root causes, and I call this the boulder problem. So imagine you're tasked with moving a pile of rocks differently sized from one place to another. If you try and push the biggest boulder, you're going to spend more time and effort moving it, and quite often, you'll get hurt. In the same way, focusing on big problems can really dishearten you when you fail to make a meaningful change. Instead, it would have been much better to use that time that you spent moving the big boulder to pick up many smaller rocks, moving them one by one, where we can predictably and incrementally make a bigger pile in the same time that it took us to move the boulder, and all of that, the cumulative effect of all of those small rocks actually ends up building a bigger pile. So here, Lean tells us to tackle this by doing daily problem solving, that is, to use the small problems of everyday life to strengthen your team knowledge on the conditions that enable better quality and faster delivery. So focus on specific problems, not general ones, and see how you can prevent those from reoccurring.

So now we've identified a problem of the right size, let's see what we can do to solve it. When we look at, we're looking for the root cause of a problem, it will relate to one of these four inputs that go into making high-performing teams, and at work, we call this the four M model, which describes those inputs. So firstly, we have the maker, the person who's producing the thing that delivers value, and the things that go into that are their health, their knowledge, and their skills.

Then we have secondly, the machine. So this is things like, for us, the code base, the equipment, the development environment, all of our tooling falls into the machine category. Then we've got methods, so that refers to the work standards, so that is what is state-of-the-art for the way that you're doing something. And finally, we've got the materials. So these are all the things that we give to the maker, to the developer, in order for them to complete their ticket. So that might be requirements, and it also might be designed from a designer if there's any UX that goes into their ticket. And depending on what category your root cause falls under, we'll solve this problem differently.

So for the maker, we'll train the people on the specific piece that they produced. For the machine, we fix the tech. So for example, when I mentioned updating the TS config, that was fixing the machine, and I was making it impossible for someone else to fail in the future. If there was something wrong with the method, we can go back and update our standards for state-of-the-art. So we may have been producing something to the correct standards, to our best understanding of what state-of-the-art was. But it turns out our understanding of state-of-the-art was completely wrong, and now we need to go and update our understanding. And if there was something wrong with the materials, i.e. the physical inputs, the things that we gave the developer, we can then locate where the original defect occurred and go to that place to ensure that there is quality at the point that that thing was created. So if it was designs, it's going back to the designer and seeing why was there a miscommunication or a mismatch between the thing that was required by the developer and the thing that was produced by the designer.

Let's bring this all together and look back again at the cycle of firefighting that we talked about. So in fact, I actually later revisited that exact same problem where a dev was struggling with a CMS ticket. And because I hadn't solved it right the first time, with my updated understanding of my role as tech lead, I actually had a second chance to tackle this problem. So we spent some time looking at it together, and it takes us about 10 minutes to find that a property that we expected to be returned from the CMS was actually undefined. So we solved the immediate issue by fixing the TypeScript to indicate that the property had changed. But instead of returning to my own ticket this time, we first did a quick problem analysis, and we found that once again, the reason was because someone had made a change to the type of the CMS without updating our TypeScript. So at this point, we can choose to address it in one of a number of ways. We can either train the maker, fix the machine, change the method, or analyze the materials that were inputted. And I consider this kind of problem to be a machine problem, because if we fix the machine to make it impossible for us to fail in the same way in the future, we've effectively eliminated this class of problem. So in this case, actually, we found a number of ways that we might solve it. The way that we chose to address it in the end is we used a library which automatically generates TypeScript types from the data type that's defined in Contentful. So essentially, we could have three types. They're always up to date at build time. So you run TSC, or the scripts, which then generates the types and runs TypeScript compile, and your code will fail at build time rather than at runtime.

And after I implemented this, it meant that we prevented this entire class of bug, this entire class of problems, and we've broken the cycle of firefighting. I actually never experienced this problem again, which was great for me.

So what does it mean to be a tech lead? So tech leads are not senior developers. They actually create and maintain the conditions for developers to deliver value effortlessly. And if you're looking to be a tech lead, you can achieve this by the model of tech leaders manager. You do this by identifying a problem in the working conditions through standardization and on Genchi, Genbutsu, and then using problem solving to completely eliminate those daily problems.

You might have some questions about the role of tech lead in a Lean company, as I've only scratched the surface. So on top of what I've discussed today, I've got an article that addresses some of those questions and goes more into detail on some of the examples and the theory behind Lean if you're interested in learning more. So feel free to reach out to me on any of these platforms or through my website. I'm really always interested to get feedback on the things that I'm thinking about. So thank you for listening.