Coach, don’t dictate

The initial instinct I had was to micromanage all of the code going into master. It’s a natural instinct really; you are the conduit between your team, and higher levels of management (but hopefully your org is flat enough that you are not a blockade between them and upper management). As far as the team is concerned, the buck stops with you. Not that its a sin to fail (you do have a culture that allows failure, right?); but let’s face it, no one wants to sit there with egg on their face no matter how understanding your org is. Because of this, the urge to control every aspect of the code going into production is strong… at first.

As time moved on though, I began to realize the harm this causes. You have a team that thinks you don’t trust them (and honestly, maybe you don’t… at first). That’s entirely not sustainable. Trust is paramount to having a well functioning team. If you are sitting there picking apart every little thing your team is doing that you would not do yourself (more on this later), you are doing nothing but turning them from engineers to coders. You don’t want robots; you want humans with free will who solve problems and have a sense of ownership over what they ship.

Just because it’s not the way I would do it, doesn’t mean it’s wrong.

I learned pretty quick that there is about a 0% chance anyone is going to solve a non-trivial problem the exact same way I would. There is about a 100% chance that I will be surprised by the solution. This drove me nuts at first. I was suffering from some serious “if it didn’t come out of my head, it’s shit”itis. I would see pull requests come across my desk, and seethe at how bad the solution was; how I could do so very much better. Truth is, I probably could have done some of those assignments better, but that’s not the point. The point is that you must learn to accept solutions that are not your own, otherwise you will foster an unhappy team who will sit there and just wait for you to think for them at best; at worst they will find the door. I was fortunate enough to learn this lesson before it got to my team showing themselves out.

Focus on fundamentals

We gotta have some standards here. I know what I said before (and I mean it). But c’mon, we can’t just merge everything to make everyone happy. Of course, we can’t torture people either. The standards need to be fundamental, measurable, predictably enforceable, and not unnecessarily tedious.

For instance, I expect all work to come with unit tests. I expect automated quality gates to pass. I expect commit history to match a standard. I expect pull requests to be of a reasonable size. Etc etc etc.  These are the broad things that matter. I can point to a section of code and say “this is missing tests”. I can ask for a commit message to contain more information. I can easily point to a failing build, or a quality gate failure.

In speaking of quality gates…

Automate quality controls

Hopefully your org already has this set up for you, but if they don’t, please ask for forgiveness instead of permission, and set up a basic CI pipeline with code analysis.

It’s extremely tedious to review code without the help of some static analysis tools. Hell, even if you have the tools, it’s tedious to run them manually and then communicate the results for each run to the person that needs to hear it. It’s the 21st century, automate your build. Let the machine deliver the bad news so you can spend more time engineering, and less time explaining why four nested foreach loops is a bad idea.

Patience is a virtue

Things aren’t going to go right all the time. Teammates are going to fail. You will fail. All of us will fail. I swear I am not a nihilist.

You really have to be patient with people. You can’t force someone to understand something. You can’t open up their head and mainline knowledge right into their brains. It takes time for someone to learn alternative ways to accomplish goals that may or may not be better. Be there to support them through the journey. Help them get to the next level; but it’s not a race.

Humility is a virtue too

Look at you big shot, you are the lead. The boss of the team. Finally, you can be in control and get all of these guys into mini yous. Bless your heart if you think this way. Ok, I wasn’t quite this bad, but I did think the learning was top down. Boy, that was awfully stupid of me.

I remember the first time I came across a pull request where a technique was used that I had not been aware was possible within the codebase we were maintaining. What a refreshing moment! But here is the real kicker; I would have solved this same problem in a much dumber way. Praise be to that developer who opened up my eyes to how susceptible I still was to doing things in sub-optimal ways.

Play to the strengths of your team

Don’t judge a fish by its ability to climb a tree, and don’t judge an engineer by their ability to write a regex. Just because someone is bad at one thing, doesn’t mean they don’t excel elsewhere.

I remember speaking to my manager at the time about a member of my team, and how they were “at a certain point in their career” based on how they accomplished some planning task I had assigned them. He was quick to correct me, and teach me this lesson. He was most certainly right about this. You need to use this to your advantage. Don’t ask that front-end engineer on your team to write a SQL query if they don’t like writing SQL queries. But more importantly, don’t judge them for not wanting to write that query. They don’t like it, and they are way better off spending their time refining the front-end instead.

It’s good to be quiet sometimes

I think most people become team leads because they spoke up in meetings, and delivered quality results. They convinced their managers (either directly or passively) that they were ready to get to the next level. They spoke up, gave their opinions, helped others, and generally showed signs of leadership.

Now you are a team lead, and it’s time to shut the fuck up sometimes. Wait what? Yes, that’s right. Shut. The. Fuck. Up.

I really loved to hear the sound of my own voice blah blah blah’ing about this problem and that problem and solve it this way and we can do that and we will need this and yadda yadda yadda. I still kinda do. I’m a flawed human. But guess what, noone else but me was speaking. I was taking all the air out of the room, and leaving none for anyone else. Eventually, my team got comfortable with this, and just let me do all the thinking.

One on Ones are not for me, its for them

In speaking of loving the sound of my own voice, did you know your one on ones are there for you to listen? It seems obvious, but its pretty hard to sit there and just listen sometimes. I’m a software engineer. I imagine if you are one of the three people who will actually find this post, that you are as well. There is an innate drive to try to solve problems instead of just listening. Do yourself and your poor staff a favor, and just listen. Every one on one should start with “How are you?” (and mean it). Next phase should be “do you have any topics you want to discuss”? Yes, this is their time to ask you for advice, tell you their problems, etc. Then and only then do you bring in your topics.

I have a feeling when I write the post “What I’ve Learned In Five Years in a Management Role”, I’ll have a lot more to say about this.

Servant Leadership is best leadership

You are not there to be a dictator. No one likes a dictator. I can’t think of a quicker way to suck all the joy and morale out of a team than to sit there and dictate every nuance of what they should be doing. No, you are there to collaborate and serve, with emphasis on the serve part. You are the shield protecting them from BS meetings. You are the one getting them access to the tools they need to success. You are there to listen with empathy as your entire one on one is spent being an emotional sponge as your team member passionately explains why the decision to switch from snake_case to camelCase was a bad decision. You are there to enable them to do their best!

I’m not saying that you don’t make decisions, and I am not saying that you cater to the every whim of your staff. What I am saying is that everything you do should be in the service of helping your team be the best they can possibly be.