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.)

Communication problems in engineering teams

An engineering manager asks Stackexchange for help with his “socially awkward” team and gets skewered by the community. It goes to the heart of managing and leading engineering teams, so let’s dig in.

This lack of social skill creates a few problems from the manager’s point of view:

  • won’t participate in company social events,
  • won’t communicate with other teams,
  • rely too much on tools like Slack to communicate, and
  • not reaching out for details on bug reports.

It seemed like a reasonable point of view and like a set of problems I have lots of personal experience with, especially in an agile world where communication skills are super valuable. The community largely disagreed.

First, they disagreed with the premise that the team lacks social skill. They have good advice for you as a tech lead: before you make a judgment that a team or person “lacks social skill,” consider whether they just have a different communication skillsets or techniques than you do. People who become managers often do so because their communication techniques more closely match traditional business norms, so you might have a blind spot.

Second, always remember that you probably preferred lots of time to concentrate and work when you were in their spot. As a tech lead, you’re starting to move into the world of humans that coordinate and progress by randomly bumping into each other in meetings. As you get used to this, you’re going to forget how important focus time is and why asychronous techniques like Slack and email are highly valued.

Third, remember that, as a leader of an engineering team, your product is that now the team’s effectiveness. They’re there to solve problems creatively, which takes focus, concentration, and a unique kind of coordination — forcing them to socialize in ways that match the company’s techniques but not the team’s preferred methods will undermine the quality of your product.

As one poster pointedly said:

Just because your boss [declared the team ineffective because they’re socially awkward] doesn’t mean the criticisms are valid. You now have an opportunity to back up your team and support their best interests, advocating for them and the way in which they work best. As their manager, that is your job, not parroting whatever your boss (who is even more removed from the developer world) has come up with next.

I know you know all these things, but I thought the thread (which is very long and raises a lot more good points than I did above) was an awesome illustration of how engineering teams need to be protected and nurtured, especially in companies that don’t understand the culture.

That said, I think the posters focused too much on criticizing the premise of the question and didn’t do enough to acknowledge how critical good communication techniques are. But still, it was a valuable discussion!

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.


So I went to the California DMV today

I defy you to get yourself juiced up on motivation. Buy a Toxin Flush from Nekter, put your noise cancelling headphones on, and listen to Tony Robbins or Les Brown or Zig Ziglar at full volume for three hours straight. Now spend 45 minutes in a California Department of Motor Vehicles office near South Central LA where I was today and just try to maintain your Robbins’ attitude. Just try.

You simply cannot do it. I’m not one to set limits, but you cannot maintain a positive attitude in that environment. Full stop. Period.

As you’re already exquisitively aware, the DMV is a beaurocratic machine finely tuned to suck every last bit of essence from your humanity. Sure the workers are pleasant and patient as they can be, but that just makes them more effective at their soul crushing task. You will walk out compliant and defeated.

Before I left for the DMV this morning, interestingly, I was reading a transcript from an internal interview on software engineering effectiveness and happiness. They cited last year’s paper On the Unhappiness of Software Developers.

One possible summary of that paper is that developers are unhappy in their jobs because of other people. They feel burdened by other peoples’ code, processes, meetings, personalities, etc., etc. They feel they lack the persuasive capability to influence other people and be the creative force that crafting code promises.

In my current role, I get to drop in on dozens of engineering and IT environments throughout the year, and I can feel it. It’s palpable almost everywhere.

The DMV is an extreme example, but it’s a useful bedrock baseline. At the DMV, you have zero power to influence anyone or anything. Less than that maybe. The rules are written in stone and interpreted by someone behind the one way mirror in the “Control Room.” Their SEIU employees have forgotten more excuses than you could possibly stammer to produce on the spot, and you are simply required to comply with all these other people’s requirements.

Your team’s culture is an order of magnitude better than the DMV — surely. But how many orders of magnitude? More pointedly, to what extent, as a tech lead, are you leaning toward or away from the a DMV-like environment?

I’m honestly not sure if I made my point very well here (especially since it’s a subtle one), so please hit me up in the comments and we can continue the conversation!