After a company acquisition, I found myself working under a new management team. All of them came from the acquiring company—and almost all of them had hardware backgrounds. They were competent leaders: experienced, confident, and used to managing complex product development. But they didn’t understand software.

That distinction matters. Moving from software to hardware leadership is absolutely possible; many have done it well. But the other way around is much harder. Software development requires a different mindset. It’s iterative. It relies on judgment. It accepts uncertainty as part of the process. Trying to manage it with hardware instincts—demanding full validation, fixed sequencing, and constant control—tends to create friction, not progress.

That’s what happened. Every technical proposal had to be defended in full detail. Even straightforward decisions were challenged. Engineers with ten or fifteen years of experience found themselves second-guessed by people who had never worked in software—and who didn’t seem interested in learning.

At one point, I built a PowerPoint presentation to explain the need for version control across multiple delivery tracks. It wasn’t a technical presentation. It used pictures of cartoon children—smiling or angry—to illustrate good and bad practices. Not because I thought it was clever. But because it was the only way to cut through the noise. It was the only way to be heard in a room that no longer trusted the people doing the work.

That was the lowest point in my professional life. I wasn’t simplifying to clarify. I was dumbing down to survive.

And still, it didn’t work.

There were good people in that organization. Skilled, thoughtful, and determined to make things work. But the environment didn’t support them. The system didn’t trust its own experts. And over time, that trust eroded everything else. Execution slowed. Frustration grew. Eventually, I left. Not long after, the company exited the entire business line. It had become unsustainable.

I still think about that failure. Not because I regret leaving—but because of what it cost. The people who stayed behind. The wasted potential. The energy and commitment that could have built something excellent, if only the environment had let it happen.

What I learned—and what I’ve seen again since—is that when leadership doesn’t trust what it doesn’t understand, the damage is structural. You don’t just slow down. You lose momentum. You lose people. Eventually, you lose the business.

You don’t need to know everything. But you do need to know when to listen.
And if you’ve hired capable people, your job isn’t to prove them wrong.
It’s to make sure they can do their work.

software leadership, organizational trust, tech acquisitions, culture clash in tech, engineering management, hardware vs software mindset, scaling software teams, executive decision-making, leadership failure, micromanagement in tech