Whether you’re a manager or an individual, in software development, you own code and that code is in—wait for it—one of three states: you’re writing it, you’re fixing it, or you’re maintaining it. When you’re writing the code for the first time, technical direction as a goal isn’t hard to keep in the front of your mind. What am I building? What tools am I using? Is it going to perform? I don’t know what you’re building, I don’t know what company you work out or your development culture, but I do know that for the code that you own, you set the technical direction, not your manager.

A manager’s job is to forget. That’s what they do. They get promoted and begin the long processes of forgetting everything that got them promoted in the first place. I’m not joking. Manager amnesia will be the source of much professional consternation throughout your career.

Now, in defense of my brethren managers, we don’t forget everything, and during all that forgetting, we’re learning other useful things like organization politics, meeting etiquette, and the art of talking for 10 minutes without saying a thing. The things that we do remember are the painful scars of being an engineer. The scars of experience pop up as random inspiration and make it look like we’re keeping track of it all, but we aren’t. We don’t. This is why my management strategy is to assume those closest to the problem can make the best decisions. That’s how I scale.

There are those managers who are desperately trying not to forget. They believe that given enough time and effort they have the same degree of visibility they had when they owned the code. These people are called micromanagers, and they are going to fail because they’re not learning how to forget.

It’s not just micromanagers driving their teams up the wall with their weekly status reports, 1:1 code reviews, and a complete disregard for the management structure. It’s their quest to know it all that is destroying trust on their team. Why did you hire these people? To get more done. They’re not extensions of you; they’re entirely themselves. Deal with it. Again, those who are closest to the code are immanently qualified to set the technical direction of the work.

Rands, he’s not a micromanager. He fashions himself a visionary and he won’t shut up about Scala. How the hell can I get things done when I’m being Scala-beaten?

That’s the beauty of my list of three. Your manager, micromanager or not, has the same goal. It’s his job to set technical direction—just like you. So, yeah, he’s going to do research at the technical edges, he’s going to think about radical re-architecting. Hopefully, he’s competent and has the ability to do so, but that’s not the technical direction you care about.

It’s easy to forget with micromanagers and visionaries cluttering your day with their agenda, but as the owner of the code, it’s your job to care—daily. Whether it’s during the joy of writing the code, the annoying days of bug fixing, or the seemingly endless maintenance tasks, it’s your call where the code is going to go next. Are we spending too much time on maintenance? Is it time to throw it away and start over? Sure, it’s not necessarily your decision to make, but it’s absolutely your responsibility to raise the issue, to have an opinion, and to affect the plan.

This code is crap. We need to start over.

Early in my career at Borland, I was baffled by the stock. What is it? Who sets it? What’s an option? How do I spend it? Borland was in its heyday, so during all of the stock confusion, the price just went up...for two years. My thought was, “That’s what stocks do. They grow.” Then we missed our number. The earnings we had predicted were missed and the stock took a beating.

More confusion.

Everything in the building looked exactly the same. Everyone was working hard, but we were suddenly worth 25% less? This was my first lesson in perception being reality. The market sees growth as a leading indicator, and the panicky mob that is the stock market equates a lack of a growth with death.

And they’re right.

As the second item in my career philosophy, growth represents the strategy by which you are learning, doing more, getting promoted, getting the shit kicked out of you, and garnering more responsibility. There’s a simple rule designed to grab your attention: “If you’re not growing, you’re dying.”

Let’s see if you’re dying. Ask yourself the following:

Any answer of “No” is a troubling sign. You’re coasting. Sure, it’s comfortable, but while you’re sitting there in your mediocrity, your industry is aggressively attempting to make you irrelevant. It’s not personal; it’s a function of all of those other bright people who aren’t scared of failure, who have surrounded themselves with catalytic personalities, and who thrive on understanding.

Rands, isn’t it my manager’s job to grow me?

There are two parties responsible for your growth. You and your manager. Now, this isn’t actually true, but early in your career, it’s a convenient illusion. It is your manager’s responsibility to care more about your growth than you. They do have more experience and are able to identify and assign opportunity suitable for that growth. She’s ready to be a tech lead. I can feel it.

Unfortunately, you’re always second in line when it comes to growth with your manager. I pessimistically believe that your manager will consider his interests before he considers yours. It sounds devious, but the same rule that applies to you applies to your manager: grow or die.

