Categories
Tech Leadership

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!


Categories
Tech Leadership

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 👍

Categories
Tech Leadership

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 👍

Categories
Uncategorized

What to do with the Swift REPL “NameError: name ‘run_one_line’ is not defined” error

I was playing around with Swift this weekend. Every time I started the REPL (whether version 3x or 4x of Swift) I got a whole bunch of errors that look like this:

The REPL would work fine, but you know…. it was really, really, really, really annoying having to look at that error. All 100+ times it got repeated.

Turns out that the Swift REPL depends on a Python library called six. You may be able to quickly install it using this command:

Problem solved……?

Good luck out there!

 

Categories
Modern Enterprise Code

So much Hello, World!

Today I listened in on a few tech screens with some Java developers. The experience made me want to crack open Exercism. Exercism is an amazing platform to write some code and get some feedback.

So here’s a collection of various people’s ways to say Hello World from the first Java exercise.

Here’s another one:

Ok, that one was clearly wrong. Here’s another one:

And another one, which I rather like for its thoughtfulness:

Another one:

And this:

And this one with some dependencies:

Yet another:

Those are just some examples from the past few days. Some I like, some I don’t; some are more efficient, some are not. My only point in this post is to just highlight that, even in a simple hello, world example, there are many different approaches.

Categories
Uncategorized

Monday Motivation

“To put away aimlessness and weakness, and to begin to think with purpose, is to enter the ranks of those strong ones who only recognize failure as one of the pathways to attainment; who make all conditions serve them, and who think strongly, attempt fearlessly, and accomplish masterfully.”

Categories
Tech Leadership

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!

Categories
Tech Leadership

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.

Categories
Management

Everything you will ever do as a leader is based on one audacious assumption. It’s the assumption that you matter. Before you can lead others, you have to lead yourself and believe that you can have a positive impact on others. You have to believe that your words can inspire and your actions can move others. You have to believe that what you do counts for something. If you don’t, you won’t even try. Leadership begins with you.

-The Truth About Leadership

Categories
Consulting

Short projects are hard

Short projects are much harder than long ones. I’m talking about super short development projects, like four weeks plus or minus a few. First, software engineering is almost always harder than everyone thinks, but in a small project everyone assumes that it’s going to be easy. It never is, is it?

Second, the amount of time you have to establish credibility compresses so tightly that it’s easy to completely blow it in just a few days. Trust and credibility usually take time to develop, but if the project only lasts four weeks and you have a bad demo on Tuesday of week two, you may never recover your credibility before the project ends.

Third, nobody takes the time to analyze everything. Realistically, few will invest much more than a few hours to scope out a project that’s only going to last a few weeks, so they build in a lot of assumptions to short cut the process.

Sure, big projects have a lot more on the line, more eyes, and more pressure. But in a long project, there’s time to absorb some of the inherent risk in all software engineering projects and time to build credibility or restore it from a few missteps and the stakeholders usually invest a lot more analysis into it. Short projects are white knuckled with none of these luxuries.

What to do about it

Only use senior engineers who have demonstrated tech leadership abilities. Don’t even try this with a junior engineer who’s still learning — even if it costs a lot more. You’re probably doing short project because you’re hoping to get follow on work, so don’t blow it by trying to turn a profit on this one; make it up on the backside (hopefully).

Raise the risk before you agree to do it. This is hard because clients are likely to be dismissive and you’re struggling to build credibility. They might tell you it’s just going to take a week. But if you remind them that software development is hard, they usually agree to add some buffer. This is software engineering, and one week can turn into eight. Bigly. Mature clients know it.

Ditch the traditional agile processes and two sprint timelines. Be truly agile in your delivery not your processes. Invest more into management and project oversight time than you would on a short project. One or two day sprints if you must follow the process.

Build credibility with the client by demoing as often as possible but at least a few times per week. Daily if you can. Nothing to demo? Demo code. Lots of demos gives you the ability to course correct and build credibility quickly when the inevitable issue comes up.

Offset some of the risk by increasing stakeholder involvement. Stakeholders might be tempted to be dismissive of of their need to be involved in a short-term project. Make them show up to demos or suspend your work if they claim they’re too busy.

What to do if you get off track

Communicate, but do it at a detailed, code level. Remember, even when you’re off track, you’re still trying to use every minute to build credibility and trust with the client — and you need them to support you for more time.

What do you think? How do manage short projects? Did I miss anything? Leave me a comment or hit me up on Twitter @michaelrice.