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

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

The experience of being a Tech Lead can change from organisation to organisation, from being an ivory tower architect to getting stuck in the weeds with complex technical challenges. A Lean Software Company is one whose approach is deeply rooted in optimising customer value through studying the techniques used in Toyota’s Production System.

Old-school Agile also has many roots in Lean principles - Kanban, for example, is a tool used on the Toyota production line. But what can the manufacturing of cars teach us about software development?

Join me for this exploration through the world of a TL as experienced within a Lean Software Company as I reveal some of the secrets that allow these companies to deliver higher-quality software at speed.

This talk has been presented at C3 Dev Festival 2024, check out the latest edition of this Tech Conference.

FAQ

A tech lead is not just a senior developer. While a senior developer focuses on technical issues and coding, a tech lead is responsible for creating the conditions for the team to succeed, which includes problem-solving and improving workflows.

The 'cycle of firefighting' refers to the constant handling of recurring problems without solving their root causes. This can lead to burnout and inefficiencies as the tech lead is constantly shifting focus between coding and resolving issues.

Lean principles originated from the Toyota production lines and focus on problem-solving to make incremental improvements. They aim to create stable and efficient workflows, which help in delivering high-quality outcomes reliably.

Standardization in Lean methodology involves defining the state of the art for work processes to create stable conditions. This helps in identifying when things are off standard, making it easier to solve problems and maintain quality.

Andon is the surfacing and visualization of problems that occur in work processes, while Genchi Genbutsu means going to the actual place to understand the real conditions and issues faced by workers. Both practices help in effective problem-solving.

Tech leads should focus on identifying small, specific problems and solving their root causes. They should use the 4M model (Maker, Machine, Methods, Materials) to categorize and address issues, ensuring continuous improvement.

Focusing on standardization and problem-solving helps create stable working conditions, reduces recurring issues, and improves team efficiency. It allows tech leads to maintain high performance and deliver value effortlessly.

A tech lead in a Lean software company creates and maintains the conditions for developers to deliver value effortlessly. This involves identifying problems in the working conditions and solving them to ensure a high-performing team.

The maker-manager model divides roles into makers, who directly create the product or service, and managers, who create and maintain the conditions for makers to deliver value. In a Lean company, tech leads are seen as managers.

The 4M model categorizes inputs that go into making high-performing teams: Maker (health, knowledge, skills), Machine (codebase, equipment, tooling), Methods (work standards), and Materials (requirements, designs). Problems are solved differently based on these categories.

James Haworth Wheatman
James Haworth Wheatman
20 min
15 Jun, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
The Talk discusses the role of a tech lead in a lean software company and the challenges they face. It emphasizes the importance of problem-solving and continuous improvement in software development. The speaker shares their personal struggles as a tech lead and the need to prioritize between being a maker and a manager. The Talk also highlights the significance of identifying root causes and solving problems to prevent future issues. Overall, it provides insights into the role of a tech lead and the role problem solving plays in creating optimal conditions for developers.

1. Introduction to the Role of Tech Lead

Short description:

Today, I want to talk to you about the role of tech lead. I want to share an underrepresented perspective on what it means to be a tech lead in a lean software company. As a tech lead, I saw the role as a senior developer who could solve any technical issue, but I was mistaken. This misconception had costly consequences on my first project as a tech lead.

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. It 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 would pick up a ticket and start coding. After all, I'm a developer, so I should be working on tickets.

2. Struggles as a Tech Lead

Short description:

Often, complex problems interrupted my workflow as a tech lead. One issue was caused by a change in the data type without updating the TypeScript types, leading to a recurring bug. Despite appearing as a highly functional team, I was burning out due to the cycle of firefighting. It was a pivotal interaction with the CEO that reframed my understanding of the tech lead role. I realized I was trying to do two jobs: developer and tech lead, leading to struggles with interruptions and neglecting tech lead responsibilities.

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.

The 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 mental 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 mental model of management that we use in our group. The reason that I was struggling with the 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.

3. The Maker and the Manager

Short description:

Tech leads are not simply senior developers. They create and maintain conditions for developers to deliver value effortlessly. Choosing to be a maker or a manager is important, as trying to do both creates conflicts in daily work.

So here's the mental 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 their 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 mental 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.

4. Lean Software Consultancy and Problem Solving

Short description:

Theodo's approach and the concept of Lean in software consultancy. Toyota's transformation in car manufacturing demonstrates how Lean principles can be applied to software development. At the heart of Lean is problem solving, a rigorous approach to making incremental improvements in daily work. TypeScript bug example showcases the need for continuous improvement.

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 mental 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. It's 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.

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 was not 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 codebase? And it turns out after some quick googling, this is actually a solved problem.

5. Problem Solving in Software Development

Short description:

