What does a tech lead do, anyway?
Ever wonder what a “tech lead” might do? I’m going to share with you what my regular work-week looks like as tech-lead of Aftenposten.
First, a little about our team. We’re fairly small, 11 people split across developers/product/UX/analysis. But we’re scaling up to have another 8 people join us. We currently have two streams: one focusing on our core product, and the other on new ideas. Additionally, we’ll be working closer to Aftenposten Junior, a product aimed at kids, their parents and schools. So while 19 people might sound like a lot, it’s actually split up between 3 teams. In Schibsted, we try to have leads who are responsible for tech, UX, and product, with the goal of each displine of our team being represented and having contact points.
If you haven’t heard of Aftenposten, we’re Norway’s biggest subscription paper. Schibsted is our parent company, a media organzation with many papers within Norway and Sweden.
We have a tech lead definition within our team that sets out expectations and tools we use. This is dynamic, so it’s not always accurate to what’s being done, but it’s a good rough guide for expectations.
The tech lead works actively to improve code quality in the team and help other engineers to improve by providing feedback and mentoring.
When applicable, make sure the products are scalable and shareable with other parts of the organization. They are actively involved in discussions across teams, and ensure alignment with other workstreams and the overall direction of Aftenposten.
They share knowledge within own workstream, within own team, and across the organization.
They continually find ways to improve the way the team is working. Act as an example to all team members by following the principles and practices we have committed to so that everyone on the team feels confident they can too.
They work together with engineering managers, product and UX on the overall planning, estimation, resource commitments and risk analysis.
They grow the team and help assess applicants when hiring.
Tools you might use
One to one syncs might be helpful for figuring out what your team members want to work on
Retros, for identifying what went well in a project
Planning sessions for each sprint’s stories
Sync meetings between leads
Out of scope
Handling personal issues of team members (this is the engineering manager's role)
What does this look like in reality?
Aftenposten is part of Schibsted, a media house with several newspapers - mostly split across Norway and Sweden. As a result we have a bunch of centralized teams that maintain services relevant to all our brands, like the CMS, login, and ads. Within our specific part of the organization, there’s some other teams like ops and shared tech who help us maintain our product so we can focus on developing new features.
On a biweekly basis, I have syncs with both the tech leads from across the entire organization, and a sync with our local shared tech team. The goal of these meetings is to let other teams see what we’re up to, along with aligning our solutions so that we don’t spend too much time reinventing the wheel. We bring what we’ve been working on, along with any problems with may have encountered recently. A great example of this is that we noticed a drop in Google traffic for Aftenposten, so some of our colleagues from other brands looked at their own analytics with us so we could see if it was common across our brands.
By default tech leads are generally part of the on-call rotation, so we have a meeting once a week when handing over, so that we can be aware of any problems that might’ve occurred in the last week, and how to solve them.
The tech, product and UX leads from Aftenposten also have a weekly sync, meeting to discuss matters like hiring, meetings, offsites and resources. These meetings tend to be short: updates tend to be quick, then we discuss specific topics based on what’s come up, for example, planning for OKR sessions.
A good deal of my time is spent in planning. This involves turning requests from journalists, product and users into issues that we can track, and then prioritizing them with the help of our engineering manager and product leads. Our developer team tries to share the load of these requests: a specific developer is assigned once a week to triage and create issues, replying to the requester and then either fixing the problem if it’s a critical bug, or letting the leads know they need set priority of the issue.
In practical terms, this is done through two main meetings: one on Fridays between tech + product leads where we go through the backlog and new issues together, and another with the whole team on Mondays where we go through the board, ensuring it’s up to date and any blockers are sorted out. On Mondays we also go through the roadmap together, so everyone knows what we are doing and why.
Hiring is a big one currently. Together with our engineering manager, I help coordinate tech hiring for our team. That involves setting up the interview plans, figuring out who should interview and when, and ultimately who we give offers to. I’m a firm believer in writing stuff down, so for each interview we do, there’s a guide that the interviewer can use as a basis for their interview. There’s also a role description for each role on our team, which we can use to improve the job adverts and guide the interview questions. The leads also join interviews for product/UX once they’ve passed a few interviews, so that we can get an idea of how the candidate works with other disciplines.
Coordinating involves mostly talking to people from outside our product team and connecting them with the right people. As we’re a small team, often I will pick up the requested feature myself - for example, when we wanted to implement text-to-speech, the rest of the team was busy with their tasks so I implemented it myself. It’s also also a case of answering questions about how something might be implemented, and setting up meetings between the relevant people.
A good example of this is sitting in on projects to provide opinions and facilitate discussions. I don’t spend all that much time coding, but to keep an overview of all the initiatives we’re working on, it’s useful for me to sit in on meetings and try to build an overall perspective of what’s being done.
Guidance & mentorship
Along with the engineering managers, a tech lead might want to have one to ones with the developers in the team so that the developers can flag any issues they might see technically. This can also happen in a wider group, but sometimes there’s something that someone has been thinking about but hasn’t had the right forum to share it in. Ideally, we try to raise these issues as they come up on Slack rather than waiting. Similarly to an engineering manager’s one to ones, a tech lead might want to make sure that the right developer is working on the right thing: do they have the right knowledge? Do they have support from those who know the system better? Are they enjoying what they work on? This falls a bit into mentorship, which is a pretty important part of being a tech lead. The tech lead doesn’t need to know all the answers, but should be able to guide developers towards finding a good solution.
A tech lead can be responsible for internal and external representation of our team - giving presentations, answering Slack messages in shared channels, and writing blog posts. The tech lead doesn’t need to that all on their own - but should encourage the rest of the team to do if they have interest.
Since the social aspects of our team is one of the most important part of achieving good things together, we can say that running social events is also pretty important. We try to have lunch or dinner together when we’ve reached some milestone, and we have a pretty low barrier for what we consider a milestone to be. We also have a scheduled coffee-chat once per day with the whole team, where people join just to chat. Every other Friday we meet to play some games or a quiz. These events are especially important during covid, where otherwise you might not see some coworkers for a while if you’re working on different initiatives.
Not every tech lead codes, and some do much more than others. I typically try to focus on coding things that would otherwise distract my team: one-off fixes, quick prototypes that have a short life, or require external consideration. A fix might be something like an issue unrelated to our current initiatives that is reported to our team that might take a lot of time to be formally worked on: if, for example it went: reporter => product => tech lead => issue => developer, that could potentially take a lot of time and not be worked on until the following sprint. Whereas if I take the issue up myself, it would be dealt with a lot faster. Quick prototypes tend to be something that I might spend a few hours on, again unblocking whoever requested it without disrupting the team. Finally, tasks that require external consideration are those that the central teams need to approve or require discussion. As tech lead, I’m in various forums and channels where I can push an agenda a little easier. This type of task is usually one that requires 90% discussing, 10% implementing. They might also be some improvement that will enable a better workflow or code later on from my team.
I do sometimes work on typical issues, but I find it’s more important to ensure that people on a particular initative are able to have a good workflow rather than my personal contributions.
Hopefully this helps you understand what a tech lead might do, along with why and how. It doesn’t cover everything, and it’s team-specific as different teams have different requirements, but it might provide some inspiration. Titles can always be a bit mystifying, and vary a lot between organizations. Even within our organization it’s quite different, but this is mostly accurate to Aftenposten.