Making a difference as a Tech Lead

Recently, I interviewed a candidate who asked me what I did (as a Technical Lead at my company). The question slightly caught me off guard. I, of course, answered the question but not with as much vigor and energy as I usually do. However, the question has rolled around in my head since that day. I've also been itching to begin posting my thoughts on here as I continue to evolve. This quickly became a candidate; and so here I am.

The question I want to answer is not so much about what I personally do as a tech lead, or what the industry's definition of one is. In fact, I believe that the role is just as fuzzy as those roles in architecture. No, the question I want to answer is how you can make a difference as a tech lead.

In most cases, your responsibilities as a tech lead involves delivery of software, code quality, team efficacy, road block resolution, mentoring, work planning, architecture, presentations, demos, support...tell me when to stop. Let's just agree for the time being that it's a lot.

This post is also not meant to provide you with a "how-to" list. Instead, my focus is to provide you with how to frame your mind and how you may approach taking the next steps of making a difference.

Temporal Magic

That's right. You need to become a magician that can pull time out of a hat. If you care about making a difference, you have to make time for those around you. This could be any member of your team, or even those outside. The thing that's scary about being a tech lead is that it will seem like there aren't enough hours in the day to do everything. Then, it snowballs into the following day, etc.

The point here is that you hold the role of a leader. It's in the name, and it easily infers that you're leading people. Make time for them. Trust me, those people will know how busy you are. Maybe not down to the details, or right away, but they'll know. Making time for them shows them that they, and their tasks are important to you. Needless to say, those you make feel important will most likely be the ones that will follow you into battle.

Let It Go

Yes, now I'm singing the song in my head. But, it really can't get any clearer than that. It's somewhat of a paradox, really. You have to let go of some of the things that you did, perhaps exceptionally well, as you slide into this role. You might've been a rockin' developer who can slip your headphones on and code 8 hours a day and just produce. Give your headphones away, you won't need them anymore.

Coding? Well, this one's a tricky one. I have a separate point on this later but for now, I'm mostly talking about those days when your life was simple and you can just pick up a story from the sprint backlog and hit the cruise button. Life is not simple as a tech lead; embrace it. It's not a bad thing but it's also an aspect that makes this role not a fit for every developer.

Returning to the core point, I tried to be careful of saying "some of the things". That's because, the things you're letting go are the things that are inward-facing or selfish. You'll certainly want to retain those outward qualities such as leadership, communication, empathy, etc.

Don't Be A Blocker

Oh my goodness, this is one of the most important ones, in my opinion. It sounds so easy, and borderline cliche. In fact, in a podcast that I listened about being a tech lead, this phrase was mentioned. It's probably mentioned in many other places.

What does this really mean? Well, it means, don't put yourself in a position to be a blocker; emphasis on the preemptive inference that I'm making. Don't pick up stories from your backlog that you can't complete. In fact, don't pick up any stories at all - that's no longer your job.

Besides the obvious, why is this so important? Well, imagine your a class (for those of you still living in OO), or a recursive function (for those of you who have found beauty in functional programming), and you're about to get instantiated (I'll just stick to the "class" example) and your method is about to get invoked:

var techLead = new Me(); techLead.PerformDuties();

Now, as a single instance, you have capacity to take on work (let's just say your team agreement states that's okay). Fine, everything's fine. However, what if this happens:

var techLead1 = new Me(); var techLead2 = new Me();

Not so much capacity now. When this happens, and you successfully get through it, you will wonder what you ever did when you were only running one team, or when your team was still half the size.

To me, this is important because of the mentality of the role that it invokes. In most cases, this might not be you but if you force yourself, just for a minute, to imagine if you started running another team, or if your team size doubled - would you succeed and stay above water? If so, imagine what things you would change to be successful. Now, jump back into reality and apply those things.

And if all goes well, you may now have "extra" time on your hands that you can spend on the people that matters most to you.

This post seems long enough for now. I'll continue this series but if it's helpful, I can provide more concrete examples.

jgo