Scientifically rigorous approach to problem solving. Example of a TypeScript bug and the solution. Preventing reoccurrence of the problem through configuration. Demonstrating the essence 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 was not 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 codebase? And it turns out after some quick googling, this is actually a solved problem. We shouldn't have run into this in the first place. 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 codebase. This is what I really mean by problem solving.

6. Empowering the Team and Identifying Problems

Short description:

Training everyone in the company to have a methodical approach to problem solving. The role of a tech lead in a Lean software company. Identifying and improving developer working conditions through problem solving. The concept of standardization and achieving stable conditions. Visualizing and solving problems with Andon. Experiencing real conditions through Genchi Genbutsu.

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 forwards, 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 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 template 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 us 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 is going wrong on their ticket, it's their obligation to raise this as soon as possible and so that they can solve the initial problem, get back on track with the delivery of the ticket with the 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 the 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 Genchi Genbutsu. We can do this in a number of ways. We can sit next to the developer and pair program with them on their ticket. We ourselves can take in tickets and get a feel for the code base and identify where it might be going wrong, potential room for improvement within the code base.

7. Continuous Improvement and Problem Solving

Short description:

Continuously improving ways of working within the code base. Prioritizing smaller problems for incremental progress. Daily problem solving to strengthen team knowledge and improve quality and delivery.

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 code base. And it can also be done through code reviews, and when I do code reviews, I try and 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 that 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.

8. Identifying Root Causes and Solving Problems

Short description:

Identifying root causes and solving problems using the 4M model. Training for makers, fixing the machine, updating methods, and analyzing materials. Eliminating future failures by addressing machine problems. Using a library to generate TypeScript types for Contentful data types.

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 4M model, which describes those inputs.

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 standard, 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 the 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. You run TSC, or the script, which then generates the types and runs TypeScript compile, and your code will fail at build time rather than at run time.

9. The Role of Tech Lead and Problem Solving

Short description:

Preventing bugs and problems by breaking the cycle of firefighting. The role of a tech lead in creating and maintaining optimal conditions for developers. Using problem solving to eliminate daily problems. Additional resources available for more information on the role of tech lead in a Lean company.

And after I implemented this, it meant that we prevented this entire class of bug, this entire class of problems, and we'd 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 lead as manager. You do this by identifying a problem in the working conditions through standardization, and on, 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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Framework for Managing Technical Debt
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Top ContentPremium
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
Remix Flat Routes – An Evolution in Routing
Remix Conf Europe 2022Remix Conf Europe 2022
16 min
Remix Flat Routes – An Evolution in Routing
Top Content
Remix Flat Routes is a new convention that aims to make it easier to see and organize the routes in your app. It allows for the co-location of support files with routes, decreases refactor and redesign friction, and helps apps migrate to Remix. Flat Folders convention supports co-location and allows importing assets as relative imports. To migrate existing apps to Flat Routes, use the Remix Flat Routes package's migration tool.
Principles for Scaling Frontend Application Development
React Summit 2023React Summit 2023
25 min
Principles for Scaling Frontend Application Development
Top Content
Watch video: Principles for Scaling Frontend Application Development
This Talk discusses scaling front-end applications through principles such as tearing down barriers, sharing code in a monorepo, and making it easy to delete code. It also emphasizes incremental migration, embracing lack of knowledge, and eliminating systematic complexity. The Talk highlights the use of automation in code migration and the importance of removing barriers to enable smoother code migration.
Fighting Technical Debt With Continuous Refactoring
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Watch video: Fighting Technical Debt With Continuous Refactoring
This Talk discusses the importance of refactoring in software development and engineering. It introduces a framework called the three pillars of refactoring: practices, inventory, and process. The Talk emphasizes the need for clear practices, understanding of technical debt, and a well-defined process for successful refactoring. It also highlights the importance of visibility, reward, and resilience in the refactoring process. The Talk concludes by discussing the role of ownership, management, and prioritization in managing technical debt and refactoring efforts.
Building High-Performing Cross-Cultural Teams
React Day Berlin 2022React Day Berlin 2022
25 min
Building High-Performing Cross-Cultural Teams
Top Content
The Talk discusses the importance of effective communication and collaboration in cross-cultural teams. It emphasizes the impact of culture on communication and performance evaluation. The speaker highlights the differences between low-context and high-context communication styles and the need to understand cultural nuances. It also explores the challenges of giving feedback in multicultural teams and suggests ways to improve communication and create a feedback culture. The influence of language on communication and the importance of transparency and honesty in feedback are also discussed.
How to Make a Web Game All by Yourself
JS GameDev Summit 2023JS GameDev Summit 2023
27 min
How to Make a Web Game All by Yourself
This talk guides you on how to make a web game by yourself, emphasizing the importance of focusing on tasks that interest you and outsourcing the rest. It suggests choosing a game engine that allows distribution on the web and aligns with your understanding and enjoyment. The talk also highlights the significance of finding fun in the creative process, managing scope, cutting features that don't align with the game's direction, and iterating to the finish line. It concludes by discussing the options for publishing the game on the web and leveraging unique web features.

