Twenty Years of Being Wrong

I've been in technology leadership for over twenty years. In that time I've built things I'm proud of, led teams that did remarkable work, and made decisions that turned out right.

This article isn't about any of that.

This is about the mistakes. The ones I replay on long drives. The ones I wish I could go back and undo. The ones that taught me things I couldn't have learned any other way — which is a nice thing to say about them now, but wasn't much comfort at the time.

I'm writing this because leadership advice tends to come pre-digested. Lessons extracted, edges sanded down, failures reframed as "growth opportunities." The reality is messier. Sometimes you just get it wrong, and the getting-it-wrong part is the important part.

The Hire I Championed

Early in my career as a leader, I fought to hire someone I was convinced was brilliant. They interviewed well — articulate, technically strong, confident in a way that felt like competence. A couple of people on the team had reservations. I overrode them.

Within three months it was clear the fit was wrong. Not a bad person — a bad match. The skills that showed up in interviews didn't translate to the actual work. The confidence that impressed me in a one-hour conversation became inflexibility in day-to-day collaboration.

The mistake wasn't the hire. You can't know everything from interviews. The mistake was overriding the people who'd be working alongside this person every day. They saw something I didn't, and I treated my own judgment as more reliable than theirs.

What it cost: Six months of team friction, a painful departure, and a lesson in how much damage a leader can do by being too sure of their own read on people.

What I learned: The people closest to the work almost always see things the hiring manager doesn't. When multiple team members have reservations, that's data, not noise.

The Architecture I Loved Too Much

There was a system I designed that I thought was elegant. Genuinely clever. It handled edge cases beautifully and anticipated problems we hadn't even encountered yet.

It was also nearly impossible for anyone else to maintain.

I'd optimized for intellectual satisfaction instead of operational simplicity. The team could use it, but they couldn't extend it confidently. Every change required understanding the full system, because the abstractions were so tightly interwoven that touching one part rippled through everything else.

We eventually rewrote it. Took about a third of the code, covered maybe 90% of the use cases, and the team could actually work in it without fear. The remaining 10% we handled with simple, ugly, obvious workarounds.

What it cost: Months of slowed velocity while people tiptoed around my clever system. And the rewrite itself — time that could have gone to new work.

What I learned: Code that only the author can confidently modify isn't an asset. It's a liability with good comments. Optimizing for deletion beats optimizing for elegance.

The Conversation I Avoided

I had someone on my team who was underperforming. Not dramatically — just consistently operating below where they needed to be. Missing deadlines by small margins. Producing work that was fine but not good. Disengaged in meetings in ways that affected the people around them.

I kept telling myself it would improve. That maybe they were going through something. That maybe I was being too demanding. Every week I'd think about having the conversation, and every week I'd find a reason to put it off.

By the time I finally addressed it directly, the team had been carrying the weight for months. Two people I valued were frustrated enough to be looking elsewhere. The underperformer themselves was surprised — they'd genuinely thought things were going okay, because nobody had told them otherwise.

What it cost: One person who might have improved with earlier feedback instead left feeling ambushed. Two strong performers who lost trust in my willingness to address problems. Months of suppressed team morale.

What I learned: Avoiding hard conversations isn't kindness. It's cowardice dressed up as empathy. The longer you wait, the more people get hurt — including the person you're trying to protect.

The Rewrite That Should Have Been a Refactor

"Let's just rewrite it." Three of the most expensive words in software.

I greenlit a full rewrite of a system that was painful but functional. The team was frustrated with it, I was frustrated with it, and a clean slate felt like the right answer. We estimated three months. It took closer to nine. During that time, the old system still needed maintenance, so we were effectively running two systems — the one in production and the one that was supposed to replace it.

When the new system finally shipped, it was better. But it wasn't nine-months-better. It was maybe 30% better, and we'd introduced a whole new set of bugs that the old system had long since resolved through years of patches.

What it cost: Nine months of engineering time. Customer-facing bugs we'd already fixed once. The morale hit of a project that kept slipping its deadline.

What I learned: The old system's ugliness was partially load-bearing. All those patches and workarounds encoded real-world knowledge about edge cases. A rewrite doesn't transfer that knowledge — it discards it. Refactor incrementally unless you can articulate exactly why you can't.

The Time I Confused Activity with Progress

This one's embarrassing because I've warned other people about it so many times.

There was a period — I think it was during a particularly intense planning cycle — where I was in meetings from 8 AM to 6 PM, every day, for weeks. I felt productive. I was making decisions, unblocking people, moving things forward. My calendar was proof that I was needed and engaged.

