NONLINEAR. Pedro Álvarez-Tabío

Things I wish I'd known when I became a tech lead

For the last few months, I've had the great honor of becoming a de facto tech lead for a new project at HERE Connected Driving. That is, I have to act as one but I don't have the formal title nor experience. This has an additional difficulty. I can't grow a full beard and here I am acting as a tech lead, so I have to go the extra mile to prove my worth among teammates, managers and stakeholders.

By means of trial-and-error I finally grasped (in some cases the hard way, believe me) a thing or two what this is all about. If only someone would have grilled me with this advice, I wouldn't have had such a learning curve. But anyhow, you don't really get to know until you do.

Hire for smarts, more than experience.

One of the first things you will probably do as a tech lead (especially if you're starting a new project) is hiring. We all know things change every second in the software world, so I would recommend hiring someone adaptable who is willing to learn. A smart person. Of course, if you can find someone who, apart from being really smart is a subject expert, go for it. Many times however you will have to choose one or the other.

But – what is smart? A smart person is one that not only gets up to speed fast, but also relentlessly keeps getting better and better. If this developer you hired proposes new and imaginative solutions to problems while humbly listening to others' opinions, learns from other people as well as from her own experience, you've found an A-player. Congrats!

Always probe for intelligence, communication abilities and learning speed. You will see the difference in the end – plus it's way more rewarding to help someone unleash their potential than to just tell them to use their current abilities. [1]

Help your people get up to speed as quick as possible.

OK, so you already have your developers who absorb everything really quick. Now it's your turn to make sure they get your complete support in these crucial first stages. Mentor them, teach them how to use the tools, frameworks, etc. Be supportive and don't settle for "good enough for now". They'll be using this knowledge for (hopefully) a long time.

I must admit I wasn't excellent at this right after becoming tech lead. I would assume people would understand the inner details right away and if they didn't, I'd do it for them. That approach, for better or worse, doesn't scale. Your people need to have solid foundations on the project so they know how to apply their skills the most effective way. What's more, just one member of the team without the appropriate initial can make wrong assumptions about the project and make mistakes that can completely sink the whole team's performance.

First impressions are very important. Thoughtful architecture and code matters.

"I was expecting having to rebuild a dirty mess from the ground up but I'm impressed with this architecture"

– One of my teammates, right after joining

I remember at the beginning of my tenure as a tech lead that I was obsessed over making an architecture so well-thought that people who joined the team had a good first impression of me. This is an initial step in earning respect, you have to show that you're up to the task, especially when you're a first-timer. It turned out really well, in words of my super-smart teammate JC Guerrero.

Architecture and the code itself are two sides of the same coin. You set the bar – at the beginning, be as tight as you can with tests and code. Aim for as clean as you can possibly do. Doing my best at the beginning helped establish a benchmark. Don't get me wrong, when a feature is delayed and needs to go through, test coverage and/or code quality suffers. This happens all the time. Encourage your folks and yourself to refactor everything so everyone's at the levels you set for the team. Carve out some time as you learn to push the bar even higher. It'll feel awesome.

NOTE: There is a narrow line between a well-thought-out architecture and overengineering. Think twice about the scope, size and even number of people in the project and align your architecture to it.

Document everything you do as a team.

And I'm not referring to the code. By documenting I mean keep track of all the things you do as a team. How do you do source control? Code reviews? Deployments? Testing? QA? I can't stress enough how useful this is for new people who join the team, or even external contributors from other teams who need to manually build your stuff. It reduces the up-to-speed overhead and helps everyone be on the same page. Last but not least, encourage everyone going through the docs to give back in the shape of corrections or troubleshooting steps for everyone's different environments.

This helps achieve one of the golden rules of docs – it is of extreme importance to keep them up to date. I know it's hard for a team to keep up with updating every single thing. It comes with the job, though. A trick that's worked fine for me is to put a fake meeting on my calendar every other week. Its title is "CHECK THE DOCS". Check the work that's been done, ask your team, and don't hesitate to step in if something needs to get fixed right away, and the one responsible for that is focused on other stuff. After all, you have to be the person who keeps the engine humming. You don't want expensive context switching from your developers.

Which links to one of the most important ones...

Maintain focus. Define clear goals for every team member.

I got burnt hard on this one. At the beginning I was so obsessed with keeping.

I found that clearly defining ownership, with clean interfaces between components is not only a sign of a good codebase, but it can also be applied to teams themselves.

In the end with the help of my teammates we cracked the people algorithm for this one:

  • Divide the app into components.
  • Assign an owner to a component. One developer can own, of course, more than one component.
  • Get a backup owner. Just so your bus factor is > 1.
  • Keep assigning that to every.

This, of course, can lead the team to turn into silos and no one really knows anything about the rest of, both feature- and code-wise. Silver bullets for this: code reviews and team demos. Make you and your folks review all parts of the codebase. Also encourage show-off on all those sweet new features!

[1] It's cheaper as well! (at least in the beginning). That leads to happier managers who spend less for more :)