Workshops on related topic

Integrating LangChain with JavaScript for Web Developers
React Summit 2024React Summit 2024
92 min
Integrating LangChain with JavaScript for Web Developers
WorkshopFree
Vivek Nayyar
Vivek Nayyar
Dive into the world of AI with our interactive workshop designed specifically for web developers. "Hands-On AI: Integrating LangChain with JavaScript for Web Developers" offers a unique opportunity to bridge the gap between AI and web development. Despite the prominence of Python in AI development, the vast potential of JavaScript remains largely untapped. This workshop aims to change that.Throughout this hands-on session, participants will learn how to leverage LangChain—a tool designed to make large language models more accessible and useful—to build dynamic AI agents directly within JavaScript environments. This approach opens up new possibilities for enhancing web applications with intelligent features, from automated customer support to content generation and beyond.We'll start with the basics of LangChain and AI models, ensuring a solid foundation even for those new to AI. From there, we'll dive into practical exercises that demonstrate how to integrate these technologies into real-world JavaScript projects. Participants will work through examples, facing and overcoming the challenges of making AI work seamlessly on the web.This workshop is more than just a learning experience; it's a chance to be at the forefront of an emerging field. By the end, attendees will not only have gained valuable skills but also created AI-enhanced features they can take back to their projects or workplaces.Whether you're a seasoned web developer curious about AI or looking to expand your skillset into new and exciting areas, "Hands-On AI: Integrating LangChain with JavaScript for Web Developers" is your gateway to the future of web development. Join us to unlock the potential of AI in your web projects, making them smarter, more interactive, and more engaging for users.
From Engineer to Leader: A Workshop for First-Time Tech Leaders
TechLead Conference 2024TechLead Conference 2024
144 min
From Engineer to Leader: A Workshop for First-Time Tech Leaders
Workshop
Andrew Murphy
Andrew Murphy
Transitioning from an individual contributor role to a leadership position, especially in the fast-paced tech industry, is hugely challenging. Most new leaders don't receive any training at all in the first 10 years of their new responsibilities.Our comprehensive workshop is designed to assist new and emerging tech leaders in understanding their new roles and gaining the skills to make them confident, happy and effective leaders.
Managers Are From Mars, Devs Are From Venus
TechLead Conference 2024TechLead Conference 2024
111 min
Managers Are From Mars, Devs Are From Venus
Workshop
Mo Khazali
Mo Khazali
A Developer’s Guide to Communicating, Convincing, and Collaborating Effectively With Stakeholders
It’s a tale as old as time - collaboration between developers and business stakeholders has long been a challenge, with a lack of clear communication often leaving both sides frustrated. The best developers can deeply understand their business counterparts’ needs, effectively communicate technical strategy without losing the non-technical crowd, and convince the business to make the right decisions. Working at a consultancy, I’ve both failed and succeeded in architecting and “selling” technical visions, learning many lessons along the way.Whether you work at a product company, are a consultant/freelancer, or want to venture beyond just being a developer, the ability to convince and clearly communicate with stakeholders can set you apart in the tech industry. This becomes even more important with the rise of GenAI and the increasingly competitive developer market, as problem-solving and effective communication are key to positioning yourself.In this workshop, I’ll share real-world examples, both good and bad, and guide you through putting the theory into practice through dojos.
Out of the Frying Pan, Into the Fire: A Manager's Guide to Helping New Developers Thrive
TechLead Conference 2024TechLead Conference 2024
35 min
Out of the Frying Pan, Into the Fire: A Manager's Guide to Helping New Developers Thrive
Workshop
Andrew Coleburn
Andrew Coleburn
Onboarding to a new project can be difficult, no matter your background and experience. But it can be especially challenging for new developers straight out of school or a coding bootcamp. Drawing on personal experience as a bootcamp grad and JavaScript consultant, this talk will discuss tips and strategies for managers to help the new developers on their teams get their bearings in an unfamiliar codebase, so they can make more of an impact, faster!
How to create editor experiences your team will love
React Advanced 2021React Advanced 2021
168 min
How to create editor experiences your team will love
Workshop
Lauren Etheridge
Knut Melvær
2 authors
Content is a crucial part of what you build on the web. Modern web technologies brings a lot to the developer experience in terms of building content-driven sites, but how can we improve things for editors and content creators? In this workshop you’ll learn how use Sanity.io to approach structured content modeling, and how to build, iterate, and configure your own CMS to unify data models with efficient and delightful editor experiences. It’s intended for web developers who want to deliver better content experiences for their content teams and clients.