What I was actually doing was making myself the bottleneck. Every decision routed through me because I'd accidentally trained the team that I needed to be in every room. People were waiting on me instead of moving forward on their own judgment.

When I finally got sick and was out for a week, almost everything continued without me. The things that stalled were the things I'd hoarded — decisions I should have delegated months earlier.

What it cost: Slower team velocity. A dependence on me that was fragile and unnecessary. My own health, briefly.

What I learned: If your absence doesn't cause any problems, you've built a good team. If your absence grinds things to a halt, you've built a dependency. One of those is leadership. The other just looks like it.

The Promotion I Got Wrong

I promoted someone into a leadership role because they were the strongest individual contributor on the team. Classic mistake — so classic it's become a cliché, and I made it anyway.

They were miserable. The things that made them exceptional as an IC — deep focus, technical perfectionism, comfort working alone — were exactly the wrong skills for management. They spent their days in one-on-ones and planning meetings instead of the deep work they loved. Their reports didn't get the support they needed because their new manager was still trying to write code instead of clear paths.

We eventually found a way back — created a senior IC track that gave them scope and recognition without management responsibilities. But the detour cost everyone: the person who spent six months in the wrong role, the reports who had an unhappy manager, and me for not seeing the obvious.

What it cost: Half a year where nobody in that part of the org was doing their best work.

What I learned: Leadership isn't a promotion. It's a different job. The best ICs deserve recognition and growth that doesn't require becoming someone they're not.

The Feature I Shipped Too Early

We had a deadline — external, real, not one we'd invented. And we had a feature that was maybe 80% there. I made the call to ship it.

The 20% we were missing turned out to be the 20% that mattered most to actual users. The core functionality worked, but the error handling was rough, the edge cases were unaddressed, and the onboarding experience assumed knowledge that new users didn't have.

We spent the next two months in reactive mode — fixing bugs, answering support tickets, putting out fires that wouldn't have existed if we'd taken another two weeks upfront.

What it cost: More engineering time in fixes than the original feature took to build. User trust that took months to rebuild. Team morale from the grind of emergency patches.

What I learned: The last 20% of polish isn't vanity. It's the difference between software people tolerate and software people trust. Two extra weeks of development is almost always cheaper than two months of damage control.

The Credit I Didn't Share

This is the one I'm least comfortable writing about.

There was a project that went well — better than expected. When it came time to present the results, I talked about what "we" did, but the framing made it clear that I'd been the driving force. I wasn't lying, exactly. I had been deeply involved. But the actual breakthrough had come from an engineer on the team who'd had an insight I hadn't, and I hadn't made that visible enough.

Nobody called me on it. The engineer didn't complain. But I could tell something shifted. A small withdrawal of trust that I'd earned and then squandered through carelessness.

What it cost: Hard to quantify. A relationship that was slightly less open afterward. The knowledge that I'd failed at something I claim to care about.

What I learned: Credit is not a finite resource, but it feels like one when you're the person who didn't get it. Being generous with credit costs nothing and builds everything. Being careless with it costs more than you realize until it's too late.

The Bet I Didn't Make

There's an opportunity I passed on because the timing felt wrong. The team was stretched. We had commitments. It would have required reprioritizing work that important people were expecting.

Someone else took that bet and it worked. I watched from the sidelines as they built something that I'd had the chance to build first.

I won't go into specifics, but the lesson was painful: "the timing isn't right" is sometimes genuine prioritization and sometimes just fear wearing a responsible-sounding mask. I've gotten better at distinguishing between the two, but I still don't always get it right.

What it cost: An opportunity that didn't come back around.

What I learned: Good timing is partially a myth. There's rarely a moment when everything aligns perfectly. The leaders I admire most have a bias toward action that I sometimes lack, and I've lost real opportunities to excessive caution.

What I'm Probably Wrong About Now

Here's what makes this list incomplete: I don't know what I'm getting wrong right now. That's the nature of mistakes — you only recognize them after the fact, often well after.

But if I had to guess:

I probably still avoid some conversations I should be having. I probably still hold on to decisions I should delegate. I probably still underestimate how much my assumptions shape what I see and don't see.

Twenty years of experience doesn't make you right. It makes you wrong in more interesting ways, with higher stakes, and — if you're paying attention — with a little more humility about your own fallibility.

That's the best I've got. It's not much. But it's honest.