The founder every decision came back to

Founder: Alex, founder of an established software and IT services business with a small team and team leads (first name used with his written permission; surname and company withheld). Stage: Established, client delivery running through a team of under ten. Work: Three rounds across 2025 and 2026: a four-week working block, an eight-week Operational Reset Sprint, and a two-month program we decided not to start. Result: A lightweight operating system in place, loss-making side projects closed, and his operations lead now running the client-team interface directly. He reports it runs better. The business does not yet run without him, and this write-up does not claim it does.

What he thought was wrong

A slow team. Delivery he couldn't predict. Too many projects at once.

In his own words, written afterwards: "Endless chaos from too many projects with the wrong people, combined with my inability to let go." Whole workdays went to paralysis. Decisions stalled because nothing was simple enough to decide with a clear head.

What was actually happening

Every problem had two routes back to him.

If someone on the team cleared a decision with the wrong person and it went badly, it bounced to Alex. If a process broke, it landed on Alex too. It didn't matter where a problem started. He was the switch everything ran through.

That pattern was older than this business. People had always brought him everything, because he had always said yes. The team had learned the most reliable way to get an answer, and the answer was him.

Some of the projects also weren't making money. So the first move was cutting, before any optimizing. By spring 2026 the side projects that weren't paying were gone.

What we built, and where it stalled

The sprint started with an audit of workflows, work in progress and who owned what. Out of it came a light operating system: a meeting rhythm, boards, a retro format, a handover guide, and three sessions with his team leads to roll it out.

It worked on paper. Then the gap showed.

Nobody inside the team owned making the system run. Alex was still the person who had to keep it going, so the dependency moved around without getting smaller. A process document can't change who a team brings its problems to. Somebody has to hold the new routine while the old habit tests it.

What moved it

On a visit to the team, he handed his de facto operations lead direct responsibility for the interface between the client and the team. No new framework. One person who already did most of the work now owned it.

By his account it has run better since. In our terms, one decision that used to route through Alex stopped routing through him.

The engagement we didn't start

In spring 2026 we scoped a two-month program to take him off the critical path before a long stretch away from the team.

The decision call surfaced something bigger than the team setup. The part of the business we would have built it for had an open structural question that sat outside anything a team routine could solve. Building an operating system for it first would have been the wrong order. We said so, named what was already sunk, and put walking away on the table next to fighting for it.

We stopped there. No program. The relationship stayed warm.

What he says now

On what surprised him: "That it makes sense nothing could run properly anymore at that point."

On what changed: over time he practiced setting boundaries, saying no, and cutting off connections that only cost energy, and he chose to accept more risk of not meeting other people's expectations, real or assumed.

To another founder: "The investment in clarity is a key to focus, and focus is the key to success."

Why this one is here

You hire leads so the company depends less on you. Alex had leads. It still depended on him.

The leads were capable. The setup they were working in sent everything back to the founder, and a new process didn't change that on its own. One handover of real ownership did more than the handbook. And sometimes the useful call is the one that says don't build this yet.

---

Attribution note: Alex gave written permission to be named by first name only, on LinkedIn, in referrals and on iamtrung.com, and approved this case study. Quotes are from his written testimonial (September 2026), translated from German by Trung. No session recordings or private details are quoted.