Perhaps a healthier way to think of it is that your manager is responsible for your job, but you’re the manager of your career. The primary goal of both jobs is to identify and act on opportunity inside of the company that is going to challenge you, force you to learn, and push you to the edge of discomfort. These opportunities are going to confuse you because it’s unfamiliar territory and you don’t have a map...which is the point. A good manager creates opportunity, but it’s your responsibility to take it.

However, your boss is not going to discover opportunity outside of the company. They’re likely never going to say, “Yeah, we’re doomed. Get the hell out.” There is no one more qualified and informed to make decisions regarding your larger future than you.

I am ready for more.

It’s an unfortunate necessity that in our industry, the shit hits the fan. Just under two decades of experience in the Silicon Valley working at big companies, and I can confirm that random disasters are a constant.

Let’s assume that you’re a responsible person in the next disaster. Let’s assume it’s of a deeply technical nature, and let’s assume you’re not capable of handling this disaster. Who do you call?

Got a name? I bet you do. It’s the guy who can do anything. He’s probably got an office in a company where only managers have offices. He probably wears very strange T-shirts and has odd eating habits, but what’s important about this guy is he delivers—like a machine. There’s nothing that you can’t ask this fellow to do that he doesn’t leap on, can’t explain, or can’t argue about.

My guess is this guy is deeply technical—maybe an architect, perhaps a free electron—but going back to the question, why’d you call him to help with the disaster?

He delivers. It’s not even a question. You don’t consider for a moment that he won’t be able to help. Even if the technical expertise you require has absolutely zero intersection with his experience, you know that he’ll be able to help.

It’s a skill, yes, but it’s not the skill that everyone admires; it’s the reputation. It’s the expression you’ll see on your boss’s face when you tell him, “Yeah, I know it’s a disaster, but Ryan’s helping.” Oh good, it’s handled.

If technical direction is your ability, and growth is the refinement and shaping of that ability, then delivery is the reputation you construct around that ability, and the rule is also simple: “Do what you say you’re going to do.”

Quips, quotes, tweets, and clever names are littered all over my writing, but don’t let their simplicity imply they are easy to apply. Doing what you say you’re going to do is hard. Let’s do the math.

If X is ever larger than Y, then your reputation is suffering. Any task, big or small, that has landed on your plate and you failed to complete is eroding your reputation. Here’s why:

It wasn’t a big deal. They didn’t even notice. Yeah, they did. Maybe they didn’t follow up and maybe it wasn’t that big of a deal, but there was a brief moment when they internally measured you: Didn’t follow up. Didn’t complete. Doesn’t care. That’s what they remembered.

I couldn’t say no. It was my boss. When you accept a task from your boss, whether you’re able to complete it or not, the assumption is that you’ll do it. Saying no to the person who signs the checks is tricky, but again, think about your reputation. Are you going to lose more points for saying no to a task or for failing at that task?

But I want to be a team player. Yeah, good teams don’t fail.

The Quakers have a tenet that reads, “Speak truth to power.” When the boss is signing you up for failure, your move isn’t laying down the no; your move is to tell the truth. Hey, I have no idea how to be successful here. I care about being successful, and so should you. Help.

You need to be maniacal about your reputation. Yes, a single failure to deliver isn’t a disaster. Mistakes happen. X is sometimes bigger than Y, but some misses are vastly bigger than you expect. That one off-handed request from your VP that sounded like it wasn’t a big deal? Well, by itself it wasn’t a big deal, but the three tasks after that were a big deal and when she reverse-engineers where the failure originated, she’s not going to remember that the request was off-handed. She’ll think, “Right. Unreliable.”

A reputation is a community-based opinion that you don’t control. It takes years of work to develop and a single missed key responsibility to destroy.

I use the word “rule” a lot in this chapter, but I’m not a rule guy—I’m a direction guy. If you’re looking for the definitive 38 ways to effectively manage your career, I’m sure there’s a book for that. The “List of Three” is intended to give a semblance of structure and a sense of direction.

For me, technical direction is a reminder to care daily about my work. Growth is actively watching my career and making sure that today is not a dull repetition of yesterday. Finally, delivery is my daily investment in my reputation. Keeping this list in my head keeps me asking questions and, more importantly, keeps me growing.

To me, the fundamental unit of growth is knowledge. Knowledge isn’t facts, and knowledge isn’t data. It’s your consumption of facts, data, situations, and personalities, and the consumption yields a discovery. It’s when you mentally build something new. This knowledge may not be novel, but what makes it unique is that you built it for yourself.

The act of creation makes knowledge yours. It grows your mental arsenal—giving you a new experience to reflect upon forever.