Zero to Hero: Tech Lead Edition

Posted on February 05, 2024

Zero to Hero: Tech Lead Edition

Fans of Bojack Horseman might get (from the choice of cover) a feel for what this post is about. Others will get it after reading through.

For the last year-and-a-half I’ve been the Tech Lead of Up Learn’s Learning Experience Squad - called Enlighten 💡. It was my first time in this senior role and a massive learning experience (pun intended). What follows is a collection of my key takeaways, gift-wrapped for those looking for advice on their first venture into leadership, a peek at a Tech Lead’s routine or even life advice.

What is a Tech Lead anyway?

Software products are built through collaboration since they’ll invariably grow too complex for an individual to manage. That requires coordinating tens, hundreds or even thousands of people around a single codebase. All kinds of structures emerge to manage such a headcount - the most basic one is usually called a squad.

A product squad typically consists of 1-10 engineers, one product manager, one or more designers and one or more data analysts. A Tech Lead is the squad’s housekeeper - they’ll manage communication and strategy overhead, while ensuring good quality code output and performance of each engineer. The role is explained in more depth here.

As a tech lead, your major concerns will be long-term code health, team performance and individual engagement. The following lessons should help you prepare for obstacles towards these goals. They’re 100% scientific, objective and totally not just my rudimentary opinion.

Lessons

Create predictability

To perform well, people (and squads by extension) should rely on habits, which can’t emerge spontaneously in highly unpredictable environments. Therefore, a Tech Lead’s primary goal is to create predictability for its team, so that good processes may emerge. Most of the advice hereon merely stems out of this. Think about it:

Your PM wants predictable deadlines and predictable development speed.
Your designer wants predictable implementations of his work.
Your user wants predictable behaviour.
Your manager wants predictable results.
Your engineers want predictable code, predictable workdays, predictable requirements, predictable documentation and predictable launches.

That goes in an inwards sense - your team should know what to do and to expect every day, week, sprint, quarter - as well as in an outwards sense - your PM and people outside of the team should understand what the team is up to, why and when to expect each deliverable.

If your team is constantly asking what to do, meetings feel awkward, plans are shifting, people find themselves idle or blocked - these are signs of unpredictable management. If you’re constantly reacting (putting out fires) that’s usually a bad sign. It’ll make you anxious and the team will lose a sense of direction.

(personal experience) The PM’s role has been to decide on what the team builds next - even if the TL can advise on that, or worst-case veto on a very dangerous scenario. The TL’s role is to ensure the path is clear towards realizing their vision, striving for the magic keyword - predictability. Case in point, keeping the PM aligned on deadlines and having the team be able to stick to them.

A good place to start is yourself. Find a predictable work routine and create predictable processes to organize your work. Here’s what a usual week may look like (assuming Monday is when the sprint is planned):

Monday - pick up the context you (hopefully) left last week, use that to align with the PM on a single goal for the week and deliver that to the team on the planning meeting.
Tuesday through Thursday - normal operation. Two 30min blocks for comms: start of the day and post-lunch. Read everything and turn whatever you need into action items. Categorize, delegate or execute them as appropriate. Have a daily standup, unblock engineers and pair with someone if you can.
Friday - while you still have the full context of the week, write down the most important things to be taken care of next week.
- Is there anything to add to a meeting agenda?
- Are there any team dashboards / scoreboards that need updating?

This model’s been useful for me and got good reception from the team. It stems from an engineering value followed at Up Learn: doing one thing at a time until you’re satisfied with it. With that in mind, I noticed the impact of weekends in a goal that spans multiple days: our team - myself more than anyone! - would lose some context between weeks, slowing down whatever work was being done. Instead I decided to try and present our roadmap in week-sized, visibly achievable short-term wins. That led to an increased sense of ownership of our current goals and got the team more engaged.

You work for your squad, not the other way around

You deal with everything behind the scenes so that their workday is predictable. From high-level estimation to putting out unavoidable fires, communicating with stakeholders and everything in between. You should be careful not to overprotect your engineers’ time, but it does make sense to deal with most external context.

Questions you should ask: “How can I help?” “Do you have everything you need to move forwards?” “Why did this task get stuck? Is there anything we can do to prevent that next time?”

Ask questions

Ask lots of questions. Make sure you understand everything. Build enough context to make confident decisions.

