Repeat your vision often tech leads!

As leads, we almost always have the vision clearly in our heads–or we should. Our engineers probably do not.

You (hopefully) have all three of the components of a clear and compelling vision your head almost all the time–the what, the how, and the why. We are probably having conversations with managers or other stakeholders where you talk about the vision to constantly align the work with the rest of the company or the client’s needs.

If you are using effective tracking and adjusting behaviors, you have a pretty good idea of where each engineer or person on your team is against that vision or goal. You probably also talk about where the team is in terms of status against where you thought you need to be on the project plan, whatever form that takes for you.

Your engineers are not thinking about the vision as much as you are

Now, think back to when you were an engineer or individual contributor. What was your view of the world? It was probably something like the following.

You had a task or story to work on and you probably had a pretty good idea of how much work it was going to take and whether it was going to be on time.

You’re focused on trying to get all the pieces and parts to come together. Maybe you’re standing up an API or trying to integrate with one. You’re wiring up unit tests (hopefully). You’re flipping back and forth on git repos and branches, trying to get pull requests approved, and generally just trying to get stuff built.

You’re worried about whether your code is going to pass a code review or what your tech lead or other teammates are going to say about the choices, decisions, and code you’ve written. You’re balancing the need to get things done now with the need to do really high quality work and trying to keep track of the tech debt you’re incurring.

Oh, and if you’re a a junior developer, you might still be learning some fairly fundamental stuff and struggling with obscure things, like why your React component won’t render the data the way you thought it would. Maybe you’re spending a lot of time on Stackoverflow.

In short, as an individual contributor or engineer, you’re probably not thinking a lot about the vision for project and you might forget as you’re mired in all the details.

Beacuse of this, as a tech lead, it is YOUR responsibility to constantly remind the team WHAT, HOW, and WHY we are doing what we are doing, not the engineers’ responsibility.

Most importantly, it’s Taco Tuesday!

What do you think? Do you repeat the vision often?

It’s Monday, Tech Leads. Ugh. Focus on what you can control, not what you can’t

Mondays can be a little overwhelming, tech leads, especially when it’s also April 15, tax day, in America! I know. I get it. It’s Monday for me too.

Ugh.

Let’s spend a moment with the fact that it is tax day. You know what they say, the only things certain in life are death and taxes. Let’s drop in on that and consider: it doesn’t matter what you do to change the situation right now. You can call your Congressperson. You can campaign. You can lobby. You can call some talk show radio and run your mouth. But you cannot change how much money you have to cough up today. For those of you in high tax states like California, man…

Now let’s talk about your job and the fact that it’s Monday. As a tech lead, you’ve got a whole bunch of things happening, right? Maybe your sprint ends at the end of the week and your team is behind on story points. Maybe you’ve got an annoying meeting coming up with a product manager, and you’ve been dreading it. Maybe there are some budget cuts going on and you’re not sure what what’s going to happen to your project, team, or yourself.

Don’t sweat it!

You already know this: there’s no point at all in complaining about taxes, or complaining about your company, or complaining about your team, or really, even thinking about the fact that it’s Monday.

What is useful to think about right now is what you can control. One thing I like to do on Mondays, or really any day that I start feeling overwhelmed, is to start using my tracking and adjusting behaviors and start pinging the team. Get clarity on where things actually are. What can we do to fix it? Drill in and focus and look for details where you can make a change.

You can’t change the fact that your ops team won’t fix the flaky servers, for example. But you can talk to your team about how to code around it, at least for now. There is almost always a way, and if you focus on that instead of the problem, you can make this a great week.

Onward, tech leads!

Being a tech lead – Week 1

This week I’m going to try something different. I hope you’ll appreciate it. If you do or don’t, please send me some feedback or leave a comment below!

Trying Something Different: Consistency!

For a few years now I’ve been thinking a lot about the tech lead role. I’ve been publishing stuff here and there a haphazard way on various channels such as the Tech Lead Coaching Network Twitter account, Medium, my personal blog, LinkedIn, through podcasts on the Tech Lead Coaching Network, and I even hit publish on a How To Be A Tech Lead, a free book the weekend before last. 

For a while there, when I was at Red Hat, many were articles I wrote in a hotel bar eating a hamburger after long travel days. I think some of the stuff is pretty good and insightful. 

But so inconsistent. 

And that inconsistency is what I want to solve starting this week. Starting today, I’m going to start sending out content in a (relative compared to the past) organized way and be consistent about posting. Each week I’ll pick a general topic and try to stay with it for the week, posting on, primarily, LinkedIn and Twitter, since this seems to be where tech leads are likely to hang out.

Thankfully I can use tools like Buffer to get it all planned out the weekend before!

This Week’s Topic: Newbie Tech Leads

