Why?
A common characteristic of engineering teams is that the tech lead is saddled with a whole bunch of (technical and non-technical) work and the rest of the engineering team is hungry for more responsibility and opportunity to lead. At a former tech lead gig, I had an engineer on my team express that they wanted to pursue a tech lead role, but didn’t know how to prove they could take on those responsibilities without being given the title.
Being a tech lead is a continuous loop of managing and prioritizing ideas that are introduced, serving as the technical consultant in a room where requirements are discussed, and breaking down large-scale projects into digestible chunks. Each iteration of this loop makes you a stronger tech lead as you learn the intricacies and oversights that plague the software development lifecycle.
Giving others (who are interested) the chance to engage in this work is a way tech leads can help junior engineers sharpen their skills, try a new path with low risk, and make leadership more accessible and inclusive.
How?
I’m going to detail the process I had the most success with for distributing tech leadership among interested team members. When I first piloted this process, there was skepticism around how this could be implemented in a way that gives product managers visibility into the engineers’ planning process, but also minimizes micromanaging from the tech lead or product manager.
Let’s come up with a hypothetical team! Here’s our roster:
Product Manager: PM
Tech Lead: TL
Software Engineer 1: SWE1
Software Engineer 2: SWE2
Software Engineer 3: SWE3
As the tech lead, you’ll presumably be involved with (quarterly, or whatever your cadence may be) planning. The main deliverable from planning is a set of goals (OKRs, SMART goals, KPIs to hit, etc.) you plan to accomplish. These broad and few goals are often broken up into epics to be worked on by the relevant teams.
Okay, great, we have the epics. The number of epics is dependent on your granularity and engineering team size. Here are our hypothetical epics:
- Reduce page load time by 15% (E1)
- Launch new security feature (E2)
- Design system architecture for photo upload service (E3)
At this stage I open the floor to the engineers to discuss what they’re interested in either by claiming their epics or letting me know their preferences privately. From there, we get Epic Owners:
(SWE3 isn’t interested in owning an epic -- and that’s okay!)
Now that engineers have their own epics, they are responsible for familiarizing themselves with the requirements of the epic through reading documentation or meeting with relevant parties. This is a great time to make a cross-functional epic-specific Slack (or whatever your chat of preference is) channel. Once product, engineers, designers, and QA have a vague idea of the work required, it’s time to make a Gantt chart.
Make sure to run your Gantt chart by the whole team. Not only is a Gantt chart visually appealing, but it helps ensure resources are equally allocated. The chart provides checkpoints for each epic making it easy to check in with epic owners about progress.
The only deliverable I (as a tech lead) need from the epic owners is fleshed out tickets ready to go for sprint planning. As a team, we make an agreement that we will all get our tickets in for the next sprint before the end of the Friday preceding that new sprint.
The tech lead’s only responsibility with respect to epics that other engineers own is opening up the backlog on Monday morning and making sure the epics on the Gantt chart for the upcoming sprint are represented by tickets in the backlog. If they’re not, the owning engineer gets a ping reminder.
We follow this process for every sprint until the end of the planning cycle.
By creating their own cross-functional channels for each epic, engineers get experience serving as the tech liaison and translating technical limitations and opportunities. By dividing up work into tickets, engineers learn how to take large-scope, ambiguous projects and turn them into actionable work. Through writing tickets, engineers learn how to describe work, technical requirements, and intricacies.
This process got overall positive feedback from participating engineers and gave them the opportunity to hone some skills that are difficult to sharpen before formerly earning the “tech lead” title.
Top comments (0)