A letter to myself, 10 years ago

Introduction: The Leadership Gap I Didn’t See

If I could go back to 2014, I would tell myself two things:

1. Start reading with a pencil in your hand.
2. Learn the fundamentals of team leadership.

I was traveling to a different location every week for 7 months where I was struggling to turn around a failing program. I didn’t recognize how much I was missing about the fundamentals of a team.

At the time, I had led several teams, but I had never kicked one off. I had basically inherited a team someone else kicked off and I succeeded in not messing them up. I had been the best engineer I could be on those teams, excelling through technical expertise – making good high-level technical decisions for a team that was already high-performing.

But I had never been asked to lead a struggling team, let alone turn one around. And so, I defaulted to what had always worked—being the smartest person in the room.

It wasn’t enough.

The issues went deeper than engineering challenges. We lacked a shared goal, communication was broken, and problems went untracked. I didn’t impose my leadership strongly enough, largely because I didn’t know where to start when I didn’t know every detail. There were so many issues, and leading them to closure was different than anything I had encountered.

One of those issues was a plastic bearing—a seemingly small problem that revealed everything that was broken about the way we worked.

The Plastic Bearing Problem: A Case Study in Leadership Failure

We were working on a mechanical control system. One of the key components in our system was a plastic bearing about the size of a coffee mug. Driven by our control motor, the position of this bearing in a tight-fitting metal housing was the basic thing the system was controlling. The bearing was made of an exotic, self-lubricating plastic called Delrin. It was an elegant solution, except for one flaw: our tolerances were quite tight which called for a Delrin with a precise heat treatment to help it maintain it’s shape. If scratched, the untreated layers underneath could absorb moisture, swell, and ultimately bind. And if it bound up, the unit would require total disassembly, which was impossible in the field. (Spoiler alert – that happened.)

This issue should have been a top priority. Instead, it was dismissed.

When I heard about this issue and explored it, I was told that the risk of scratching would be “managed by process.” They would create a special assembly instruction to ensure the bearing was handled with care during assembly. But no one ever actually created that process. And this location’s culture was a startup mindset meaning they were process-light. In this case they were charged with creating a production-worthy design. They were way out of their element and so was I.

(Another product had been returned by a customer for missing a feature described in the advertisement. “Oh we didn’t know you wanted that” was the response. Amazing.)

In hindsight, I failed to push hard enough on this issue. I didn’t feel confident challenging senior engineers who were so much technically smarter on this topic than I was.

But they didn’t need another engineer. They needed a leader.

I should have insisted on finding alternatives, on documenting a clear mitigation strategy, and on tracking the issue properly. Instead, we moved forward as if the problem had been solved, only for it to resurface when the same failure repeated itself in future builds.

What could I have done differently?

I should have made the problem visible—created a clear, visual tracking system that forced us to confront our unresolved risks. But at the time, we didn’t even have a way to track our to-dos, let alone prioritize them.

A System Without a Memory

That was the core issue: the team weren’t tracking anything.

There was no backlog. No issue tracking system. No way to ensure that problems were recorded, prioritized, or resolved.

I remember my first drive to the plant. It was October, a beautiful drive to an eastern New England state. I had been on the same project for 6 years and I was feeling excited to jump into a new project, learn some new tech.

I found the project manager, the only name I had been given. He was standing up, having just spilled a cup of coffee on a very messy desk.

Me: “Hello Bob, I’m Evan. I’ve been sent here to help. Where should we start?”
Project Manager: “I don’t understand why you were sent here, we’ve got this.”
Me: “I hear you haven’t run a project review in 3 months. I’ll take that off your plate – what are your 3 most difficult problems?”

He gave me a list.

I conducted the meeting, presented these three issues, got some advice and some resources. I returned to the project manager.

Me: “I’ve got a commitment for resources for those three issues.”
Project Manager: “We’ve just finished those.”
Me: “Oh… I wasn’t asking about your morning to-do. What is actually hard? What are you using to track your issues.”
Project Manager: Scathing, he just points to his head. He tracks the issues in his head for several million dollar development program a team of 13…

The reared its ugly head a couple months later. This issue cost us $30,000 over a $1 part.

Three separate failures, an invisible problem

