Responsibilities of a Tech Lead
Tech leading is a role within a team that any developer can take up. They work closely with the product manager(s) and delivery manager(s), helping to provide their technical knowledge to support the team and guide the work. They will guide the technical direction of the mission by working with technical architects and the developers on the team.
Identifying and planning work
Working with the product manager(s) and within the context of your team to identify potential technical work that is relevant for the team. It’s also important to advise on the technical direction or how potential work fits within the wider technical architecture of GOV.UK.
Planning how specific pieces of work fit within the rest of the team’s work and sometimes tailoring the work based on who is in the team. This could be down to learning and development, the expertise in the team, and chats with developers.
Writing up work
As a tech lead, a significant portion of time will be spent writing cards for developers. This is either from scratch or adding suitable technical information to existing cards.
Typically, a card will contain information about what the piece of work is and why it’s being done, plus some useful context and background to help anybody pick it up, and sometimes a prescriptive acceptance criteria/definition of done.
Anybody on the team should feel comfortable picking up any card, even if they don’t have the required knowledge, they should know where to get that knowledge.
Onboarding new team members
For existing teams, tech leads should on-board new developers to the team. You should meet with developers new to the team to introduce the team’s work and overall goals. Discuss the new developer’s objectives so you can help ensure there is suitable work for them and generally help settle them in to be productive team members.
If the developer is new to GOV.UK, then it’s worth taking them through the overview slides.
Managing leavers
When a team member leaves GOV.UK, the team’s Delivery Manager should inform Business Operations of the leaver/mover.
This eventually leads to a ticket in the JML view Zendesk group, which Senior Tech will process.
Being aware of the health of your team
It’s worth having regular catch ups and chats with the developers on your team (if that’s something the developers would like) to get an idea of whether they’re enjoying their time. This might overlap with what your team’s delivery manager may already be doing, so it’s worth coordinating this to avoid too many meetings.
Things it’s useful to know could be their yearly goals, any areas of tech they’d like to learn or are interested in, whether they’re confident with the team’s work, and whether there is anything they’d change. It might also sometimes be helpful to point developers towards opportunities they might not already be aware of (presentations, leading on mission work, etc).
During team ceremonies, it’s worth being aware of how each developer contributes, and giving opportunities for those who might not feel as comfortable speaking.
Removing technical blockers
Making sure that every developer on your team has the right access to the third party services that we use. This includes Sentry, Logit, PagerDuty, AWS, etc. If you don’t have the right access yourself, you can ask a fellow tech lead or the lead devs.
Making sure that every developer on your team has access to our own services. This includes SSH access to machines, appropriate Slack channels, etc.
Helping the developers on your team with their work either by pointing them towards people who are knowledgeable and would be able to help, or by providing your own knowledge in the form of pairing or answering questions.
Championing good practice
As tech lead you have the opportunity to champion good developer practice in terms of making sure things are well tested, properly reviewed, that pull requests leave a useful trail for the next person, and the Trello cards (or equivalent) are kept up to date.
Essentially a tech lead’s role is to be the face that represents all the standards and principles by which developers need to work with.
Attending tech lead stand up and writing the weeknote
Every week there’s a GOV.UK tech lead stand up where each tech lead will talk about the work their team did in the last week, and let other tech leads become aware of anything that might affect them. At the same time, this is a good opportunity to share things that you’ve found out with the rest of your team so they’re aware of wider changes happening on GOV.UK.
There’s also a weeknote which every team contributes to and is shared around the developer community on GOV.UK.
Attending relevant Incident Reviews
When incidents happen on applications your team look after, you’re expected to attend incident reviews along with the team’s Product Manager. This is so you understand the technical work and you have the opportunity to ask questions or challenge the approach. You can give the technical direction for any follow-up actions that come out of the review.
Not knowing everything about GOV.UK
It’s important to be aware that you don’t need to know everything about GOV.UK to be a tech lead. The role is just as much about leadership and “soft skills”, than it is about technical ability and knowledge of the platform.
Not needing to be on top of everything
There’s no requirement to oversee absolutely everything your team does, and it’s better if you don’t. Every responsibility of a tech lead can at times be taken up by other people on the team. They will sometimes spot work and write cards, they’ll be able to help other team members, they might also be able to give people access to things, they’ll make technical decisions about the system, and review PRs.