The First 30 Days: How I Diagnose a Technology Organization

I'm Tom Lang — I've built and scaled engineering organizations for three decades, from startups to 250-plus engineers and through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

Every engagement I take starts the same way: with a fixed-scope Technology Diagnostic. I've written elsewhere about why it's the mandatory front door — the triage desk that tells you which kind of help you actually need. This post is about what happens inside it. Because a diagnostic done well isn't an audit; it's the difference between a consultant and a CTO, and it comes down to what you look at, in what order, and what you're really trying to learn.

The one question I'm answering

People assume a technical diagnostic is about finding bad code. It isn't. There's exactly one executive question I'm there to answer:

Can your current engineering engine actually drive your specific business goals — and if not, what are the exact roadblocks we have to remove immediately so it can?

Everything I do for 30 days serves that question. The deliverable is a reality check that bridges the gap between the founder's financial and growth goals and the codebase's physical limitations — because that gap, not code quality in the abstract, is what's actually holding the company back.

The sequence: business first, code last

Here's the rule that separates a CTO from an auditor: if I start with the code, I'm just an auditor. If I start with the business, I'm a CTO. So the order is deliberate, and it never changes:

The business reality. What is the CEO actually trying to achieve in the next twelve months? Raise a Series B? Cut cloud spend 40%? Survive a 10x traffic spike? Prep for acquisition? Until I know the target, nothing technical has anything to be measured against.
The people and culture. Who holds the institutional knowledge? Who's burnt out? Who's the brilliant jerk holding the roadmap hostage? Most of the real problems live here.
The delivery mechanics. How does code actually ship? I look at CI/CD, pull-request bottlenecks, and deployment frequency to find where the friction really is.
The architecture and code — last. I look at the tech last, and I use the codebase and the telemetry to validate or disprove what the humans told me in steps 2 and 3. The code is evidence, not the starting point.

Why it's 70% people

That order reflects a deeper split: a diagnostic is roughly 70% people and process, 30% code. It surprises founders who expected me to disappear into the repo. But code is just frozen human thought. Conway's Law has held true my whole career — a system's architecture inevitably mirrors the communication structure of the team that built it. So the fastest way to understand why the software is the way it is, is to understand the people who wrote it.

Which means I spend most of the 30 days in 1-on-1s — listening to engineers vent, watching how product managers write specs, talking to the CEO. Then I spend the remaining 30% in Jira, Git history, PR reviews, and the telemetry, checking whether the data matches the stories I've been told. That comparison usually tells me who was right and who was managing my perception.

What I refuse to do in the first 30 days

This is where I prove I'm a seasoned executive and not a reactive consultant — by what I won't do yet. In the first 30 days I explicitly refuse to:

Fire anyone. Unless I uncover active sabotage or gross negligence, I don't terminate a soul before I understand the system's dependencies. The person who looks expendable is sometimes the only one who understands the payments module.
Order a rewrite. No "burn it down and rewrite it in Rust" declarations. I work with the stack you have until I've earned the right to say otherwise.
Write code. I don't take tickets off the backlog or ship production code. I'm there to fix the factory, not work on the assembly line.
Promise roadmap dates. I won't commit to new delivery dates until the diagnostic has shown me the team's true, unvarnished velocity. Committing before I know it is how consultants lose credibility in week two.

Restraint in the first 30 days isn't passivity. It's the discipline that makes the eventual recommendations trustworthy.

What you get on day 30

At the end, you get a blunt, highly actionable written document — no jargon, no hedging. Three parts:

The unvarnished truth. A clear statement of the actual root problems, which are usually not the ones you were told about. Something like: "Your site isn't slow because of your database. It's slow because your lead developer refuses to let anyone else review code, which has created a massive bottleneck."
The 90-day attack plan. A prioritized list of what has to happen next — first to stop the bleeding, then to align the technology with the business goals from step one.
The gear recommendation. The explicit close: exactly which kind of engagement it'll take to execute the plan. "To run this transition you need an Interim CTO for the next three months, after which we dial down to Fractional." (That's the gears framing again — the diagnostic is what tells you which one you're in.)

Here's the part I'll say plainly: the Diagnostic is a paid audition. By the end of it, I understand your business better than you understand your own technology — and that's exactly the proof you want before you hand anyone the keys to your engineering org.

The honest goal

That's the first 30 days: business before code, people before repos, restraint before action, and a blunt plan at the end. If your engineering engine and your business goals feel out of sync — and you're not sure whether the problem is the tech, the team, or the process — that's exactly what the Diagnostic is built to find out. Book a call and we'll start there.