As a lead, it’s on you to pick the right path and clear it. As a spokesperson, queries about the team will be thrown at you - you’ll be expected to know what the team is doing and explain why. As a mediator, you’ll also be responsible for stepping back a conversation and ensuring everyone’s putting mental effort towards the right goal.

Your nemesis is pretending you understand something. It breaks hard-earned trust from everyone towards you. Do yourself a solid and get that conceptual ground covered. Here are a few questions I eventually started using every day:

Is there anything I can help with?
What’s your biggest challenge right now?
How do we know? (as response to a statement)
What problem are we solving?
What is the tradeoff?
What is the team’s priority?
Why are we building this?
Do we need to fix this bug?
Can we think of a simpler solution?
How did we arrive at these requirements?
How did we validate this design?
What is a _?
What happens if _?
Is it clear to you what happens if _?
Is there anything missing in this flow?
Which OKR should we sacrifice in favor of this demand?

Finally, make sure no alignment goes amiss. It’s easy to take for granted that the PM understands implications of a technical choice. This corresponds - on the PM’s side - to expecting engineers to know undocumented details around requirements. Dig in a little bit and make sure both gaps are filled.

Be upfront about not knowing stuff

No one expects you to know everything (that’s kind of impossible). But it’s important to know how to deal with not knowing. Not knowing will be a constant for you. Learn to be upfront about it. Say “I don’t know. I’ll find out and get back to you.” (and then do get back to them). Ask for a deadline - “by when do you need this data?” - and stick to it. Consider getting someone in your team on that if it’s urgent enough that you can’t do it yourself, or if you have higher priorities. Honestly, that’s usually better than handing out bad data. People will appreciate the honesty and thank you for it.

This is more general advice but should be especially relevant now given the previous topic.

Take notes

Start a rolling chat notes document. One for yourself and one for every relevant meeting. People go back and forth on their word and you’ll often need something tangible to enforce agreements. Debrief for ~5min after every meeting whenever necessary to make sure your notes are succint and clear. You’ll thank yourself.

Find (or create) the appropriate channel

There’s an appropriate channel for every discussion. As a default, instead of jumping to solve an issue on the spot, find the appropriate time and medium to deal with it. Demands come in all shapes and sizes, but over time one starts to notice patterns. Without a proper medium for those, you’ll end up reacting most of the time. Instead, thin about the topic being addressed:

Comms? 30min twice a day
Requirements? Feature Chat
Squad processes? Squad leadership chat
Squad process feedback? Retro

If there isn’t a medium, then create one! Managing intake gives you the ability to deal more effectively with demands. Most issues are not as urgent as they seem. There will be exceptions, but those are few and far between.

Step away from coding.

Goes hand in hand with the above - your metric is the success of the team. Coding should be 30-50% of your time. The rest is admin, documentation, comms and operational work to make sure your engineers have the peace of mind you’ve once enjoyed 🥲. You will deliver much slower and you will feel sad about it. Make sure everyone’s aware of this so they know what to expect from you as an engineer. Eventually you’ll stop measuring yourself by your own code. That’s when you’re ready to start leading for real. Avoid build tasks 90% of the time. Especially if they are blockers for other people’s work 😱 Pick up bug tickets in the sprint and other miscellaneous work.

Delegate

It’s on you to understand what’s preventing a squad from delivering better. That requires investigating to find bottlenecks. Often, that bottleneck will be you, and there’s absolutely no shame in this - you have, after all, very limited time. That’s an excellent trigger to create a system around that task, and have other people step in.

If you can’t make time for mapping requirements well, consider creating a temporary (per-project) role on your team for that. To build confidence, place yourself as the reviewer - you’ll still be ensuring quality without spending as much time. Feed the role into your team’s process and they will follow suit.

Try to get as much of your team’s opinion as possible. My advice here is to become the example by showing vulnerability: if you don’t know how to delegate something, acknowledge that - invite people’s ideas and respect those. You might also create a channel for that: maybe a process-related monthly all-hands will help? Keep in mind that your feelings resonate through the team: by taking this first step, you create a safe space people trust to open themselves up. With that in place you can more easily draw on their thoughts and ideas to build better processes together. We’ll go deeper into feelings later, but case in point: you’ll find better solutions for process gaps - including opportunities for delegation.

