…or how my performance review got out of hand and I ended up writing a blog post instead
Hey, look at that! 2018 is all but done and my performance review is due. As I have looked back at this past year to evaluate myself and as I piece together personal goals for next year, a bunch of leadership-related stuff coagulated in my mind.
Develop more than code
Being a leader is not just about being an awesome developer but about influencing and enabling others to be awesome developers as well.
Don’t get me wrong. In order to influence others to write better code, you have to have a certain level of proficiency yourself. But if you look back at your career, however long it may be, I guarantee you that the most impactful leaders are not the ones who were the best developers but the ones who invested the most in you.
Software development is not a zero-sum game. Helping others doesn’t negatively affect your own performance.
Consider a poker game. Each player comes to the table with a certain number of chips. Every time a player wins a hand, he does so at the expense of the other players at the table. Ultimately, one player will walk away with all the chips. The amount won by the winner exactly equals the amount lost by the losers. Stated differently, the sum of all the amounts won and lost by all players equals zero, hence the term “zero-sum game.” But not everything is like this.
The zero-sum bias is a cognitive bias that incorrectly attributes “zero-sumness” to a given situation. The side effects of such zero-sum thinking may include lack of cooperation and an increased perception of hostility from peers. (If you think you are experiencing these side effects, stop treating software as a zero-sum game immediately.)
As a software developer, zero-sum thinking makes people hesitant to mentor junior developers, contribute to open source projects, champion other people’s ideas, or engage in any other activity that would aid in the success of someone else. I have made this mistake more than once by assuming that someone else would get credit for my genius or somehow inhibit my own success. Nothing could be further from the truth.
I firmly believe that you don’t really know something until you can teach it from memory. Think you know the difference between types and interfaces in Typescript? Can you explain it without Googling anything?
Additionally, passionately investing in others is a great way to suppress your own ego. Be a resource for others. Market your peers’ ideas. Publically recognize your team’s success. Fight for the underdog. Make yourself vulnerable by depending on the success of your peers.
“Leaders become great not because of their power but because of their ability to empower others.” — John C. Maxwell
It feels good to be followed because of the success you bring to your company. But what really takes leadership to the next level is being followed because of the success you bring to others around you.
Delegate what you’re good at
This is actually an area of recent personal failure and subsequent growth. I have been providing architectural oversight for our in-house team as well as managing our off-shore team. In an effort to improve the project’s velocity, I have been methodically identifying and removing process bottlenecks.
Everything was going swimmingly until I became the bottleneck.
I wasn’t able to review code fast enough. I wasn’t able to pass features to QA fast enough. I wasn’t able to keep up with answering technical questions. I was the bottleneck but I literally couldn’t get any more done. I have hit burnout enough times in my life that I started to hear the train coming and knew I needed to get off the tracks. (cue “hello darkness my old friend …”)
I recently read the new and increasingly popular book It Doesn’t Have to be Crazy at Work and was punched in the face with a simple yet difficult truth:
“The only way to get more done is to have less to do.” — David Heinemeier Hansson and Jason Fried
Fundamentally, I should have handed off project management, code review, answering technical questions, and many other things weeks ago; however, I hesitated to do so because I felt that I couldn’t trust anyone else on the team to do as good of a job as me. That wasn’t just arrogant, it was stupid. By not handing off work because “I could do it better,” I ended up doing everything poorly.
And here is the lesson I had to learn the hard way: leading doesn’t mean doing everything yourself. Could I have done it better? Probably. If I let someone else do it, would they have done it right the first time? Probably not. And did it even need to be done that well in the first place? Who can say?
It is natural not to trust others to do things exactly as you would. But it is crucial to allow others to fail in a healthy environment. This is an extension of “develop more than code.” Keeping others from failing deprives them of the opportunity of learning from that failure. It is as pointless as spotting a friend at the gym by lifting for them. In the nicest possible way, if you want to help your peers grow, let them fail.
“We need to fail down here so we don’t fail up there.” — First Man
One way to “develop more than code” is to facilitate the growth of your team by allowing them to take on your responsibility. This requires you to check your ego at the door and spot your team without doing the lifting yourself.
Learn to articulate why you are correct
Good leaders aren’t accidentally successful.
For a number of years, I worked at a job where excellence through good engineering practices was the norm. The company had been around for an eternity (in software years) and intentionally hired and mentored solid engineers.
Once I left, I stumbled upon the knowledge that knowing the correct way to do something is very different than being able to articulate why it is correct. If you can’t clearly articulate why your idea is the right one, then you’re not right, you’re just opinionated.
“Leadership is Influence” — John C. Maxwell
Leadership goes beyond being the smartest developer in the room or simply accruing hours in the industry. It is entirely possible to have done something for a decade and not know why it works or why alternate solutions are more or less successful.
Two things happen when you can articulate why you’re right. In the words of John C. Maxwell, “Leadership is influence.” First, a fantastic way to influence a team to pursue excellence is to not just point to a good solution but to point to reasons why it is correct. This leads to the second thing: to be able to expertly articulate why something is correct, you really need to know the thing.
I had been involved in peer code review for years. It was a habit. In fact, it provided so much benefit, it never crossed my mind that a software shop wouldn’t rigorously engage in peer code review. And yet I found myself working with a team that routinely “approved” multi-thousand line pull requests minutes after they were submitted. Both code and bugs flew fast and loose.
In an effort to help improve things, I suggested that we start formalizing a process for performing peer code reviews. It was received with all manner of responses ranging from “This company doesn’t do code review” to “We already do code review.” In this case, code review simply meant rubber stamping a PR so that our SCM would allow it to be merged.
I came to realize that while I personally understood the process and value of code review, I was terrible at explaining that value to others. In order to be an influence, I needed to master the “why” in addition to the “what.” My next few weeks involved pouring over a ton material. I read about various tips and tricks. I read about how the human brain works when reading code. I read about why teams don’t review code.
Two things happened. First, I got better at peer code review. Second, I was finally able to articulate the concept well enough to be able to motivate the team to actually do it. Over time, code quality started to improve. I distilled the wealth of information I churned through into a code review policy and eventually wrote a blog post about Code Review for Real People.
Borrowing the expensive opinions of others is a great way to ensure that you have Strong Opinions, Weakly Held. I have billions of dollars worth of experimental data sitting on the shelf by my desk. I didn’t pay those billions to get it. I didn’t have to; a good book is rarely more than $50. Not leveraging the wisdom of authors who are experts in their field is a subtle decision to recreate those same billions of dollars of failure.
Good leaders read. They can readily defend their own opinions but deferring to the expertise of others. LeVar Burton’s famous catchphrase from Reading Rainbow planted the seed of deferring to the written authority of experts.
“… but you don’t have to take my word for it” — Reading Rainbow
Good leaders point others to expertise outside of themselves.
Find something you can’t do, and then do it
Lastly, strong leaders don’t get comfortable. If you want to mix things up, find a problem that needs fixing and that seems really hard. Then commit to fixing it. As I do this, I have seen a few things happen.
First, I have learned things and gotten support from other leaders in ways that wouldn’t have happened if I had stayed in my comfort zone. This is the other side of delegating — taking on responsibilities from someone else (who could likely do much better). This leads to the next thing.
Additionally, committing to something you’re not good at means failure now and then. You don’t have to gloat over mistakes, but be honest and own up to where you messed up. Being transparent about your own failure is fundamental to developing others as well as yourself. Better transparency means better feedback from your peers and better feedback means faster growth.
Goals
There is way more to leadership than what I talked about here. But for me, my goals for this upcoming year are to invest more heavily in developing myself by investing in my team and the community around us. And like any recovering Magic Schoolbus addict, I want to:
“Take chances, make mistakes, get messy!” — Ms. Frizzle