How a profitable IoT company's biggest problem wasn't technical debt, broken pipelines, or bad tooling. It was a founder who hadn't made the transition from builder to leader — and a team that had learned it was safer to say nothing.

What They Were Experiencing

An industrial IoT company asked us to assess their DevOps and Agile practices and provide some developer training. They built software for monitoring heavy equipment — the kind of systems that keep critical infrastructure running. They had a real competitive advantage: remote firmware updates while competitors were still physically visiting equipment with USB sticks.

On paper, everything looked fine. Profitable. Growing. Self-funded with no external investors. Real customers with real contracts.

But something had gone wrong. Features were taking too long. Bug fixes felt like band-aids on top of band-aids. The development teams seemed stuck. Leadership was frustrated. The teams were frustrated right back.

When I arrived for two weeks of on-site work, what I walked into was much worse than a tools problem.

What They Thought Was Wrong

Leadership believed the problems were:

• Their Scrum process wasn't working
• They needed better DevOps tooling
• A version control migration (that had been dragging on for nearly a year) was blocking everything
• The development teams were too slow and too rigid about roles

The developers believed the problems were:

• Leadership didn't listen to them
• They never got time to fix known technical debt
• Quality was supposedly important, but the QA team had been laid off
• Every bug was a fire drill that derailed whatever they were actually trying to build

Both sides had a point. Neither side could see the whole picture.

What I Actually Found

Finding #1: Joy Had Departed

This is how I opened the findings document. Not with a technical finding. Not with a process recommendation. With this:

Something has happened at this company. Work has become a hard slog. Life and the job has become something to be endured. Joy has departed and morale is terrible.

I don't usually lead with feelings in a technical assessment. But this was the most important thing I observed, and everything else flowed from it.

The developers were defeated. Not angry — that would have meant they still cared enough to fight. They'd moved past anger into something worse: resignation. The prevailing attitude was something like: "What's the point? If I raise a concern, they're just going to ignore me — or worse, fire me. I'm just going to keep my head down."

Finding #2: A Culture of Fear Wearing a Culture of Gossip

Leadership gossip was visible from across the room. There's a posture that people adopt when they're talking about someone instead of to someone — a look of not wanting to be overheard, a look of guilt. I could see it from a distance.

The gossip was a symptom, not the disease. People gossip when they feel powerless. They vent to each other because they don't believe raising concerns through official channels will accomplish anything. At some point, venting becomes gossip and gossip becomes hopelessness. Once you're there, you're stuck in the mud.

Underneath the gossip was genuine fear. For whatever reason, the impression had taken hold that raising concerns too loudly would get you reprimanded or fired. Whether or not that was objectively true didn't matter. The perception had become reality, and it was shutting people down.

Finding #3: The Say-Do Gap

This was the structural driver of the morale problem. Leadership said quality mattered. But the QA team had been laid off, leaving a single overwhelmed tester who was largely ignored by the development teams.

Leadership said technical debt needed to be addressed. But when developers identified problems that would inevitably become production emergencies in the coming weeks, they were told to ignore them until a customer actually reported the issue. Then those same developers would have their weekends ruined fixing an emergency they'd tried to prevent.

The teams heard "quality is important" and then watched leadership ship anyway when tests were failing. They heard "we value your input" and then watched their concerns disappear into a void. That gap between what leadership said and what leadership did was the single biggest source of the morale collapse.

Finding #4: Regression Sprints Were an Excuse to Ignore Quality Now

The company had developed a practice I'd never seen before: entire sprints dedicated exclusively to regression testing and bug fixing. No new features. Just cleaning up the mess from the previous sprints.

This practice was a symptom of a deeper dysfunction. When you know that an entire regression sprint is coming, there's no incentive to deliver quality in the current sprint. "We'll fix it later" becomes the default, and later arrives on schedule every few weeks in the form of a grinding, demoralizing sprint where the team does nothing but repair their own work.

The regression sprints also created a devastating productivity illusion. Leadership saw teams "working hard" during regression sprints. What was actually happening was that the team was spending massive amounts of time undoing damage that shouldn't have been created in the first place.

Finding #5: The Founder Who Couldn't Let Go

Before I gave my findings to the full team, I had to have a separate conversation with the CEO. It was one of the harder conversations I've had in consulting, and I prepared for it carefully.

