Technical Leadership Beyond the Default

Based on my observations and experiences others told me about regarding different kinds of technical leads or lead developers (including myself in some smaller teams I’ve lead at different stages of experience) and the effects they had on their teams, I believe the following statements to be true.

• If the lead developer is simply the most knowledgeable developer (in the domain or in the technologies used) within the team, or worse, the most experienced by years of employment, and only “available” for their team rather than actively involved, that’s simply a senior developer in my eyes – and it might not even be their fault.
• Most developers will avoid practices like continuous integration, pairing, test-driven development, and even testing at all, by default – simply because these things take effort to learn, require discipline to do, and are usually not covered in college, bootcamps, and tutorials. These are just examples, and the same applies to all practices that go beyond the basics, depending on the team and context. If your technical lead does not actively coach the team and lead by example, they are just another developer in my eyes – and it might not even be their fault.
• Many developers, through no fault of their own, will set up an automated build pipeline and call it CI, split up classes and methods and call it single responsibility, and think that TDD can’t work because it requires you to define all tests before you begin implementing the functionality. A technical leader must actively fight against the flood of misinformation that spreads (on the web and within groups of people) faster than education. If your technical lead thinks that CI is a build tool, is not aware of the common misconceptions developers are exposed to and does not do anything to actively mitigate them, they are at best another developer in my eyes, if not actively holding them back – and it might not even be their fault.
• If the lead developer is the one who sets the standards top-down, enforces their own style guides and processes, and prevents any and all efforts from individual developers to try better ways of working, then they might be one of the main financial risks to the product or even the company. This one might actually be their fault! Bonus points for only knowing one single true way of working, and being skeptical (as they likely call it) of everything that is not done by the majority of the industry, continuing the vicious cycle as they grow the next generation of lead developers.

In conclusion: If your lead developer does the same as everyone else in the team, only better, and helps them execute what they’ve always been doing, you’re probably in one of two situations.

1. The team is either already extremely effective and regularly delivers high-quality software in time and in budget.
2. Or, more likely, you might want to look for a lead developer who goes beyond just developing software in a certain technology, doing the same thing they’ve always done and that everyone else is doing by default anyway.

Of course this is not a trivial problem to fix. After all, who’s supposed to decide whether a developer can lead a team to be more effective? Maybe sometimes the best you can do might be to see whether they are actually changing things for the better, and get (anonymous?) feedback from their team on whether they see things improving and are actively learning (and unlearning). If the team says “everything is fine”, then it’s probably not; fine compared to what? If they say “I’m learning a lot and we’re consistently becoming more effective”, that’s a good sign.