‘You Don’t Need Tech Leads, You Need A Strong Engineering Culture Sounds like a ubiquitous role, | am well aware, but not every software engineering organisation has or feels the need for a tech lead. In fact, the more you talk to engineers across the tech space, the more you realise, everyone has a different take on what a tech lead even is. For some it’s just a rotating hat, while for others it’s a full-blown role, or even an individual contributor level they diligently work towards. All of this, and many more reasons I’ll get into, make me believe and ultimately conclude that truly healthy engineering organisations don’t require tech leads. It’s but an unnecessary hat, a hierarchy that introduces complexity A.common engineering goal tends to be reducing complexity. When it comes to code, I don’t think Thave to explain just how quickly the opposite can happen. Often the very tools that are meant to reduce work, enable velocity or even reduce complexity are the ones that ultimately have the reverse effect. Think of the introduction of jQuery, Angular or React, for instance. In many ways, these libraries and frameworks moved a lot of complexity away from the day-to-day in the short term. The long-term effects, however, are things like spaghetti code, impenetrable monoliths and microfrontends that now come with their own complexities. Endless layers of feature switches are another common example, and if you don’t want to go as far as code, just look at Agile. In principle ‘meant to simplify things, but ask anyone who had to work with Jira and the one word they'll never utter is simplicity. The gist of itis that Well-meaning solutions often fail to address the root cause of the problem and create longer- lasting, deeply rooted issues in an organisation. The standard definition of a tech lead is precisely what we've all heard a thousand times: an. individual contributor who engineers, guides, and implements technical solutions andimprovements with the help of their software development team, Sounds easy-peasy lemon squeezy, but it can just as easily become a minefield within an engineering organisation, The hat Hats in any IC role tend to attract some controversy. More commonly, the individual contributor will feel they have all the responsibility and none of the benefits. That's one extreme. On the other extreme, you'll have those willing to take on any hat just to prove themselves. I would argue that neither of the attitudes are healthy and speaking from experience there isn’t much of a middle- ground to play with either. Ideally, a team consists of engineers of all levels, from junior to staff or even principal engineer While I don’t think there is an ideal distribution that works universally for all teams, I do think that at the very least, having juniors and seniors on the team is necessary. Within that team configuration, however, if you decide to “anoint” someone with the distinction of being tech lead on the team, you will run into challenges that could destroy the very fabric of that team: + The tech lead is a senior engineer, but you also have a staff engineer who constantly disagrees with the tech lead, Regardless of whether they're right or not, it creates an adversarial vibe that will result in the tech lead being ineffective or breaking the team up as people tend to pick sides. + Effective mentorship will fail to happen. As juniors will find themselves increasingly confused about conflicting direction, their frustration will grow to the point of requesting to move teams. Scale just these two issues up to an entire engineering organisation with dozens of teams, and you have yourself what many will call a toxic engineering culture. While rotating the hat within a team is often suggested as a solution, over time I have come to the conclusion that as it is usually with hats, it either doesn’t fit everyone, some may not want to wear it and others may want to without understanding the responsibilities that come with it Appointing the next tech lead may be done by the engineering manager — if there is one — or the existing tech lead, which in itself could be problematic as a weak tech lead may not be fit to identify the next lead, or a very senior engineer may want to appoint a weak or easy to manipulate puppet tech lead just to retain control. If that sounds untenable, remember that software engineers are just as humans as politicians, and both power and influence can be extremely valuable to someone highly intent on climbing the ladder quickly within an organisation, The role While some companies assign the tech lead title as merely a hat, others invest a whole lot more into it and designate it as a role, Where exactly it’s situated in the IC levels may vary from organisation to organisation, but typically, I see it sitting between senior and staff software engineer, becoming a level in itself. In other cases the staff engineer role itself becomes known as also the tech lead and because teams rarely have the ideal distribution of engineering talent, you'll even find teams where becoming a senior engineer also means becoming tech lead. Believe it or not, there are companies that consider the senior level to be the top level at which point you either have reached the peak of your career or are invited to pivot into management, something most ICs should consider avoiding. As it is with the hat approach, the role itself comes with a host of potential issues that one way or another will arise even with the best of intentions:« You suddenly have a hierarchy within the IC levels where a considerable set of tasks have little or nothing to do with technical leadership. It’s a superfluous reporting structure, especially in an Agile team with well-established ceremonies, such as daily standups. + The tech lead is suddenly expected to be an architect, an omnipresence in meetings, not only spending time solutioning, but also hovering over all tasks and work the team is involved in, all the while picking up work like every other team member. « Transparency also suffers, as often the tech lead will be privy to information the rest of the team isn’t. This can be useful sometimes, but it does create a very narrow funnel of information and God forbid your tech lead falls ill or goes on holiday for more than a few days, you have yourself an uninformed team, and if the expectation was that the tech lead will be the one responsible for disseminating the information, you see, you have yourself yet again a broken reporting structure. * The tech lead becomes interim EM. In somewhat dysfunctional teams, this will happen far too frequently, The engineering manager goes on holiday or is out sick, and suddenly tech leads find themselves filling in, In such a scenario, what should happen is reporting should go one step up, for instance the engineering director, VP of engineering (the most appropriate one if there are more) or even the CTO. From what I see and experience in the tech space, especially in Silicon Valley and Silicon Docks, the tech lead role is one that causes more trouble than solves problems. Tech leads typically get overworked, suffer early burn-out and quickly become the cynics they moaned about during the earlier days of their careers, All for a bit of extra pay. Dubbed sometimes as a hybrid responsibility role, I think we ought to come clean and define it as what it really is — a symptom of poor management and decaying engineering culture. Why you don’t need it It might have started becoming obvious that all the issues listed in the previous sections of this article are precisely the ones you're facing or trying to avoid, so those are good enough reasons already to consider not having tech leads on a team, but I think there are a few more aspects that need to be highlighted. Hierarchy in the real world cannot be conflated with responsibility. ‘Typically, in an organisation, there are two kinds of reorgs: adding hierarchy and removing hierarchy. The latter is often called flattening the organisation, which we mostly talk about when layoffs happen. But the very opposite happens just as much, when teams and entire orgs very optimistically decide to add roles and levels. This decision is far too often paired with the assumption that those in charge will assume the responsibility and thus everything will funetion like clockwork, or that having the role in place will help with separation of duties and concerns. When it comes however to tech leads, I believe that’s rarely the case. In a well-functioning organisation and team, the responsibility of delivering high quality, working software is not on the shoulders of one engineer — no matter how senior — but rather the entire cross-functional team. It is not one individual’s role to aggregate information from all stakeholders for the team to know what to develop, but rather everyone is at the very least aware of what needs to be done and what technical challenges are involved in the delivery. Speaking of seniority, as experienced a tech lead might be, experience doesn’t always translate 1:1 to every situation, For instance, a microservice architecture might not be the right call on the backend, nor a microfrontends approach on the frontend. Or perhaps your team is building something more exotic, like a Zoom app, and you find yourself having to get creative. A tech lead making decisions and architecting technical approaches in isolation could have disastrous effects.The above is also a hotbed for a low opportunity space. In my experience, progression requires visibility within the organisation, While moving someone from junior to midslevel is easy for a manager, from then onwards, it becomes increasingly challenging to justify a promotion without visibility outside the team, With a lead engineer, often there is less opportunity to shine for everyone else, praise can end up being misdirected, so members of a team who worked equally hard on achieving the goals, remain in the shadow of the lead. This can, of course, be avoided, but that requires a highly mature lead with a strong focus on the team. What you actually need Let me close on an important note. I realise I’m stepping on a good number of toes here. I am essentially saying, the tech industry as a whole is doing it wrong (for the most part), has been for a while, and tech leads are not the solution. That's not to say, though, that doing what a tech lead does, is wrong. You see, it’s a lot less about what one does as a tech lead, and a lot more about organisational structure. always regard skills as tools in a toolbox. The more one has, the bigger the toolbox, but just like you don’t take a plumber’s toolbox to an electrical job, one’s toolbox can be utterly useless or even dangerous in the wrong context. A tech lead’s skills are infinitely more useful in a project context than a team context What I'm proposing here is that rather than having tech leads, have either no leads at all, or just have project leads instead. Which one you opt for depends on engineering culture and engineering culture alone. From my decade+ experience so far, I can conclude one thing: the healthier the engineering culture, the less one relies on titles and designated responsibilities. Having worked in teams that had no tech lead, yet performed really well even in the context of a large organisation, I can safely say, it’s absolutely doable and beneficial for many teams to simply never appoint a tech lead or even a project lead. In this scenario, cach team member gets to use every skill they have, learn leadership by stepping up in any right circumstance that requires it. This setup fosters mutual respect, complete transparency, both team and individual visibility across the organisation and mentorship becomes a natural part of being a team member, a day-to-day opportunity rather than an individual end of year goal for a potential promotion, When this works, you can bet you have a strong engineering culture built on solid pillars and organisation-wide agreements. Believe it or not, even something as simple as having the same linting and code formatting rules or a common code review etiquette set up across teams, can have tangible, long-lasting benefits on culture and productivity and enabling successful individual contributors just as much as teams, But of course, your team or organisation may not be there yet or is simply far too large to achieve such a setup. That’s when project leads come in handy. This is but a hat, except it doesn’t come with any hierarchy, Having project leads opens the opportunity to have the most interested person in the project in a technical leadership position. This is the hat where passion and ownership can meet, Suddenly, it’s not about leading all and any technical decisions on a team, but rather making sure that the project succeeds. Another benefit of having project leads over tech leads is limited scope, both in technical challenges and time. Most projects teams take on don’t last years, especially in an Agile organisation. Within a few months or even just weeks, the project can be wrapped up, and the project lead can either lead another initiative or just take a breather for a while and join someone else's Whichever avenue you opt for is entirely dependent on how strong you feel your organisation’s engineering culture is. Perhaps it still needs work. Maybe you never even discussed it, you just have a nagging feeling that something is wrong. A strong engineering culture is tough to build andtakes time, but I feel quite strongly that having tech leads does not contribute towards a healthy one. Certainly, not in the long run. The secret to thriving engineering teams isn't hierarchy, but a strong, healthy engineering culture, and that requires as litle hierarchy as possible.