The CEO was the company's technical founder. He'd built the original system. He remembered what it was like when the company was small — when he could just jump in and fix something, and people would look at him with awe. He missed that.

So when he got frustrated with the pace of development — which was often — he'd step away from being CEO and start writing code himself, often for multiple weeks at a time. This created two problems at once, and both were invisible to him.

The code problem

There's a phenomenon that happens in technical careers that almost nobody talks about. Exceptional coders get promoted into leadership — and then their technical skills quietly atrophy without them realizing it. They stop keeping up with framework changes, new language features, shifts in deployment patterns, evolving UI technologies. They're still thinking in yesterday's approaches while their teams have moved on. It's a natural part of the transition from builder to leader, but it's not risk-free — especially when the leader still believes they can jump in and code at the level they used to.

That's what had happened here. The codebase had evolved past him. It still had his fingerprints all over it, but it had gone in new directions because of the people he'd hired. When he jumped in, it scrambled the team's work. His code didn't fit the current architecture. His approach didn't match the team's patterns. And nobody could tell him. Because of the culture of fear, the team had learned that the safest response was to say nothing, wait for him to move on, and then quietly rewrite whatever he'd done.

The leadership vacuum

While he was off writing code for a couple of weeks, nobody was being the CEO. The strategic decisions weren't getting made. The organizational problems weren't getting addressed. The culture issues that were crushing morale — the gossip, the fear, the say-do gap — were going unattended because the one person with the authority to fix them had left the bridge to go tinker in the engine room.

So every time the CEO got frustrated and dropped into the codebase, the company took a double hit: the engineering team's work got scrambled and the organization lost its leader. He was trying to solve his frustration by doing the thing he was good at — building — instead of doing the thing the company needed him to do — leading.

That single pattern — the inability to give honest feedback upward, combined with a leader who kept abandoning the helm — told me more about the organization's dysfunction than any process assessment could.

I had to tell him something uncomfortable: he was showing all the signs of wanting to grow the company into something larger, but he was still running it like a solo operator. He wanted a big kingdom but was managing it like a one-person shop. If he'd had external investors instead of being self-funded, he probably would have been replaced by now — not because he was incompetent, but because the skills that make a great technical founder aren't the same skills that lead a company at scale.

The technical problems weren't really technical problems anymore. They were culture and human systems problems colliding with business direction. And the founder was at the center of that collision.

Finding #6: The Refinement Meeting That Revealed Everything

I sat in on one of their backlog refinement meetings. I knew almost nothing about their systems — the hardware, the firmware, the back-office applications, the on-board units. I was an outsider with zero domain knowledge.

One hour, one requirement, zero estimates

An hour into the meeting, they had looked at exactly one requirement. They hadn't estimated a single item. When they finally did estimate, people shouted out numbers without any structured discussion — anchoring like crazy on whoever spoke first.

A backlog that silenced product ownership

The requirements themselves told a deeper story about the company's culture. They were written as technical tasks — implementation steps that only made sense to developers. Not "customers can view equipment status remotely" but something closer to "implement data retrieval using generics and stored procedures." The backlog read like a developer's to-do list, not a product roadmap.

This was both a symptom and a cause. It was a symptom of the company's tech-centric culture — the same culture where the CEO still thought of himself as a coder. But it was also causing a problem that nobody had connected back to it: the product owners couldn't do their jobs.

When your backlog is written in technical jargon, the people responsible for product direction can't tell a coherent story about where the product is going. They can't advocate for feature directions to leadership. They can't communicate priorities in language that anyone outside the development team can understand. In a company that was already bad at listening to each other, their primary planning artifact was unreadable by anyone who wasn't a developer.

It was no surprise that product owners were regularly overruled on prioritization. Some of that was the cultural dysfunction — fear, hierarchy, the CEO's gravitational pull. But some of it was simpler: when you can't clearly articulate what you're building or why it matters in language that leadership understands, you lose every prioritization argument to whoever talks loudest.

The product owner was doing all the questioning in the meeting, which is backwards. The team should be interrogating the requirements, not the product owner. But the requirements were so technically oriented that the product owner barely had the vocabulary to participate, let alone lead.

