He Wasn't Analytical. He Was Slow.

A long time ago (but not in a far away galaxy) I was a Senior Engineer at a company that sold tee-times. I've talked about this company a few times on Chaotic Commits.

During my time there, we bought a piece of software. And let me say it was rough. And rough is me being diplomatic here.

After an "eventful" trip to New York, and a few decisions made by leadership, I got put on the project of maintaining and transitioning this "beauty" into our ecosystem. Make it compliant, since it wasn't. Move it onto our tax service. That kind of work.

On this "dream team" were one junior engineer, one mid-level, and two seniors (me and let's call him Bob).

Bob was, and I say this with zero ageism intended, twice my age. I'd been in the industry about seven years at that point, so I was 27 or 28. Bob was a Senior Engineer like me, and to be clear, staying at Senior is perfectly fine. It's a terminal role and there is nothing wrong with that.

I barely worked with Bob before this. He hadn't gone to New York to analyze the software. He rarely spoke up in org meetings. He wasn't mentoring anyone.

And then my manager made a choice: no lead engineer for this project. Bob and I would "work it out." His reasoning, as told to me, was that Bob had things I should learn, and I had things Bob should learn.

In hindsight (which is 20/20), that was one of the worst possible management moves. Take two seniors with nothing in common, no shared history, and no assigned lead. Call it collaborative.

It's just leadership avoiding a decision.

The Mismatch

So, let me tell you about Bob. Bob was slow. Bob was quiet, and not in the thoughtful way, just no opinions offered. When pressed, he got flustered easily. And he over-analyzed everything.

Our pairing was oil and water. I move. Delaying a decision feels like wasting one. I'm direct: if something doesn't make sense, I say so. I ask questions. I look at a problem, land on a solution, and go. If we're stuck, I pull up a chair and we pair program.

Basically, I was Silicon Valley's "move fast, break things" poster child at 27.

But the thing is, Bob had been in the game longer. Far longer than I had. My manager loved him for it. Tenure wasn't something I could just magically have. It's not like I could wave a wand and, bam, ten more years. My manager made that clear too. Bob had experience. My seven-ish years, apparently, didn't count for much.

So, as you can guess, this frustrated young Joanne.

The Billing Class

So now the drama. We love drama, right?

There was a huge C# class in this software (actually, there were several, this is just the one I remember). It was a billing class, but it also handled printing, payments, and receipts. Hundreds of imports. Using statements, if you're not a C# dev.

If you are a C# dev, you just said "hundreds?" Yes. Hundreds. Not an exaggeration.

No separation of concerns. Classic OOP violation. I looked at it and said we need to refactor this. You take X, I'll take Y, let's go.

He didn't go.

I spent days refactoring what needed it, starting with the low-hanging, low-risk items we'd identified together. He spent those same days on something else entirely.

What he did, instead of the items we'd agreed to in sprint planning, was an analysis. Days measuring import delay. He built a very basic spreadsheet showing that once you hit X imports, the delay became Y. By the way, the caveats, edge cases, dependencies, none of that got measured. That's a separate argument.

I was livid.

He presented this at our demo. All week in standup he'd said the receipt refactor was "in progress" but complicated. Turns out he was making a spreadsheet. And listening to podcasts. A month into this project, and I was done. Me, the junior engineer, and the mid-level engineer were carrying it while this guy updated us on Reddit news.

His findings were something any C# dev already knows. Somewhere out there is probably a style guide that just says: more than 15 usings is a code smell.

The Confrontation

So I was done.

I had never been that "done" before. Never in my life had I thought, "wow, this person sucks at their job." And by now it was affecting the whole team. So I went to my manager. Not because I'm a "bitch." Because at this point, the problem was bigger than the two of us working it "out."

I showed him the "spreadsheet." Days of "work" that wasn't days of work.

Mind you, at the time I was working on my PhD full time, alongside this job. I knew what an analysis was. When I finished my day job, I went home and ran simulations. This wasn't that. It wasn't anywhere close.

My manager said, "You don't appreciate it now. But once you're in this field longer, you'll appreciate how Bob works."

...

...

...

Years Later

I've now been the manager. At other companies.

And sometimes an engineer reminds me of Bob.

They don't look like him. They aren't his age. But there's something Bob-ish about them. Maybe it's the flustered moment in standup. Maybe it's slow and steady bordering on nothing at all. And when those little things show up, well.

I hesitate.

Bob was, from where I stood, a poor performer. But my manager insisted I didn't understand. That I didn't value what he brought.

And I never knew what my manager thought he "brought."

So now, as a manager, a director, whatever the title, am I missing what my manager saw all those years ago?

That feeling never goes away.

Leadership

And here is where we sit. Leadership. That's the whole point of this article. And yes, I put it at the end on purpose. You had to earn this read by sitting through the uncomfortable story first.

You will work with Bobs. You will manage Bobs.

Sometimes the Bobs are good at hiding. Sometimes they're just someone the manager doesn't want to deal with.

Looking back, I spent most of that project angry at Bob, and I was completely wrong.

Bob was doing what Bob did. My manager was the person who had the authority to fix it. He could have noticed the mismatch, set clear expectations, assigned ownership, and intervened when the team wasn't functioning.

But he didn't.

But it still taught me something:

Lesson 1: "It'll be good for you" is a manager avoiding a decision

No lead was named on purpose.

My manager framed it as collaborative, as a chance for two seniors to learn from each other. But strip the framing away and look at what actually happened: two people with no shared history and no assigned authority were left to "figure it out."

That's not trust.

That's a manager who didn't want to make a call.

My manager was probably uncomfortable naming a lead. Maybe I was too headstrong or he didn't want to disappoint Bob. But my manager's job was to have that uncomfortable conversation, and he avoided it.

If your leadership can't tell you who's driving a project, ask yourself why.

Sometimes the answer is trust. Sometimes it's avoidance.

Lesson 2: Analysis isn't output. Sometimes it's a hiding place.

Bob wasn't lazy. I want to make that clear. He was "busy" every single day. The problem is busy isn't the same as productive, and this took me way longer than it should have to learn.

He spent days proving something any C# dev with basic experience already knew: too many imports slows things down. That's not insight, it's a fact you could get from a five-minute conversation.

Managers need to watch for that gap. Rigor and stalling can look identical from far enough away, especially to someone who isn't close enough to the actual work to tell the difference.

Lesson 3: Tenure isn't automatically expertise

"You don't appreciate it now, but once you're in the field longer, you'll appreciate how Bob works."

That's not an argument.

Years in the industry can mean someone has developed real judgment. It can also mean someone has spent years sitting at a desk. Those two people can look identical on paper.

A manager's job is to look past the paper and evaluate the actual work in front of them, not defer to whoever has been around longer.

Lesson 4: Bad management outlives the project

The "Bob" situation ended eventually. I moved on, he stayed a senior engineer, life continued. But something from that experience stuck with me.

Years later, whenever an engineer reminds me of him, even a tiny bit, the doubt resurfaces.

Am I missing something?

Is there a version of "analytical" here that I'm not giving enough credit?

That doubt is mine. But it was planted by a manager who defended the wrong person and told me I lacked the experience to see it. That's the real cost of that kind of defense. It doesn't just protect the underperformer in the moment. It plants a seed of self-doubt in the person who was right, one that can take years to fully dig out.

Lesson 5: What I do differently now

I follow the motto "clear is kind."

That means, I name the skill gap clearly. If someone isn't performing, I will never dress it up. Because dressing it up protects my own comfort, not the team.

I will also always assign a lead when a project needs one. I won't let a personality clash talk me out of it. Ambiguity about ownership isn't developmental. It's a setup, and usually the person who ends up carrying the weight of that ambiguity is the one who cares the most.

And I make sure analysis has a purpose and a decision attached to it. Good analysis changes a decision, reduces uncertainty, exposes a risk, or tells the team what to do next.

Conclusion

This story isn't really about Bob. And I'm not writing this to settle a score.

I'm writing it because I still catch myself hesitating, all these years later, and that hesitation is the actual lesson. Not the billing class. Not the spreadsheet. The fact that one manager's bad call can live in your head far longer than the project ever did.

So if you're the manager now: name the lead. Trust the output. Don't ask your team to "work it out" just because it's easier than making a call.

And if you're the engineer staring at your own Bob, don't ignore what you're seeing. Bring the evidence. Ask for clarity. Escalate when the team is being affected.

But don't make your manager's judgment the only thing you trust.

You're allowed to be wrong about someone.

You're also allowed to be right.

If you are curious about the "eventful" trip to New York, I talk about it more in Episode 17 of Chaotic Commits.