Are you micromanaging? How do you know?

Check your intentions – know who you’re talking to

The other day, I was telling someone that I really love to be a “hands on” kind of manager or leader.

The next question was, “well, that’s great but how do you know if you’re crossing the line from ‘hands on’ to micromanaging?”

That’s an insightful question. And I’m working up an email post for my subscribers on the topic this weekend, but here are some broad strokes.

First, check your intention before having a conversation that might cross that fine line from being really “hands on” to being really annoying. If you’re walking into a conversation from a mental place where you need something from someone or have an insecure need to control what a person is doing, this should be a red flag for you. The person receiving the communication will almost surely pick up on your subconscious feelings.

Second, you need to have done the hard work of really hearing and seeing the people on your team. That way you’ll know the subtle cues and the way that people like to be engaged. For example, understandably, a lot of software engineers don’t like being engaged when they’re deep in the code. Others are able to context switch more easily. So knowing them means you’ll know the right time to engage.

Photo by Nappy on Pexels.

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 👍

Working with IPFS locally, did you hit the “no ‘Access-Control-Allow-Origin'” error?

So did I. 

If you’re doing decentralized application development, eventually you’re probably going to want to play around with the Inter Planetary File System (“IPFS”) because you simply can’t (and don’t want to) store too much data on the blockchain. 

My problem came up when I was doing some local development with a local node and a local React application.  I wanted to connect to the local instance of IPFS daemon using something like the following code from my React app (edited a little to simplify):

Of course, when I tried to run it, I hit the dreaded cross site security issue that CORS was developed to help with.  It’s pretty generic and not at all unique to IPFS.

Surprisingly, there isn’t too much written on the web on how to resolve this.  Simply disabling the browser’s security didn’t work because the IPFS local endpoint was configured to reject the cross-site request.

Long story short, all you have to do is change the local IPFS configuration. Start by editing your config file by using something like the following:

Now change the “API” section of the config file to look something like the following:

Restart your IPFS daemon and you should be good to go. 

Good luck out there and let me know how it goes for you!

The Solidity “out of gas” error… you’re probably not really out of gas

This is my first week at OpenLaw, a Consensys spoke, where I get to not only do a little legal work as a legal engineer but also get to do some blockchain engineering, especially Solidity development.  I’m currently working on version 0.4.24.

But as you probably know if you dabble in Solidity, it’s still early days and a challenging platform compared to more mature languages! 

For example, for a few hours this afternoon I was absolutely flummoxed with the following error when running my Truffle tests:

So I diligently checked my Ganache settings and tried to change the gas settings on my Truffle transactions.  No dice. 

It turns out that this error is probably a red herring.  The more likely cause is that there’s an error in your deployment somewhere.  

It’s probably not a problem with your code (lightly speaking), or it Solidity wouldn’t compile.  However, it could be something that’s sorta, kinda related to your code.

In my case, everything was working until I tried to pull some contract names up into interfaces and had naming collisions even though I thought I had organized my code properly to avoid them.  Others have reported similar issues such as not implementing constructors from parent classes properly.

So, long story short, if you see the check-your-gas-amount “error” it’s probably not a gas issue — you probably have an issue lurking somewhere in your codebase.

Hope this saves you an hour or two….. good luck out there 🙂

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!

 

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.