Observations and Practices of a Tech Lead
Series: growth March 15, 2014
I’ve been the “tech lead” for my team at work recently. It is a new role for me and I’ve had my shares of struggles and successes in the past six months.
We had a brownbag discussion a couple weeks ago about the responsibilities of tech leads and I wanted to share some of my observations and practices. For context, my current project has four full-time developers (including myself) and two part-time UX/designers.
So what kind of things do I do as a tech lead?
Legwork
Legwork is what I traditionally think of as “tech lead stuff”. You will be breaking down features into tasks, planning the high level architecture, getting your test environment setup, evaluating libraries and tools, etc.
I’ve found it valuable to focus less on the specifics and more on the strategy. For my current project, our testing strategy boiled down to:
Unit test when it provides value. Integration test the happy path. Always use your judgement.
A strategy allows the team to rally behind shared values, instead of saying “that’s just how our testing was setup when we started”.
Notice that I said strategy and not rules. Rules are inflexible and can come across as “my way or the highway”. A strategy is open for discussion when it comes down to the implementation. These are the discussions that I want to have with my team.
Story Scout
The tech lead should play the role of the Story Scout. This means constantly scouting out upcoming work for the team: looking for technical roadblocks, doing spikes for unknown functionality or libraries, making sure all the UI/UX work is in place.
Spending a few hours every iteration on scouting can reduce the number of blockers once work reaches active development. When work can easily flow through the development process, the team is generally happier and more productive.
It’s important to share your findings with the team: a “scouting report” if you want to keep up the metaphor. If you had to pick a non-obvious solution because of a strange requirement or technical reason, explain your rationale to the team. You should be ready to back up your choices with solid reasons so the team can trust that you did your due diligence and get on-board.
Codebase Presence
I find it hard to play the tech lead role without actively working in the codebase. A tech lead that isn’t committing code is a smell to me; it reminds me of Astronaut Architects that are completely disconnected from the day-to-day development.
I like to think of my development role as a builder of internal libraries for the rest of the team. To build an effective library, you need to be in tune with how the consumers (i.e. the rest of the team) will use it. Handing the team a UML diagram of “the new architecture” and then scurrying off to my desk is not the way to go.
I try to spend the rest of my time sharing knowledge. While pairing is the best way I’ve found to disseminate knowledge, I also try to write Golden Master code when working alone. A shining example can be a great guide and help teach standards and common practices when pairing is not an option.
A tech lead should be the voice of feasibility in “valuable, usable, feasible” product discussions. Having a deep understanding of the state of the codebase is crucial in know what may or may not be feasible under your project’s constraints.
What strategies do you use to balance letting the team learn autonomously versus pushing them aside and writing (or rewriting) all the code yourself?
How does the role of tech lead fit into your projects?
I’d love to hear your thoughts on Twitter.