Put Aside The Ranger

So you want to become (or have been told you now are) a technical team lead? Awesome, congratulations! You’re in for an excellent adventure. But if you’re wondering where to begin, and what’s going to change, lucky for you I’ve been there myself, helped several others through this transition, and have captured some lessons you can apply:

First, make sure everyone on the project knows you’re the technical lead. This isn’t about ego or power, it’s about clarity of function and accepting responsibility. With that comes the need to be responsive; availability for conversation is now part of your job.

Next, get to know the team personally and earn their trust though human connection. You cannot be everywhere all the time, so you need people who are comfortable coming to you with challenges both technical and otherwise. If there are folks involved external to your organization this is doubly-important. Identify a go-to person on that external team and engage with them regularly one-on-one.

Get to know the team professionally as well. What are each individual’s strengths and weaknesses? What technical skills do they have, and what parts of the system need those skills applied? What are their communication styles and ways of being motivated? Personalize your approach with everyone; it’s your role to put them where they can thrive, which in turn maximizes collective success.

Have a generalist mindset. Get to debugging level competency across the entire tech stack, no excuses. You don’t need to be the best at everything, in fact you shouldn’t be, but you should know what good looks like so you can ensure it’s happening.

There’s one area, though, where your knowledge should be unrivaled, and that is understanding your customer and the business case you are there to solve. Get familiar with their requirements and deadlines. Stay connected to your stakeholders, listen, ask questions, and then push their objectives down to the people in your charge. Once again, this is especially important if there are subcontractors who have a limited view of the big picture.

Make yourself present in meetings, erring on the side of being overly-present (especially at first). Requirements gathering session? You gotta be there. Sprint planning and backlog grooming? Not optional. But that deep dive on a bug or tricky technical problem? Maybe let your tech experts handle it, or at least have them gather the data and come to you if they run stuck or need a decision.

Speaking of decisions, apply wisdom to the ones you can delegate and ones you cannot. Specifics will vary project to project, but in general the more reversible a decision is, the less important it is you make it. Another rule of thumb: as soon as you know how to do something well, it’s time to teach someone else to do it, while you take up the next challenge no one else is equipped to solve. Fail at security and you fail full stop, so keep your eyes on anything that could jeopardize it.

High level architecture and technology choices will matter more in the long run than anything decided in a code review, so keep your nitpicks to yourself. Speaking of code reviews, their value mostly comes in peer to peer cross-checks. If you think you have to approve every line of code yourself, you’re doing it wrong. Treat your attention like the precious commodity it is.

Your good intentions of ensuring quality code and other deliverables won’t be enough. Establish quality mechanisms: automated linting and security scans. Automated testing. Continuous deployment. These are your eyes and ears, and more important for you to establish and monitor than you building features.

Take failure personally. Things will go wrong; the minute you blame those under your charge, you’ve lost. Instead, turn your gaze inward to what you could have done better. When you hold yourself to the highest standard, it calls others to do the same.

Finally, don’t stop listening and learning. Get feedback, even when it’s hard to hear, and act on it. Also, there’s tons more out there on being a tech lead, go do some searches and read up. Perhaps you’ll even (gasp) find counterpoints to my above arguments. That’s great! Ultimately you’re a technical lead to serve and empower, and that requires judgment on when to follow the rules and when to toss them and do what’s gotta be done, because no job is below you. Be the person who brings the coffee and donuts, orders the pizza, serves the drinks, and cleans the conference room afterwards.

Sound hard? It is. It’s gonna take a different set of skills and a significant amount of time. You’re going to have to let go of some things you’re used to doing and some things you’re good at (and probably enjoy doing) to find that time. But when a team you’ve led accomplishes more than you could ever do on your own it’s a unique kind of reward.