The Choices We Make

…and why it is so difficult to make them.

Let me share with you an interesting question, one that continually comes up as I talk with other software engineers taking their first steps toward leadership:

How do I “let it go”?
I’ve become a lead in my role, and I really need to focus on delegation and guidance instead of doing it myself.

A very common problem, faced by all manner of leaders but one that is particularly troublesome for engineers. There are plenty of articles talking about it, so people are usually good at identifying the problem. Those articles didn’t help me though. They explained why I should delegate, or what things to delegate, or even how to delegate… but I couldn’t internalize it. And from all the questions I’ve seen, there are many leaders struggling with the same problem. So here is what helped me come to grips with the problem of letting it go, I hope it helps.

Photo by KT on Unsplash

When I started as a software engineer, things were simple. My boss or lead would assign me some task, and I would fumble about for some time until it was done, repeat. I got better, and pretty soon there was a meeting where the boss asked “who wants to work on this task?”

Do I want to work on that task? No! That task is new and strange and Emily seems like she knows that area of the code and I am scared of The Unknown. As an engineer, my mind is always doing engineer things. Solving problems, identifying gotchas, optimizing some system… I looked at that task and thought Am I the best person to work on that task?

As a beginner, the answer is almost always no. But as I worked on tasks slightly outside of my skill set, I got better and better. As I became a team lead, I found there were suddenly lots of problems where I would be the best person to do the work. I could do them faster, with fewer bugs… “it’d take me longer to teach you than to just do it myself”. Which of course led to me having too much to do. Thankfully, I’m not the sort who responds by just working more. Yet that also meant that I was the bottleneck for things getting done.

So I read through leadership books and articles, all of which argued convincingly that I would become more effective if I prioritized important things and delegated the rest. Great, I knew that already. I already got rid of the not-important, not-urgent work and there’s still way too much to do.

The change in mindset I needed to make was to shift to Is this the most important work I can be doing? Which was very effective because it let my engineer’s optimization mindset continue doing it’s thing. Instead of sorting by things I am best at, I can sort by the “best” things to do. Sure, “best” is going to need to be some balance between urgent and valuable and stuff I can do better than others, but that’s fine. Those are trade-offs just like the trade-offs I make every day designing code. And while that realization was slow and painful, most of the mental concepts didn’t come from leadership — they came from sports.

One key concept was the idea of Pot Odds. This is a poker concept where you balance your bet with expected reward. Betting five dollars when you’ve got a one-in-ten chance to win twenty dollars is a terrible bet. Betting five dollars when you’ve got a fifty-fifty chance of winning a hundred dollars is an excellent bet. This was key because as a lead, my work became a lot squishier. The outcomes of endeavors were less clear cut, the value of certain actions were less measurable, even inaction carries its own set of risks with different vague likelihoods and severities. With so much unknown, choosing what to work on became more like gambling — which of these bets will have the biggest payoff to bet ratio?

The other key concept was the idea of Opportunity Cost. Now this certainly isn’t a sports-specific concept, but I learned the practicality of it reading Bill Barnwell’s writing. He’d continually talk about how drafting a certain player, or playing a player at a certain position, or spending a certain percentage of the salary cap would preclude a team from doing other things. And this concept was vital in helping me let things go. If I spent my time writing some code, that was time I couldn’t spend helping my team. If I spent my emotional energy in that design meeting, I couldn’t spend it when advocating for my team member’s raise.

The terrible, terrible consequence of this is that I will be voluntarily making worse software. When I delegate some task to an intern, they are going to write worse code. There will be more bugs. It will take longer. And it will be my fault. My engineering brain looks at this option and it recoils in horror!

This conflict was the one that kept me from letting go, only I didn’t realize it at the time. Intellectually, Pot Odds and Opportunity Cost and prioritizing by value made perfect sense. Emotionally, I couldn’t accept adding bugs after decades focused on making the best software I could. I imagined my boss or my team asking me why I let the intern do that work when I knew it would lead to bugs. All so I could do something I wasn’t really good at yet and might yield some vague immeasurable benefit? No wonder I couldn’t delegate effectively.

Once I understood the conflict, letting things go became… merely difficult. After all, you don’t change decades of emotional response overnight. But that is my problem now, along with building a culture of psychological safety and blameless failure to help new leaders faced with their own terrible choice.