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.

Junior developer’s work overwritten by a WordPress site. What would you do?

Belle is new software engineer trying to do awesomeness. Manager brings in a friend who overwrites her work with a simple WordPress site. Manager is ecstatic but Belle is disappointed and hurt. What would you do, tech lead?

Here are more facts:

  • It’s a volunteer organization and nobody’s getting paid
  • Belle suggested the new site that the manager’s friend (Steve) developed but also told the manager she didn’t have time to build it
  • Nevertheless she took the time to lay the groundwork with some Github repos, Jenkins build pipelines, etc.
  • She recommended a more robust architecture with some REST APIs and other industry standard practices; Steve didn’t know what Github was
  • The WordPress site that Steve built ignored all her recommendations and when he deployed it, all her work was destroyed
  • The manager is ecstatic about the WordPress site, declares Steve a great software engineer, and worst of all tells Belle “you can learn a lot from Steve”

I documented some of the more interesting community feedback in our new Tech Lead Workshops Discussion Boards. Many of the comments recommended technical or process based solutions; some were good, some were awful imho.

But my favorite comment was something like, for any situation you can either love it, change it, or leave it. I liked that a lot because I have a feeling, based on my own experience, that what Belle is really struggling with here is she feels devalued and disrespected. She feels powerless, like clumsy beach volleyball players trampeled all over her sand castle. Giving her those three choices might let her retake some of the power.

Belle feels her technical contributions are wrapped up in her own ego which is getting trampeled by a chumy relationship between Steve and the manager. What’s significant to her is, possibly, going to come across as mundane or tedious to the manager. She probably knows that instinctively and that adds to her powerlessness.

In this situation, she may have to step up and make her choice: love it, change it, or leave it because nobody else is going to do that for her.

And it got me thinking that, if there was a tech lead in this situation, and it was you, it may be your job to protect her work and make sure she feels valued — even if the manager still thinks Steve’s the hero.

By the way, this all came from a StackExchange post that I read on the flight to the East Coast today. Thought it was super interesting, but the mods disagreed and closed the thread. I swear, they do that to all the good ones….

So maybe the actual question is not the title of the post. Maybe it’s something more like, “Hey Tech Lead, how are you going to protect your team in this situation?

What do you think? What would you do? Continue the conversation on our discussion site.

Photo by Scott from Pexels

New tech lead discussion board

I know, I know — there’s like hardly any traffic here at all.

Right now I’m very much in the Field of Dreams mentality. I’ll have to step up my efforts to find some players to get on the field soon.

But in the meantime, late at night, I can work on the field. So I added a new feature that I think captures my real intent for Tech Lead Workshops better than some of my efforts to date.

So I set up a discussion board.

It make sense because my goal has always been about creating a safe space for tech leads to learn from each other. That was the plan for the LA Tech Lead Meetup and then Silicon Valley. But those geographically based, Meetup-bounded communities are growing a little more slowly than I hoped. So I’m trying to expand my footprint on the Internet at large.

Now, I was careful not to use something from my past, like phpBB or something — even though there seems to be active and vibrant development going on. I wanted something a little fresher looking and more responsive, so I went with Flarum and hosting by FreeFlarum.

So far I really like it, and I think you will too. Join the conversation at discuss.techleadworkshops.com.

It’s going to be very quiet there for quite some time, but I’ll try to keep it active. It’s at least a good scratch pad for ideas and half baked thoughts we might have about stuff.

Continue the discussion on the Hello, World post at the Tech Lead Workshop Discussion Boards.


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