Hey tech lead, do you know when to let go?

Short post tonight. It’s been a long day for me where the culmination of three months of work came to a head, right up until the final few hours.

I stopped at the hotel bar for a minute on the way to the room, as you do on a day like this.

A guy was next to me, and he ordered some kind of brown liquor neat. Then he watched the bartender carefully. Perhaps inevitably, she started to put ice in the drink. (You don’t put ice in a “neat” drink, just so we’re aligned.)

“Wait, Wait!” He called out in an unnecessarily loud voice across the entire bar. “Don’t you know what neat means?” Again, in an unnecessarily loud and now condescending voice — all the way across the bar.

She proceeded to make a new drink. No ice. No big deal. A conversation that could have waited for few moments.

Said bar patron gruffly accepted the drink and left muttering to his friend about the service.

I thought it was a good side car story for the day’s events, which I haven’t relayed to you in detail, but you’re a tech lead and you know deadline days. You’ve been there. Days like this are messy and chaotic. Many, including me sometimes, cling too tightly to results (as opposed to actions) we can’t control. So it was for me today.

In life, as in zen, you need to have absolute focus, commitment, and follow through on what you can control. But once you’ve done all you can, you need to let go. Let go of control and let go of the result. If you cling too tightly to the result after you’ve done all you can, well that’s the road to madness and cynicism.

I’m a huge advocate of the idea that you can control or influence more than most people think they can, but there’s a point where that influence stops and you need to absolutely let go right there.

Whose vision are you driving in your tech leadership?

There. Are. So. Many. Opinions. In. Software.

As a tech lead, it often falls to you to set the direction or, at least, resolve a debate. When I was starting out as a tech lead, I had a hard time navigating all the opinions, debates about which turn nasty on Slack. (Ok, this was back in the IRC days.)

For example, one debate I always seemed to lose was trying to minimize as many dependencies as possible. E.g., “Guys. Can we not import yet another Apache Commons library?!?!” (I know I’m dating myself, and, unfortunately, yes they were all guys.) What is it with developers that they don’t want to write code anyway…? (There I go, sparking another debate I’m going to lose.)

There are still so many opinions in software development (and in life), but age and experience taught me that they only way to really do this is to listen more closely to what I believe is the right direction and to be slow to adopt the other opinions. (Not resistant, just cautious.) It helps with step one of my tech leadership framework.

A couple of quotes came across my inbox today illustrating the principle. First from Howard Thurman:

There is something in every one of you that waits and listens for the sound of the genuine in yourself. It is the only true guide you will ever have. And if you cannot hear it, you will all of your life spend your days on the ends of strings that somebody else pulls.

What direction are you getting pulled in? Is the pull from the inside or the outside? Product management that won’t give you time for tech debt? Software engineers who don’t want to participate in code reviews? Design decisions you regret?

Maybe Warren Buffett’s quote will have more traction than Thurman’s:

The big question about how people behave is whether they’ve got an Inner Scorecard or an Outer Scorecard. It helps if you can be satisfied with an Inner Scorecard. I always pose it this way, I say: “Lookit. Would you rather be the world’s greatest lover, but have everyone think you’re the world’s worst lover? Or would you rather be the world’s worst lover but have everyone think you’re the world’s greatest lover? Now that is an interesting question.”

So what choice would you make? What choices are you making?

Photo by Richard Nolan on Unsplash

Improve developer tooling and develop tech leadership

For the newbie, wannabe tech leads out there, there’s a nice, compact thread on Stackexchange about what a developer can do to improve tooling and workflow in the team.

The original poster cites a few (stinky) smells in the environment: no tests, no automated build process, git commits straight to master, no style guides, no bug tracking, non-agile processes, etc., which “demotivates” him because it encourages bad practices in the team.

Here’s the interesting part — the seed of tech leadership –the poster wants to drive good change, and he’s had some success. He’s made suggestions and at one point the team actually started some tentative steps into agile (vis-a-vis some standups), but the suggestions don’t really “take.”

