At any given moment, your team will be working towards a goal or objective. There might be other small distractions or disruptive bugs, but usually, the group is some way along a month- or quarter-long project arc. As a tech lead — presumably a “senior” engineer, with extensive experience in the codebase, likely able to move faster than the majority of other engineers on the team — you have some choices to make about the way you participate.
Most often, I’ve noticed leads will dive into the work, directly writing code and fixing issues. It gets the project done, and anyway, as one of the more experienced engineers, why wouldn’t you get involved? You’re leading (presumably) because of some engineering ability, after all!
I’d like to suggest that, while it might be instinctive to write code, there are better, more valuable time investments to make.
You can and should trust your team to get the work done, and where they can’t, to ask for help. You can provide the greatest value by pairing on specific issues, sharing experiential knowledge and in code review. Blasting through patches on your own doesn’t help much.
Maybe the project will take a bit more time, and maybe that’s frustrating for you, but, for newer or less experienced engineers, the net benefit will be great. They will have time and space to own their work, feel that ownership, and develop the skills to work independently.
Instead, use your experience to imagine the state-of-the-world when the project is complete. Ask yourself, what’s next?
Talk to — and listen to — those involved in other functions, like product, design and research. Understand future requirements and requests of other teams, stakeholders or users. Document legacy code, impending maintenance tasks and the day-to-day frustrations of your team.
With those in mind, write down some possible futures. What would happen if you focused on technical debt for a week? What if you switched immediately to the next big feature? Is it time you ran a bug-fix sprint?
Lay the groundwork for paths that your team could take, outlining objectives, rough milestones, and potential blockers.
Help the non-engineering functions of your team understand what’s possible from the next point of inflexion. You’ll help product or project management plan and communicate priorities, write roadmaps and do their best work.
Point the way and empower your team.
There is more to say about the cadence of a project — the excitement and rapid progress at the onset, the doldrums of the middle, and the near-endless cycle of nearly-done moments toward the end — and how to help a team transition from project-to-project, but that’s not for this post!