Think of the longer run

The code you ship is the code you live with. No matter how long it takes to build - building it right the first time is always cheaper than fixing later.

Hacky code adds an extra cognitive hoop to development that makes additional code harder to write. With many simultanous coders, this means inefficiency over time - worse, it leads to further hacks. But it gets worse: you won’t fix that hack later. Just consider how frequently a hack gets shipped (once a quarter?) versus when a hack is fixed (when a project touches that file, maybe). As a result, your best option is to not introduce it at all.

Rule of thumb: as the squad approaches a new project, before even thinking of delivery, focus on making the right calls to avoid slowness on the long run. Keep this diagram in mind:

Getting that context clear for your PM as soon as possible will come to your advantage. Agree on the common goal of minimizing bugs at the outset of the conversation. Conversations around quality can get awkward, especially without that ground laid out.

Can’t we improve this code later?
We can’t keep improving the code forever.
Why is this taking so long?

Finally, don’t bother trying to predict the far future: the chance of assumptions being right falls dramatically the further in the future. Where’s the sweet spot then? You learn that from experience, but 6 months is usually far enough that expectations start to break. As an exercise, look at your own code from 6mo ago - how do you feel about it? Would you refactor it knowing what you know today?

Execise pragmatic thinking

The software product as a craft is ripe with counter-intuitive concepts. Depending on your PM’s level of exposure to it, there’s a chance they’ll only learn through experience. That may require the team to live with inadequate processes for some time, and you’ll still be responsible for everyone’s engagement and quality of delivery. Being pragmatic is key here - without good evidence pointing to the value of a change in process, it’ll often feel like pushing for a change out of personal preference. People will often (justifiably) show resistance and skepticism towards such a posture, as it can appear whimsical and unreasonable.

That can strain communication. Instead, align on the goal - taking the team to a better place -, detect the gap, find the observations that led you to that gap, describe why you think that’s a gap, how it affects the squad. Maybe share the changes you’ve considered, why you’ve discarded them.

You may need to go even beyond that! I’ll illustrate this with an example from personal experience:

At Enlighten, about halfway through migrating Quizzes, we faced a massive amount of quiz-related bugs. Those were hard to catch and near impossible to predict. I suspected of a few process gaps which could be causing that. One specific gap I had in mind was in use-case mapping, which is typically more related to product management.

Up Learn operates in a Dual Leadership format, meaning PM and TL should self-manage with minimum boundaries between those roles. As a result, even if I had the answer, simply voicing it wouldn’t solve anything, as I’d have to communicate that effectively to the PM.

Instead, I took the time to dig into most bugs that hit production, grouping them on a two key dimensions:

How impactful was the problem? (Red-Amber-Green)
At which point in our process did we expect to see this come up?

By bringing that up, there was now some data backing the argument that something should change around product discovery. Best of all, there was no friction around this, it was data, and it was auditable! There’s also some degree of subjectivity here - the one who chose and applied the labels was myself - so it’s crucial to be open (and again, truly vulnerable) every step of the way when presenting it. After all we can still fall victim to our own biases.

This led to some important reflection, and in the process I also learned of a few gaps I didn’t pay enough attention to - such as our QA process.

Know when to make exceptions

There are scenarios where hacky code is actually alright. For example if the feature/improvement is ~~actually~~ temporary (eg. to validate a PoC) or when the code doesn’t need to be maintained at all - it’s rare, but will sometimes happen. Squads need the ability to validate things quickly

without that, product improvement will be slower. Experimentation that can lead to pivots and improvements also gets inhibited.

It’s ok to consider shipping a prototype in that case. By this loose use of the term I mean a temporary feature meant to be discarded, potentially in favor of a better solution. Such cases are piecemeal - identifying them is a skill a tech lead should develop.

It’s natural (and expected) for PMs to change their minds. As grug puts it:

project managers mind like butterfly at times overworked and dealing with many grugs

However, prototypes can’t become actively maintained features as the code is not suited for that. That’ll backfire on the attempt, leading to major frustration, missed goals and bad-quality code. You must be extra sure that a prototype is the way to go. This requires special foresight and alignment - the rework and disposal of the code must be crystal clear to your PM, team, stakeholders and manager.