The accepted ✅ answer recommends moving

in moderate steps. You could start with the small changes, like using branches in your development for better integration and testing. This will eventually have its benefits, which will serve you as better evidence to support such “official” changes in the company.

It seems normal and reasonable, but I don’t like it because engineers place way too much reliance on technical benefits, assuming the technical points sell themselves. Why is that a mistaken assumption? Because technical “benefits” live solely in the eye of the beholder. They aren’t nearly as objective as we believe.

For example, I’ve met leads who strongly believe all git commits should go straight to master despite my belief and experience that branching methods like gitflow are “obviously” better. We’re both technologists, yet we see different benefits, different aesthetics.

So, may I suggest that my three step tech lead approach is super useful for in this very situation. Instead of simply seeing an approach you like and trying to sell it based on what you like, first focus on clarifying the vision — how will a formal git branching strategy align to the team’s goals for agility, stability, excellence, or whatever?

Second, walk around and work with each team member to make sure the vision connects with them individually. This might have to happen more than once.

Finally, people drift. They might initially like the vision and say they buy into it, but real life gets in the way. So, third, you’re going to have to continually monitor alignment and course correct — how well are they actually following the branching strategy? Are they seeing the benefits? Is the vision becoming real? If not, fix it.

My framework is labor intensive. It burns calories. But it works. And it’s the stuff that strong leads are made out of. Use it.

(By the way, I’m not just trolling on Stackexchange. Will suggest an answer on Stackexchange too.)

To be a tech lead, you need to be influential. What does that mean??

The truth is, I’m not sure yet. But I have some ideas.

Anything you do in your role as a tech lead requires influence, from the grand to the mundane.

If you want an engineer to take on a task or user story, that takes influence. If you want to convince your engineering management that time needs to be carved out to handle tech debt next sprint, that takes influence. If you’ve got an underperforming engineer who you know can do more, that definitely takes influence.

I have a general purpose model or framework for tech leadership that works in most situations no matter whether they’re big or small. But the effectiveness of the model will rise or fall on your own personal influence.

The center of gravity for “influence” is your ability to communicate effectively within the context. (Notice there are two parts to that: effectiveness and contetx.) The tech lead model will organize your thoughts and strategies, but if you can’t communicate those thoughts and strategies effectively within the context then every model will fail you.

Communication is hard for techies, but it seems like it’s job one to be influential. Let’s start talking about it.

Photo by Diz Play on Unsplash

Tech leads: Build real relationships at work

I was in a great, simple example of team building yesterday. Even though many of us have worked together for some time, we went around the room and explained where we grew up, how we ended up at the company, what about the company’s culture mattered to us, and basically told each other a lot about who we were.

It risked being tedious, but when people actually open up then I feel like we made a ton of progress in jelling the team. People opened up because it was being led by a leader (two leaders, actually) who in fact wanted to hear the stories and get to know his or her people – not merely their roles, or titles, or performance in those things – but actually get to know them as individual human beings.

Most remarkable was the effect it had on the director who called the session. When we finished, you could see on his face and hear in his words how getting to know the stories made his burden as a lead heavier. His tone became more reverent; he seemed to resolve to make this task we’re working on successful not just for the company but for us as individuals.

Sometimes I think managers don’t take this step and don’t engage in this deeper understanding of the team because they know, instinctively, that it will raise the stakes on their leadership.

It’s one thing to fail yourself or even cause the company to lose money, but when you’re aware that Swetha could have to go home to tell her second grader that she lost her job because the team failed – now you’re playing a different game.

I just thought today was a clean example of a leader who didn’t shy away from it.

What are you doing as a tech lead to get to know your people and their families? Are you embracing it, as my director did, or shying away from it?

Don’t just check the box ✅

The box on the code review tool? Check. ✅

One on one with your team? Went to lunch, avoided tough issues. But check. ✅

That Trello card? The build passed, so check. ✅