This week I’m going to spend some time introducing you to the tech lead role—focused primarily at newbie tech leads. I’m going to be talking about what the role is, whether you should really be getting into it or not, and what you should be focusing on in the early days of your tech leadership.

What is the tech lead role, anyway? There’s a lot of confusion in our industry about it. You can read more in my book, but a good way to understand it is the understand WHY managers need tech leads. Fundamentally, they simply cannot manage or lead all the fine grained details that come up, especially if the engineering managers are spread thin across multiple teams. That’s where you come in, but we’ll explore it in a lot more detail this week.

Should you be a tech lead? There are many good AND bad reasons why managers may come and tap you to be a tech lead. The question you need to ask yourself is whether you take on the role. This week, we’ll explore some reasons why you SHOUD NOT but we will also explore some reasons why you SHOULD. Spoiler alert: if the reasons are extrinsic rather than intrinsic, then they’re probably the wrong reasons.

What should you do in your early days? We’ll give you a some ideas about how to adjust to the new role. Probably the most important thing I can tell you, however, is that in the early days you’re leaving behind a lot of the success you had early in the role for an ambiguous, unclear role where you’ve got a lot to learn. Focus on the process of growing into the role rather than any results, especially in the early days of the role.

It’s gonna be a fun week, tech leads! Hope you find it useful. As we go, I’ll try to post links to everything that happened here so you can follow along.

A lot of this content is inspired by my new book, How To Be A Tech Lead. It’s free on Leanpub!


Wednesday Pod: Bring your whole self into the meeting and have a bigger impact!

When you’re the tech lead, all eyes (or ears) are on you. That’s one reason why they say leadership is visual.

Social animals, like humans, are hard wired to look at the leader a lot more often and pay a lot more attention to the leader’s non verbal signals and other emotional clues.

As if you didn’t need more to be nervous about!

Here you are, a new tech lead: you’ve trying to understand and articulate complex, sometimes abstract concepts; you’re trying to navigate the complexities of the personalities in the room; you’ve got deadline pressures; you might even have an adversarial client, product manager, or management in the room with; and now I’m telling you to somehow control the nonverbal signals you’re sending out?

Here’s the bad news: it’s very, very hard to control or manage your nonverbal signals. Trying to do so is actually a recipe for disaster.

The good news is there’s an easy hack. At 5:00 a.m. this morning, I published the third episode of the Tech Lead Coaching Network podcast where I give you an easy tech leadership hack.

(Spoiler alert: change your mindset going into the meeting and it will all fall into place for you.)

Subscribe on Apple Podcasts, Breaker, Anchor, and more 👍

Monday Pod: Tech Leadership Is a Bunch of Moments, Not a Role

Hit the publish button about an hour ago on my first Tech Lead Coaching Network daily podcast.

The idea that I tried to get across is that leadership is not so much a role or a title or playing golf with a bunch of caucasian, portly gentlemen.

Instead, it’s about noticing and stepping into key leadership moments. For example, what if you’re in a meeting where your engineering manager and product manager disagreed about how long a particular feature would take. Your engineering manager takes a fairly hard line and then walks out of the room with a hard stop on the meeting.

You’re left in the room with the irritated product manager and you could go up to the white board and try to start explaining it — a quintessential tech lead task. Will you step in to the moment?

Doesn’t really matter so much whether you do or don’t for whatever valid reasons you have — so long as you recognize the moments and show up in them.

Subscribe on Apple Podcasts, Breaker, Anchor, and more 👍

Bedrock Characteristics of an Effective Tech Lead

In the Truth About Leadership, James M. Kouzes and Barry Z. Posner offer no-nonsense, trend-free guidance that may help us nail down the bedrock characteristics for an effective tech lead. Kouzes and Posner surveyed 10,000+ people worldwide to uncover the key characteristics defining a good leader, traits that often come to mind when we think about leadership —  honesty, competence, fairness, supportiveness, courage, maturity, and so on.

Surprisingly, respondents consistently selected four characteristics far more often than the others: honesty (85%), forward looking (70%), enthusiasm (69%), and competence (64%).

Interestingly, intelligence, at only 42%, didn’t make the cut. We’re in the smart business, so we often try to lead with logic and intelligence. That’s clearly a mistake (and more than this survey prove it). So let’s dive deeper into what the authors think actually matters.

Basic Credibility Tech Leadership Traits: Honesty, Enthusiasm, Competence

Three of the traits work together to make us “credible” tech leads with the people on the team: honesty, enthusiasm, and competence. To drill in a bit, honesty is what you’d expect: telling the truth, having clear standards, and integrity. Enthusiasm (the authors actually called it “inspiring”) is also what you’d expect. “Energy signals commitment,” say the authors; we don’t follow those who aren’t committed.

Competence deserves some special discussion. The authors defined competence as the ability to get results from others. That feels like circular logic to me, and besides, in a dynamic field like software engineering, where there are too many posers, you need to possess a basic level of competence before people will follow you as a tech lead.