The seams an outsider could see (but the teams couldn't)

Here's what struck me: even knowing nothing about their domain, I could see where the requirements logically broke apart into meaningful, deliverable pieces. The seams were visible. A requirement that the team was treating as one large, intimidating chunk was actually three or four smaller pieces separated by natural boundaries — different user types, different data flows, different acceptance criteria.

The team couldn't see the seams because they were too close to the implementation rather than the actual business problem. They'd been living inside the complexity so long that they'd lost the ability to step back and ask "what's the smallest piece of this that delivers value?" And the product owners couldn't help them see it because the backlog had been written in a language that excluded them from the conversation.

That's a skill problem, not a knowledge problem. And it's fixable.

Finding #7: A $100,000 Dime Holding Up a Dollar

The company had been trying to migrate their version control from one system to another for nearly a year. The holdup: they were paying roughly $100,000 to a firm to build a custom tool that would migrate their entire source control history to the new system.

This migration was blocking every DevOps improvement they wanted to make. Automated builds, automated releases, traceability, quality gates — all of it was waiting on this history migration that might not even work when delivered.

The proverbial "dime holding up a dollar". The version control history was nice to have but the process & delivery improvements it was blocking were essential. My recommendation was to cancel the migration contract, do a simple "tip" migration (just move the current code, leave the old system running as a read-only archive for a few months), and start making progress immediately.

The Diagnosis

This company's biggest problem wasn't Scrum, wasn't DevOps, wasn't their tools, and wasn't their architecture. Their biggest problem was that the people doing the work had stopped believing that things could get better — and the person at the top was unknowingly reinforcing that belief every time he jumped in to write code.

The morale collapse wasn't caused by one thing. It was caused by the accumulation of say-do gaps: quality proclaimed but QA eliminated, technical debt acknowledged but never prioritized, developer concerns heard but never acted on, good ideas proposed and then quietly dropped. And at the center of it all, a founder who hadn't made the transition from builder to leader.

One moment from my notes captures this perfectly. During a discussion about branching strategy, a tech lead said something like: "Wait — wasn't this exactly what we proposed twelve months ago?" The room gave lukewarm agreement. The impression was unmistakable: even when we identify good, implementable ideas, nothing ever happens with them.

That moment of defeat — of "why bother suggesting anything" — is what it looks like when an engineering organization stops believing in itself.

I told the CEO something that I've since repeated in conference talks: there's an arc to technical careers. You start out as Han Solo — master of your own small ship, highly talented, doing everything yourself. That works brilliantly when the ship is small. But at some point, if the company grows, you have to decide whether you want to become more like Jean-Luc Picard — someone whose core job is leadership, not engineering. Picard's boring compared to Han Solo. But Picard's ship has a thousand people on it, and it works.

This founder wanted the big ship but was still trying to fly it like the Millennium Falcon.

My recommendations focused on fixing the human system first. Truly adopt Scrum — not as methodology theater, but as a forcing function for transparency, honest feedback, and small achievable wins. Stop doing regression sprints and bring quality expectations into every sprint. Close the say-do gap by aligning resources with rhetoric — if quality matters, fund QA and make time for automated tests during development. And for leadership: stop gossiping, stop confusing aggression with strength, and start embodying the culture you say you want.

The Lesson

Every technical crisis I've ever walked into was actually a leadership and communication failure wearing a technical costume.

This company had real technical problems — brittle code, missing tests, outdated tools, an architecture that wasn't ready for the next ten years. But none of those problems were going to get fixed by an organization that had lost the will to try.

The developers weren't disengaged because they didn't care. They were disengaged because they'd been taught — through repeated experience — that caring was pointless. Fixing that required leadership willing to close the gap between what they said and what they did. And it required a founder willing to ask himself the hardest question: am I still the right person to lead this company the way it needs to be led now?

This engagement changed how I think about technical leadership. The patterns I saw — the founder who couldn't let go, the culture of fear masquerading as high standards, the teams that had stopped believing improvement was possible — kept showing up in company after company. I eventually turned the lessons into a conference talk about the transition from individual contributor to leader. The core question from that talk still holds: do you want a big ship or a small one? Either answer is fine. But you can't captain a starship the same way you fly a smuggler's freighter.

The technical problems were fixable. The culture & communication problems were harder. But the question was whether anyone still believed they could be fixed.

If your team used to care and now they just go through the motions — if concerns get raised and quietly disappear — if good ideas get proposed and nothing ever happens — if someone at the top is still trying to do everyone's job because they can't let go — you might not have a technical problem at all. You might have a leadership problem wearing a technical costume.

That's the kind of problem I help companies see clearly.