The other night, I was helping my second grader with her math homework. Problems like, “Johnny had 39 fruits in his basket, 5 were strawberries, 10 were grapes, and the rest were blueberries. How many blueberries did he have?”

In class, she learned some efficient “strategies” for recognizing the problem and setting it up. It was quick, effective, and dead on right. (For example, add 5 and 10 and then subtract the result from 39.) They’re good strategies.

But I was encouraging her to try to understand the concepts a little better than simply applying pattern recognition and then raw compute power. Computers can do that better than she can and always will.

That’s the way to separate herself from the machines and her classmates. I don’t care what grades she gets or how fast she can calculate numbers. I want her to ask more questions about it, to bring more curiosity to the problems because, frankly, that’s what makes humans so wonderful when they work.

But she just wants to get on with the task because she’s little and there are other things she’d rather be doing. I understand. But really, what could we be doing that’s better than bringing all our curiosity into our work?

I love to use code review as examples where check the box behavior is notorious in our roles as tech leads. They’re such powerful ways to bring a team together, but they also consume time and risk contention within the team when you get together online to do them. As a result, it’s tempting to use some automated tool like Crucible to literally “check a box” and say, “See? I run code reviews.” But don’t do just that.


My core, day to day, general purpose, prescriptive tech lead framework

There are a million things that make up good leadership. You can read all day and all night for years about leadership. But you’re not going to find much that’s pratical and useful for tech leads like you who are on the ground, in the trenches.

So back in September, I wanted to describe a prescriptive, general purpose framework that any tech lead can fall back on in a pinch based on what I’ve tried and observed over the past few decades. I wanted something that, no matter what situation you’re in, no matter how contentious or ambiguous, you could whip it out, and lead through any situation instead of just reacting and “managing” through it.

It’s as basic as basic can be:

First, CAPTURE AND ARTICULATE A VISION. If leadership requires followership to exist, then your followers need to have somewhere to go. Give them some specific place, future state, vision. It’s true that followers will often follow charisma or titles, but didn’t you want something more substantive when you were the follower?

This is the step where you’re going to define it.

Task one is to capture a vision. I chose the word “capture” carefully because it encompasses lots of activities or strategies you might employ to define a vision. You could capture it through a conversation, a consensus with the team. You could capture it by invoking and adapting the vision of senior management or the client to your situation. You could do it by fiat (i.e., you just define and declare it and expect everyone to fall in line, which could work in some situations). Whatever your technique, capturing the vision means you know what it is and you’ve made it crisp and compelling to everyone else.

Second, EVANGELIZE THE VISION. Back in the early 2000s, on the back of the lanyard badge I needed to get to in to work, my employer wrote a mission statement. It was corporate speak that meant absolutely nothing to me, and if anything, made me feel even more disconnected from the company because I didn’t buy into the abstract values on that thing I was required to wear everyday.

And likewise, for you as a tech lead, simply stating it or capturing it isn’t sufficient and could create a disconnect if you skip this step.

You’re going to have to walk around, meet individually with everyone (formally or informally) on your team and every key stakeholder to make sure they buy into the vision by — most importantly –taking the time to connect the vision to their work and to their own human motivations. This takes time and calories. Almost everyone overlooks it, including me, because it’s hard, frustrating, and time consuming.

But if you skip this step then how do you know if anyone bought into the vision? You might end up thinking you’re a leader, when in fact you’re simply taking a walk alone around the block with nobody following you. You might be in good company with other mediocre tech leads in this regard, but you’re not leading.

Finally, COACH AND CONNECT. Number one and two are one-time activities. This is the daily activity that you need to do to make sure the day to day work, the day to day builds are aligning to the vision. People will drift. Visions will drift. Memories fade. It’s your job to stay close to every team member and every stake holder to make sure everyone stays aligned.

So there. That’s the basic, everyday framework. It doesn’t teach you everything you need to know, and it doesn’t mean you’re doing the right things. It’s just the basic blocking and tackling of tech leads that can take their team from “A” to “B.”

Use it and let me know how it goes!!

Photo by Tim Gouw on Unsplash