I was looking over the shoulder of the software engineer at the GUI. There was a camera display with several numbers on an overlay from sensors. Temperature, GPS position, that sort of thing. There was a number in a corner of the screen I couldn’t figure out. It said “24.3 inHg”.

Me: “What’s that number on the GUI?”
Software Engineer: “That’s the pressure reading.”

I can tell you atmospheric pressure is 14.7 PSI but I couldn’t think of a unit that converted to 24.

Me: “What are the units?”
Software Engineer: “Inches of mercury.”

Me: “How do you know it’s right? Do you have a calibrated standard somewhere?”
Software Engineer: “No.”

I checked a weather app. It told me the local pressure was closer to 27 inHg, about 10% higher than the GUI was reporting.

Me: “Weather dot com tells me the local pressure is about 27 inHg. Do you know why this might be reporting 10% lower?”
Software Engineer: “It’s always been low.”

I went to our system simulator, a computer with the control algorithm in it. I gave it two pressure readings – 27inHg and then 24inHg. The difference in the algorithm output was way outside our program accuracy requirement.

This single issue would prevent the entire thing from working correctly.

I went back to the Software Engineer.

Me: “When you said this has ‘always been low’ – have you told anybody about this?”
Software Engineer: “I told my boss.”
Me: “When did you tell him?”
Software Engineer: “About 2 years ago.”
Me: “And what happened?”
Software Engineer: “I never heard back.”

Two years.

For two years, a critical system issue had existed, and no one had done anything about it. The issue never got written down. Never got prioritized. Never got solved. It had lived inside one person’s head for two years.

When we finally investigated, we discovered three separate failures:

1. The pressure sensor selected wasn’t accurate enough to maintain the system’s required precision.
   • (I later learned it always intended to be a placeholder sensor, not final. More untracked technical debt.)
2. It sensor wasn’t being powered correctly, reducing its already insufficient accuracy.
3. The wrong calibration values were being used in the software.

Three issues. A circuit selection issue, it’s integration in the hardware, and it’s integration in the software. Any one of these failures alone would have thrown off our system’s accuracy. Together, they made the system unusable.

And because no one had documented issue, we rediscovered after we had already spent $90k and 4 weeks on what was to be a final respin of the circuit board stack.

Fixing the issue required another expensive redesign—one that could have been avoided entirely if we had simply tracked our problems properly.

There were several straw that broke the camel’s back on this project. I don’t actually remember which one was finally fatal, this one was up there.

None of them were documented the day I arrived. Zero.

What I Would Do Differently

The failures in that program weren’t just technical—they were leadership failures. My failures.

If I could go back to 2014, I would:

1. Ensure everyone understood the system’s purpose and the purpose of each constituent subsystem.
2. Implement a Robust, Visual Issue Tracking System – Problems can’t be prioritized and solved if they aren’t documented.
   • I only had the resources to cludge together a SharePoint issue tracker. When I arrived there were zero recorded issues and by the time I left there were 285 recorded issues. Some were minor. Some were critical. But at least they were being tracked.
   • If a problem isn’t visible, it doesn’t exist. I would have used visual management tools—burn-down charts, priority lists, and dashboards—to force leadership to confront unresolved risks. If this were today I’d have used Jira or similar. I didn’t know this tool existed in 2014.
3. Push Harder on Accountability – When people say they’ll “manage a risk by process,” I should have demanded to see that process written down. I should have followed up relentlessly until I saw proof of execution.
4. Trust Leadership More Than Intelligence – I had spent years succeeding by being the smartest person in the room. But leadership isn’t about having the right answers—it’s about creating a system where problems are surfaced and solved. I should have focused less on solving problems myself and more on ensuring the team had a framework to solve them collectively.

Conclusion: Write It Down, Lead With Clarity

I didn’t start writing until years later, but I now realize that if I had begun in 2014, I would have figured out leadership faster. Writing forces clarity. It forces reflection. It forces structure.

And leadership requires the same things.

If there’s one lesson I’d give to my past self—and to anyone in a leadership role today—it’s this: write things down.

Write down the problems. Write down the priorities. Write down the commitments.

Because a system without a memory cannot be led. And leadership, at its core, is about ensuring that the things that matter don’t get lost.