Three Tips to Become a Better Tech Lead
Switching into a lead role is exciting, but can also be a little overwhelming. As a junior or medior your main responsibility is to delivery your own work in good condition, but as a lead you are in charge of making sure *others* are able to do so. Depending on your team, you will likely adopt a new set of responsibilities: creating the technical roadmap, onboarding new team members, managing releases… and more.👾
This requires a different skillset and is quite hard to prepare for. In this blog, I’d like to share three lessons learned that helped me in my first year as a lead.
Automate the answers to FAQs
As a tech lead, you are now the first point of contact for other teams. Especially in less mature projects, you’ll frequently get requests like:
- “I need a new table for my dashboard, can you deploy it for me?”
- “I have requested a forecast through your app 30 minutes ago, but I still cannot see a result. What is going on?”
- “My forecast failed with the error message ‘weather data out of date’. Can you look into this for me?”
You cannot plan for these questions, they just “pop up”. Failing to address them can block others in their work. But you have many other responsibilities too! What’s the solution?😶
Probably the worst choice is to “just do it on the side”. This strategy puts huge pressure on your workday and is not sustainable, especially once your project grows (believe me, I tried).
A slightly better option is to delegate tasks to your team, but be careful. Picking up side-quests leaves less time for your team’s main quest. If you choose this option, make sure that the work is visible to your product manager so that he can set priorities.
But even then, these new tasks will slow down your team. A better way to deal with this situation is to invest in solutions that address the root of the issue. 🥕
Basically, the goal is to enable others to answer their own questions, using solutions like:
- A Wiki and a few sessions to explain how everyone is supposed to work with DBT, so that analysts can self-service their tables.
- A simple Grafana dashboard that shows in real-time the status of forecasting jobs, so that users and testers can check the job status themselves.
- Automated data quality reports that informs both the data owner and the people affected by the issue.
Because our team was already working with these tools, all we had to do was finetune it and make it accessible to others. With these relatively low effort deliverables, we were able to free up time and headspace.
This extra space can then be used to increase your team’s velocity. That brings me to my next point…⬇️
Strive for a stable velocity before increasing it
Your project was a little delayed, but now you can finally catch up with your main deliverables. You push yourself and your team and deliver cool functionality in a short timespan. At the end of each sprint, only a few tasks remain unfinished; yet you still feel like you’re… sprinting? Why is that?🏃♂️
One of the traps you can fall into (like I did) is setting overly ambitious sprint goals. This is understandable, but failing to complete tasks on time is a mistake:
- it lowers your team’s morale
- it damages stakeholders’ trust in your team
- it leads to delays for other teams
We addressed this issue in three stages.
First, we talked about it every two weeks with our team, and later with our project manager. We jointly decided that we needed to become more ‘predictable’.
In order to achieve that, we
- Improved our refinement process. We invested in longer, more frequent, and better-prepared refinements, in order to ensure that the scope of a task was more carefully captured.
- Tracked our time. For a few weeks, we registered how much time was spent on any task that was not related to development.
Finally, we used this information to better estimate how much effort is required for our tasks compared to how much we can spend. After about two months our carry-over had almost reduced to zero.📊
As a consequence, our work felt more organized and naturally the team started to deliver features faster. But just delivering what is asked may not always be enough…
Keep the product simple
Your stakeholders are excited that your team is running smoothly, and want to incorporate the newest tech to make your project even more sexy. After all, who wouldn’t like to boast about “the end-to-end integration of a 7 billion parameter large language model” in their Q2 demo?
As a tech lead, your job is sometimes to be the party-pooper that says “no”. If you don’t question a feature’s value, there’s a big chance that nobody else will, and this can have consequences for your project.💩
Of course you cannot just say “no”: you are a tech lead, not the product owner. This feature request came from somewhere; you need to figure out the underlying motivation. After that, you can offer to brainstorm solutions together that achieve the same end goal. Or you can try to change their mind with solid arguments.
It can sometimes be difficult to see if a new feature is worth building or not. Below you can find a few dark orange flags that can help you identify risky features 🚩:
- the user/stakeholder did not request the feature
- you cannot write in a short text what the feature is supposed to do
- nobody has defined how to test/measure the performance of the feature
- the feature has many inter-team dependencies
Out of the three lessons, this one is closest to my heart: simplicity is key. I’ve always carried this opinion, and I have found it to be true in all projects I’ve worked on. If you don’t believe me, perhaps this resource can convince you.
In summary, these three tricks helped me improve my team’s workflow:
- Handle unplanned requests from others by enabling them to answer their own FAQs.
- Work towards project goals by prioritising a steady velocity first, rather than a high velocity.
- Minimise effort wasted by questioning the value of new features.
… but isn’t this obvious?
Well, yes, it ís pretty obvious. But just like riding a bicycle, the only way to really let these lessons sink in is by experience (at least, for me). However unlike riding a bike, these issues remain challenging to navigate. So even if you knew this already, I hope this blog helped as a reminder ;). 🚲
That’s all I wanted to share with you, I hope you enjoyed the read! I am Lennart Damen, senior consultant at BigData Republic. Feel free to reach out to me on LinkedIn. And by the way, if you have a few years of Data Engineering under your belt, we’re hiring!