We found effective (and stupid simple) mechanisms to minimize rework by ensuring our releases are forwards-compatible. The key is to investigate the future - constraints, risks and unknowns - by borrowing context from your PM.

As an exercise, have him describe how the feature should behave 2 or 3 iterations ahead. That alone should uncover hidden expectations and constraints. You can then follow up with questions like “How long should it stay on?”, “How do we know when it’s time to roll back?” or “What happens once we validate this?” to expand your own context and make a more confident decision.

As always, if you face resistance, help him understand your concern and the impact of the wrong technical choice at present moment. Also worth reminding that earlier changes are cheaper changes. In my experience, once this process became familiar and releases went smoother, it just became second nature.

You will fuck up big time

Everything said so far sounds very easy in theory. In reality, your squad only ever pick the best decisions with the best available information. Keep this in mind to avoid stopping the team on its tracks. Remember:

Your feelings impact the team

If fucking up knocks you down, it will damage the team morale. This is usually worse than the original crisis itself. Instead, acknowledge the fuck-up and steer the team through this crisis as an opportunity to grow. Try prompting a conversation with something like:

“Team, this plan isn’t working. The project is stretching way beyond budget and everyone is exhausted. I thought we were making the right calls, so my apologies for that. I know we can do better than this, but we’ll need everyone’s input to find a better plan. How can we salvage this project? ”

That alone could turn a glooming disaster into a precious team-building experience. You may find that people are actually quite keen to help once given the chance. Feeling heard and being a part of something bigger promotes a sense of meaning which will usually lead a team to spontaneous, fruitful cooperation. This does however require a soft skillset not everyone has developed yet: being vulnerable, listening without judging, accepting (and sponsoring) other’s opinions and knowing when (and how) to step in.

Everything will feel very clunky at first

That’s normal. Learning a new skill is awkward by itself. For extra challenge, a new Tech Lead often needs to birth a squad, and the first stages in a squad lifecycle (Forming, Storming, Norming) are also awkward by themselves. A few things need to happen:

You must get used to running the calls and learn to prepare things in advance.

It helps to have an agenda for everything and relying on it. It becomes painfull evident for a tech lead just how limited our memory is The last thing you want to happen is to forget some key agenda item on a long meeting. It made a huge difference to align agendas with the whole team, and use their feedback to streamline that process For me that was the green light I needed to sit at the pilot seat.

The team must get used to trust, communication and self-management.

That will actually lift weight off your shoulders and allow you to focus on steering the team with less effort. The good news is that Enlighten has already reached this point (after some 6mo). When that happens, you’ll feel a noticeable click - teammates will spontaneously jump in on tasks, propose improvements and run delegated proceses, so long as the squad priorities remain clear.

You must get used to giving the final word.

If you’re like me, you’ll try your best for a democratic decision always. While usually the best outcome, analysis paralysis is a thin and people sometimes get stuck. It’s your job to notice when that happens, and to propose a way forwards, even if not 100%. As the TL, it’s usually enough to propose something. People will respect and trust you enough to follow your lead. Plus, so long as you ensure everyone feels heard (and propose to revisit a decision in the future), reasonable people will buy into the team’s decision. It’s usually better to have some direction, even if not ideal, than not having it at all.

Closing word

Leadership is a very engrossing experience to go through. It’ll throw back at you every personal shortcoming and give you tons of material to grow from. The flipside is: it’ll often be stressful. Is it worth it?

Well consider this: there are hurdles to go through. Personal development, team storming, establishing processes, managing crises - these are all painful to go through. But once you get through it, the squad will start managing itself, making calls will feel less daunting, creating processes will feel more natural and crises become opportunities to learn.

The skills you’ll learn will forever improve your performance as an engineer, lead, workmate and individual. And it really does get better, and you do feel a huge sense of accomplishment from watching what your team achieves. Just keep in mind the Jogging Baboon mantra:

It gets easier. Every day it gets a little easier.
But you gotta do it every day - that’s the hard part.
But it does get easier.

References

For you fellow newcomer, I hope this has been useful, and to wrap this up, here are some links to content I found enormously helpful through the journey - from purely technical to purely managerial content. Have fun!!

Books

Resilient Management by Lara Hogan,
Talking to Tech Leads by Patrick Kua and
Turn the Ship Around by L. David Marquet

Podcasts

Posts