That’s not to see you have to be the mythical 10x engineer (in fact, being 10x might work against you), but need to spend some time in the trenches, enough to know whether the task you’re asking engineers to complete is trivial or Herculean and enough personal experience to know when you’re losing their interest and excitement.

The Tech Leadership Trait: A Forward Looking Vision

The key credibility traits (honesty, enthusiasm, and competence) are what we hope every software engineer on the team possess, right? So where’s the “leadership” piece? It turns out the trait that differentiates you as a tech lead is your ability to be forward looking.

Forward looking means more than just being able to see into the next sprint or around the next technical edge case. Being forward looking means you have a clear, long-term vision of the future of the product and team. You, with clarity, can envision how your team’s product, workflow, codebase, or culture could be better not just tomorrow but in the months to come. Clarity is key because a vague wish for something like “engineers doing more TDD” or “product owners writing better stories with better acceptance criteria” isn’t clear enough for the team to truly rally around, other than to complain during lunch at Chipotle.

Additionally, true tech leaders have an ability to map their vision to their team member’s hopes, goals, skills, and immediate aspirations. It’s easy to be a whiteboard visionary; it’s a whole other level to be able to clearly connect your vision to the day to day hopes, goals, and general work patterns of your team.

A word of caution. While your forward thinking vision is the big differentiator that separates you from being a highly competent team member, you can’t lose sight of the core credibility traits. No matter how compelling your vision, nobody on your engineering team will follow you if you aren’t credible. If you focus too much on “vision” and lose your grounding in credibility, you’re going to lose a big part of what makes you effective in the first place.

Be credible first, forward thinking second.

You’re Probably Demonstrating Strong Tech Lead Traits Already

I want to propose to you that, if you’ve made it this far into this post, you’re probably already modeling some or all of the key traits we just talked about. For example, you’re probably already honest in the sense that you have high standards for performance and integrity about the quality of your code and the results you and your team are producing. Odds are that you’re competent and enthusiastic about the future for your team and what you’re doing together.

Not only are you modeling many (or all) of them now, you probably notice that the traits Kouzes and Posner identified come more naturally to you than less valuable traits requiring stronger people skills, like supportiveness (31%), caring (20%), or maturity (16%), which are skills we tend to associate with authority figures. Even some of the traits we associate with strong leaders, such as ambitious (26%), courageous (21%), and independent (6%) were near the end of the list.

So relax about the mysterious or complicated stuff you read out there about leadership. As a tech lead (or an aspiring one), you’re probably in awesome shape already — so keep on doing what works!

Monday Motivation. An Open Letter

Dear consultants and engineers,

Last week was not a good week for me. So this morning I feel like writing you an (open) letter to talk about my expectations and my aspirations for our week together.

Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to to, let us concentrate rather on explaining to human beings what we want a computer to do. – Donald Knuth

Code is our currency. It is what we are paid to do, no matter what level you’re working on it: if you’re one of my architects, you’re thinking at high levels how big components of code work together. If you’re one of my junior consultants, you’re probably banging your head against some legacy API and worrying whether you can get your story done.

Coding is a deeply analytical activity. It requires that we sit (or stand) still for long periods of time to read, think, prototype with a REPL, wait for build servers, read stories, so on and so on. That’s what we do, and you usually do it in isolation. You’re here because you’re good at it and my expectation is that you take pride but be humble.

Now here’s my aspiration for the week (no matter what level you’re at): increase your energy level, shake off impostor syndrome, and get social about your code.

  • Ask people sitting next to you to pair up for a few minutes.
  • If someone asks you a question, sit down with them and crack open the code.
  • If you’re trying to explain status, throw some code up on the screen.
  • Call a code review for a hard problem you’re working on.
  • Show off something you’re proud of.
  • Talk through a new pattern you found in the open source world from your side project (if you have the time to have one, no problem if you don’t).
  • Can’t find a meeting room? Invite some team members to lunch. Print out the code if you have to (remember what printers are?).
  • Working remote? Get on a video call and have lunch together and screen share.

And don’t just share some gist on Slack. I know that’s more effecient, but it’s not effective and it’s not accomplishing what I want. Read on for why.

Warning: you’re probably going to have to boost your energy level to do this — I know — but it’s worth it. After writing or staring at the computer for hours, you might not feel like you’ve got the energy to get up, walk around, interrupt other people, and engage. Most of us barely have the energy to make it through the day, I know. But what’s interesting is that if you spend energy, you actually get more of it. And by investing the energy in your team or your company, they get more too. It all starts with you, and you’ll be well on your way to leadership by these small acts.

By the way, if you feel unsupported by anyone on the team or in the organization, I want to know right away.

Make it a great week folks and let me know how the social thing works out for you.