The trust-driven Tech Lead
At the heart of my changes was a theme of trust. By trusting that I didn’t have to know everything to be effective I could be more confident
It was 9 years ago that I stepped in as the new tech lead on a housing service for Thames Valley.
As the more senior people on the team moved on they left an opportunity. Even though I was relatively early in my career I was now the person with the most experience and context. Overnight people started to come to me with all their questions despite my job title not changing. People wanted help with the history, product roadmapping, technical planning and debugging. It made me feel incredibly valued to help unblock so many people.
Unknowingly I had been somewhat prepared for this step through the values of my former team. Their trust and inclusivity meant I’d seen how it all worked because I’d been at the table. I had an idea of how to build with an agile mindset.
From here I began my own journey into figuring out what a tech lead was and how to be a better one.
The unsustainable lead
My first flavour of tech leadership had mixed results. We worked on challenging problems and delivered impactful value to users at pace. We followed open standards, kept it simple and kept a focus on testing and security.
My approach was to lean into what got me there, being a good developer with a solid understanding of the codebase and how all the systems worked. Able to answer any question at the drop of a hat. I had new problems to work through. Such as making good technical decisions, having difficult conversations, and helping people grow.
There were significant problems that I was unable to see until after a passage of time:
- Everything was in my head and I became a single point of failure. I couldn’t easily take holiday and handovers were stressful events
- Answering every question was good for my growth but reduced the opportunities for the rest of my team to contribute and take ownership. I was focussed on proving to myself that I could do it – putting my own mask on first
- I sometimes worked late to support the team. In an effort to do the right thing I unintentionally hid that we had an unsustainable amount of work
- I had too many responsibilities and was burning out. I was trying to meet the expectations of both my old role as a dev and a lead
Through retrospecting with my line manager and coach, I realised that my own goal posts were unfairly wide. To be a good tech lead does not mean you have to do everything yourself. What got me here wasn’t in fact going to get me there, I had to make some changes.
Tweaking
In the years that followed I led several new teams whilst trying to find a better balance.
I found it easier to share responsibility and delegate. I found simple processes to help myself spot opportunities. I’d write TODO lists at the start of the day and day notes at the end. Being disciplined about writing these allowed me to measure and spot patterns. If they got too long or I wasn’t getting through them that was my signal to delegate.
The prospect of writing less code was the hardest to face. I love building things and knew I still had so much more to learn. I didn’t want to sleep walk into management too early in my career. A rule that I adopted (which I still follow today) was to only work on non-critical path tasks. I should be able to drop what I’m working on at any moment without blocking my team. This could include features not on the critical path. Examples include infrastructure improvements, refactorings, pipeline efficiencies etc.
The humble lead
In 2022 there was an opportunity that pushed me to take the final plunge. I was asked to be the tech lead on a new project but there was an unusual caveat. This service for the Ministry of Justice needed to be written in 2 of their standard languages but I wasn’t proficient with either. dxw try to take our preferences into account when building teams so thankfully accepting this challenge was up to me.
Other than declining I saw 2 paths forward:
Turn up the developer dial
I could turn the dev dial up to 90%, put my head down and dive into learning these stacks as quickly as possible. I’d hope to become proficient sooner or later and achieve that good level of technical context I once clung to. I would have felt more comfortable taking this path.
Having my head down would naturally mean I wasn’t able to look up and help steer the team. I wouldn’t be available to help as often, think about the big picture or get ahead with technical planning.
Remembering that my first experiences were also heavily skewed towards dev and had problems, I knew now that I couldn’t hope to sustain this path.
Turn up the lead dial
Inversely I could finally turn the dev dial down to 10%, its lowest level in my career and focus on keeping my head up.
Previously I would have questioned whether I could provide enough value taking this approach. Fortunately I had now been on the rollercoaster enough times to know that there were many aspects to being a tech lead from which I could still serve.
The questions and fears still lingered: How could I lead the team if I didn’t have a detailed understanding and all the answers? People might think I didn’t know what I was doing, wasn’t qualified for the role or wouldn’t trust my decision.
Could I do more as a force multiplier than as an individual contributor?
Going all in on trust
Over the next 18 months I attempted a more humble approach.
Being mindful of my situation allowed me to get out in front and start working on it. I wanted to be open and honest with the team about what I could bring and what I’d be asking for. I’d create space for them, defend our scope, champion best practice and support them. I’d trust them to take more ownership of the details and to represent their work.
The other developers were experienced contractors who I’d not met before which meant I had no prior relationships to lean on. In our first 1:1s I decided to be open and lead with my own strengths and weaknesses, hoping for the best in what was a vulnerable move. This was such a key moment that with hindsight had to be done early. They knew from the start that they were trusted and had agency, and I knew I didn’t have to pretend to be an expert where I wasn’t.
I look back on this team now and am happy to see improvements:
- When I was asked a question I couldn’t answer I knew which person to invite to give their view. At one point I would have felt that not being able to answer myself was a sign of failure but now I had to defer. It helped that the team knew it was coming and were ready to take the stage and share their views. They were shaping the work more often than I’d seen before and I found new value in connecting and empowering others
- I could go on a 2 week holiday without a fuss or us having to handover to another tech lead in advance. It wasn’t all in my head. The team had been at the table and knew our ways of working and in which direction to pull
- I was more valuable in code reviews than I’d expected to be. Though it took me longer to read I could still spot patterns and anti-patterns. I still could leave positive and constructive feedback and impact the codebase
- Nobody needed to work late. If it happened I could now be the one to read the signal that we were likely overreaching. Helping to reduce the pressure instead of diving in to obscure it
This felt like a healthier and more sustainable way of leading.
In retrospect my fear of running out of work for myself never manifested. I found I had space to work with other nearby teams and influence outwards too. As we settled into a routine I was also able to spend increasing amounts of time writing code and learning.
At the heart of my changes was a theme of trust. By trusting that I didn’t have to know everything to be effective I could be more confident. By being honest and trusting my team to make their own decisions I could defer to them. By trusting my leadership team to support me if my plan failed, I could take the risk and try.
To complete a circle, I was now the senior on the team who could move on and leave a prepared team who could step up, just as I had done 9 years ago.