In the first three sessions, the work was about diagnosis: what was breaking, where the time was going, and who was carrying what shouldn’t have been theirs to carry.
By session four, the diagnosis was mostly done.
And the harder question was just getting started.
Marcus came in with the role map finished.
Every critical person at Meridian Financial and Hargrove & Associates accounted for. Every dependency stress-tested against the same question: if this person disappeared for thirty days, what stops in week one, week two, week four? And for each one, the smallest thing that could reduce that risk.
It was thorough work. Honest work. And as they moved through it—Ryan at Meridian, Daniel at the authentication layer, Kevin in governance approvals, Sandra at Hargrove, Claire in billing—the same pattern kept confirming itself. Knowledge concentrated in individuals who hadn’t been asked to share it. Processes that only worked because a specific person was carrying them. Organizations that had built themselves around people instead of systems, and were one departure away from finding out how fragile that was.
None of it surprised Marcus anymore.
What surprised him was something else.
“How much more organizational issues there are that—that’s not my job.”
He paused.
“It’s like I’m trying to solve problems that aren’t my problems.”
Three sessions of homework had led him here. Not to a list of fixes. Not to a roadmap. To a recognition that had been sitting underneath everything from the beginning, waiting to be named.
He had been absorbing costs that didn’t belong to him. At Meridian. At Hargrove. For months, maybe longer. Not because he was careless about his own time. Because he was the kind of person who saw a gap and filled it—who couldn’t watch something break and walk away from the wreckage.
That’s not a productivity problem.
That’s an identity problem.
And it was about to become the subject of the session.
At some point in the conversation—no announcement, no dramatic pivot—Rob stopped asking about Marcus’s clients.
And started asking about Marcus.
Specifically, about Apex Systems. What it was built to do. What it was actually doing. And whether those two things were the same.
They weren’t.
Marcus had described Apex Systems the way most founders describe their companies in the early years—broad strokes, maximum flexibility, minimum constraint. Software QA and testing. Custom development. Technology consulting. Healthcare practices, small businesses, companies needing help. Custom projects, hourly consulting, development contracts.
Every service. Every customer. Every revenue model.
Which is another way of saying: whoever needs us, whatever they need, however they want to pay.
Rob let that sit for a moment.
“By the time you get to the third bullet point, it’s basically everybody.”
Not a criticism. An observation. But the kind of observation that lands differently when someone says it out loud in a room where you’re trying to figure out why your business keeps putting you in the middle of other people’s problems.
If you’ll do anything for anyone, you’ll end up doing everything for everyone.
Then Rob asked the question that changed the shape of the conversation.
Not what Apex Systems offered. What Marcus actually did.
The answer that came back wasn’t what Marcus had been saying.
What he actually did, mapped out honestly: discover requirements, map business processes, identify bottlenecks, design workflows, create documentation, build automation, translate business needs into systems.
And underneath all of it, the through-line that connected every project he’d ever worked on:
“Coding is often the final 20%. The first 80% is understanding the business.”
He’d been describing himself as someone who builds software.
But what he actually did was understand businesses well enough to know what needed to be built—and then build it. Those are related skills. They are not the same job.
Rob named it directly.
“Maybe you’re not someone who builds software. Maybe you’re something else. And the things you’re actually doing—where your real value lives—maybe that’s what you should be leading with. Stop trying to say you’re someone who builds software, and instead say you’re someone who does whatever the other thing is.”
Marcus heard it.
“Yeah.”
One word. But the kind of one word that means something shifted.
The work Marcus had been doing at Meridian and Hargrove—the parts that were draining him most—wasn’t really software work. It was organizational work. Process work. Walking into systems that had been running on memory and workarounds and making them legible. And he’d been doing it as a contractor, billing for the visible part while the invisible part went largely uncompensated.
That gap—between what Marcus was being paid for and what he was actually delivering—was where the real cost had been accumulating.
Which brought them to the question Rob sent him home with.
What should Marcus stop doing?
The list Marcus had built was already honest: stop acting as a QA department for clients, stop carrying testing responsibilities, stop solving organizational problems he didn’t control, stop supporting infrastructure he didn’t sell, stop performing unpaid requirements discovery.
But it was the final line that carried the weight of everything.
“I need to stop being the person who rescues every project.”
He said it plainly. Not with frustration. Not with relief. With the quiet recognition of someone who has finally named something they’ve known for a long time but couldn’t quite say out loud.
That line didn’t come from the homework. It came from Marcus.
And that’s exactly why it mattered.
Because knowing something intellectually and being able to name it out loud are two different things. The first keeps you stuck. The second gives you something to work with.
The session was running short on time when Rob landed the final question.
“Describe for me the ideal customer for Apex Systems. And I’m not talking about number of employees or annual revenue. I’m talking about—based on everything you’ve learned from this engagement—what does the organizational framework of an ideal customer look like?”
Marcus went quiet for a moment.
“That’s what I’m still trying to figure out.”
Which was honest. And exactly the right place to be.
Because the answer to that question—what kind of organization is actually a good fit, what Marcus is genuinely good at, what he wants to be doing—wasn’t something that could be answered before the diagnosis was complete. You can’t define the right client until you understand what you’re actually offering.
And for the first time in four sessions, that picture was starting to come into focus.
Not as someone who builds software.
But as someone who understands what needs to be built—and why—before a single line of code gets written.
That’s a different thing entirely.
Most owners think the problem is finding more clients.
Often the problem is being clear enough about what you do that the right clients can find you.
Next week Marcus returns with a clearer picture of what Apex Systems actually is—and what it should stop pretending to be.