The Loss of Leadership

The Legend of Zelda

I was ten years old when I conquered the original Legend of Zelda. Took me a month. Every day after school, alone in my room, no guide, no help, just the game and me. I got stuck constantly. I’d hit a wall and want to throw the controller. But I kept going. And when I finally finished it, that feeling. I still chase that feeling.

Before Zelda it was LEGOs. The monorail set, the castle, the Technics, all of it. I built sharks and swam them in the pool. I built Batmobiles and spaceships and entire cities on the floor of my bedroom, and my mom would step on them and I’d lose my mind. I still have them. A giant bin in my closet, forty-something years later. If I had infinite time and money I’d buy every set and build them all. That’s not nostalgia. That’s who I am.

I’m a builder.

Coding was the adult version. Twenty years of it. The same puzzle-solving, the same construction, the same feeling of making something exist that didn’t exist before. A friend once told me he had an unhealthy obsession with abstract concepts, and I thought, yeah, me too. I loved the architecture of it. I loved that when I wrote something and it ran and it worked and it helped someone, I could point to it and say: I built that.

Then I stopped.

Not because I burned out. Not because I got bored. Because I couldn’t do everything at once. I was trying to be an architect, a people manager, and an engineer all at the same time. If I committed to writing code, the leadership work suffered. If I committed to leading, I broke promises to the team. Something had to give, and the thing that gave was the thing I’d loved for twenty years.

That was a real loss.

For about eighteen months, I went home every day feeling like I hadn’t done anything. I went to work. I sat in meetings. I talked. I came home. No code ran. Nothing got built. I just talked about work instead of doing work, and the difference between those two things felt enormous. I’d close the laptop and think, what did I actually produce today? The answer, most days, was nothing I could point to.

It felt like being good at something that didn’t count.

Here’s what nobody tells you about that transition. From engineer to leader. From building the thing to helping people build the thing. It’s not a promotion. It’s a career change. And the hardest part isn’t learning the new skills. The hardest part is that your old definition of a successful day doesn’t apply anymore, and you don’t have a new one yet. You’re just walking around with a hole where the scoreboard used to be.

The thing that turned it was a phrase I didn’t expect. Organizational architecture. Sounds like a corporate term, but for me it was a key. I realized I was still building. I was still constructing things and solving problems. Just not with code. With people. With teams. With structure. I was designing how groups of humans work together to go solve problems, and that’s architecture. It’s topology. It’s systems thinking applied to people instead of machines.

I still get the LEGO feeling. I’m building at a bigger scale now, building teams and structures and strategies instead of features and functions. What I lost was the Zelda feeling. That private triumph of solving the puzzle alone. That one’s gone. The trade-off is that more things can happen now than my own two hands could ever produce. The multiplicative effect of good organizational architecture is enormous. But some days I still miss the controller.

The tricky part is that people aren’t computers. Computers do exactly what you tell them. That’s the beauty of code, and also the trap, because sometimes what you think you wrote isn’t what you actually wrote. But at least the feedback loop is immediate. You run it, it works or it doesn’t. People are different. People have emotions. People have needs. People have bad days and blind spots and their own ideas about how things should work. Organizational architecture requires empathy in a way that software architecture never did.

My daughter Fiona taught me this long before any job.

She was little, maybe a year old, and I was trying to feed her. Peas. She wasn’t having it. I switched to sweet potatoes, snuck the peas back in. She caught on. Locked her jaw. Made the face. And then she smacked the spoon right out of my hand. Here’s the thing though. She’d eat it. She’d eat the peas. She just wouldn’t let me feed them to her. She wanted to do it herself, her way, on her terms.

She’s thirteen now. Nothing has changed. She will accomplish anything you put in front of her, but don’t you dare tell her how. She’s the first one at the door when I come up from work. What happened today? What did you do? What’s going on? She’s curious and fierce and people want to call that bossy. I call it leadership.

And it’s the same lesson I learned managing engineers. Don’t tell people how to do their work. Don’t even tell them what to do. Tell them why. Give them the reason. Give them the outcome you need. Then get out of the way and let them surprise you. Express the need, not the strategy to meet the need. Outcomes, not outputs.

You know what the opposite of that is called? Micromanaging. And nobody wants a micromanager.

There was a meeting, early in this transition, that proved to me I was in the right place. We were doing the usual presentations. Business objectives, strategy decks, the kind of corporate theater where everyone nods and nothing changes. Meanwhile the engineering teams had been saying for eight months that we were building the wrong thing. Nobody listened. They brought in a consultant. The consultant said the same thing. Suddenly it was true.

So when it was my turn, I didn’t present slides. I walked to the whiteboard and drew an architecture diagram. Simple. The actual system. I showed the tech debt that years of top-level whiplash had created. Every time leadership changed direction, it fractured something in the architecture, and nobody had ever explained that to them. They just thought the engineers were slow.

The room got quiet. It was a little dangerous, drawing the ugly truth in front of the new CEO. But it didn’t matter. People came up to me afterward. Thank you for doing that. Someone needed to do that.

That’s when I stopped second-guessing. I’d been thinking about going back. Just be an engineer again. Write code. Solve puzzles. Get the Zelda feeling back. But standing in that room, I realized something. There was a gap between the people making the decisions and the people building the product, and almost nobody could see both sides. I could. I could speak engineer and I could speak executive and I could translate in real time. If I walked away from that, who would do it?

Not arrogance. Just math. I looked around and the gap was still there and I was standing in it.

The higher up you go in leadership, the more your job is communication. That’s the thing I wish someone had told me going in. I tell it to every engineer now who’s thinking about making the jump. It’s going to be harder than you think. It’s a career change, not a step up. Your definition of a successful day is going to break, and it’ll take longer than you want to rebuild it. But when it does rebuild, when you start seeing your team’s output as your own, when you realize you’re still building just at a different scale, it’s more powerful than anything you could have done alone.

I was an engineer. Then I became a leader. The LEGOs are still in the closet. The instinct to build never left. I just learned to build bigger.

I love winning. It’s even better to win as a team.

Uncomplicated systems. Uncommon results.