Tech Lead - "I worked overtime fixing everyone's bugs"
👋 Hello, this is Valentina with the free edition of the Optivem Journal. I’ll help you apply TDD to escape the nightmare of Legacy Code. Join our paid community of 160+ senior engineers & leaders for support on your TDD journey, plus instant access to group chat and live Q&As:
When John worked as a developer on his own, he was responsible for quality - he had complete freedom and could choose to write clean code and run tests.
John was constantly fixing bugs for the whole team.
But then, because John was a senior developer, management promoted him to Tech Lead, and things changed. John found it hard because others weren't putting in quality work, and he felt like he had to clean up after them.
Bugs slipped through. Deadlines were missed. The client blamed him. He stayed late fixing things others broke. He felt like it was easier when he just did it all himself.
John had to take all the blame from the client.
The team knew little about testing. John felt like they didn't care that there were bugs in the code. He had to stay overtime fixing issues that weren’t his.
John was in direct communication with the client. The client didn’t care who broke it - John was held responsible. He had to justify the delays - why it’s late, why there are bugs. He felt like it would’ve been easier to do it all himself.
John introduced CD & TDD so that the team could get fast feedback & fixes regression bugs.
That’s when John introduced Continuous Delivery & TDD.
With TDD, the developer who broke something immediately got feedback - not during code review, not from QA days later, and definitely not from the client. The developer would fix it themselves, not John.
Now the team had regression bug protection.
John added static analysis to the Pipeline so that he didn’t have to point out minor refactorings during Code Review.
John also added static analysis tools (SonarQube and linters). This meant that as the Tech Lead, John didn’t have to waste time telling developers to clean up files or rename variables. Refactorings and basic improvements were now caught automatically.
Now, John had more time for things that mattered - bigger architectural decisions or design improvements, instead of fixing regression bugs and making minor refactorings.
The Pipeline was the central feedback source for all the teams. John was no longer the bottleneck.
The whole pipeline served as the primary feedback system for all the teams - providing continuous feedback, catching regression bugs, so that developers could fix them by themselves fast. The Tech Lead didn’t have to do bug fixing any more.
Most importantly, the team became independent. There was no more key-person risk. If the Tech Lead wasn’t around, things still moved forward. John stopped being the bottleneck.
That’s the benefit of continuous delivery, and automated tests are a crucial part of that.
John now had less stress and overtime. The whole team was empowered to deliver stable software.
John felt a lot more relaxed; he didn't have to keep everything under control. The weight was lifted off his shoulders, and he could finally focus on leading the team, working on what truly mattered, with less stress and overtime.
How can Tech Leads prevent becoming bottlenecks before it's too late?
Left my last job because of exactly that. They were dead against writing tests during development. They let the juniors and intermediates bang away at it without bothering to teach them how to write and use tests. Then I would have to plaster it up at the end fixing bugs and refactoring just enough to get it into production with minimal as possible testing capability. I couldn't handle working like that for very long.