What 25 Years of Software Engineering Taught Me About Running Any Practice

I've spent twenty-five years in software engineering — a junior engineer when I started, a principal engineer today, with more than twenty of those years as a DoD contractor building for defense programs. When people hear that, they picture the most process-bound environment imaginable — binders, boards, sign-offs on the sign-offs. Here is the part that surprises everyone:

I think that people will be shocked that most DoD programs are not run by process. And many of them are failures.

Not failures despite the bureaucracy — failures traceable to the absence of real process underneath it. That inversion is the most useful thing my career taught me, and it applies to a coaching practice, a consultancy, or any business run by people who think process is someone else's problem.

The stress flows downhill

What does "no process" actually do? It doesn't produce chaos evenly. It produces arbitrary work, and the arbitrariness lands on specific people. Untracked, untraceable tasking is comfortable for whoever assigns it — nothing is written down, so nothing can be examined — and brutal for whoever carries it, because all the stress lands on their performance against goals nobody defined.

Now translate that to a practice of one. A solo coach or consultant with no written scope and no tracked commitments is playing both roles. You are the bad manager handing yourself arbitrary goals, and the burned employee absorbing all the pressure with none of the visibility. Every guilty Sunday-night feeling that you should be "doing more" without knowing more what — that's the no-process tax.

The two-inch binder

The counter-example comes from early in my career: a system release governed by a real test procedure — a binder two and a half inches thick, a full sequence for vetting the system before every release. Two lessons live in that binder. Process trains people and creates repeatable results: a new person could walk in and produce a competent release by following it. And even mature process has gaps — every new person who picked up that binder found something it didn't cover — which is why process needs measurement to close the loop.

But the deeper lesson is personal:

I'm naturally process oriented… I like doing this stuff because it actually lets me be creative. This is where I'm creative.

That's the answer to everyone who hears "process" and pictures a cage. Process isn't the opposite of creativity. It's what buys the room for it — the structure that handles the repeatable so your attention is free for the parts that aren't.

Top shelf on a beer budget

The most common failure I watched wasn't technical. It was estimation, and it starts with optimism: rose-colored glasses in early development, under-bidding and over-scoping, nobody curating the feature list down to what the customer's resources can actually carry.

The customer wants the top shelf, but they can only afford a beer.

The thing that sinks the estimate is usually the thing that sounded small — the little add-on that turns out to coordinate everything else. And what bad estimation feels like from the inside is chronic stress: a small core of people carrying most of the work while the org chart claims otherwise.

For a coach or consultant, scope creep in an engagement is the same disease. Curating the promise to fit the budget — saying no to features of the engagement the client can't actually afford — isn't stinginess. It's the discipline that protects both sides.

If you're building something, the order matters

Two rules from watching programs succeed and fail, useful to anyone building a product or a practice. First, a too-generic statement of work hurts more than it helps: it fails to capture the full objectives, and the gap surfaces later as cost. Specificity in the agreement is cheap insurance. Second, rigor has to grow with the work. As scope grows, testing grows, requirements grow, checklists grow — and the schedule has to grow with them. That growth is what saves you in the long run.

Do the systems thinking before you build; capture lessons learned as you go. None of this is software-specific. It's what a well-run coaching engagement looks like too.

Run your AI like a dev team

The modern payoff of this old discipline: AI tools have made it possible to build and produce at remarkable speed, and most people use them with no structure at all. Unstructured prompting is fine for a proof of concept. A prototype you intend to rely on needs the same treatment as any serious project — run the tool like a team, with roles, sprints, and reviews. Treat one agent as the architect, one as the developer, one as the tester, and measure the work between them. It compounds: the structure becomes a substrate of how to do things well.

I've had to learn the failure mode personally. My instinct is to develop rapidly in a silo — and I've reached the end of a build with an end-to-end system that no potential customer had ever seen. Speed without checkpoints doesn't remove the surprise; it just moves it to the end. Now I purposely slow down.

If measurement is the part you never learned, the tool itself will teach you: set a goal, tell it to help you pursue it, and ask it to help measure your progress. One honest cost — the discipline is token-heavy. Rigor spends resources. Build processes that reduce the load rather than abandoning the rigor.

Nothing is new

Every generation of tooling arrives with the claim that the old stuff no longer matters. Most of the old stuff matters; the new thing is built on the last twenty-five years of development experience. Software rarely looks sideways at the domains next door — machine learning, statistics, forecasting — where much of the "new" work was already done. Coaches have the same blind spot. Your new methodology stands on older bones, and knowing which bones is a credibility signal, not a weakness.

The team of one

Everything above assumed an organization. Most coaches and consultants are a team of one, and the translation is blunt: you don't need a program manager, a review board, or a test lab — but you have to take on all those roles, and you have to be extremely well organized.

Four habits survive at that scale: design, implement, test, and review — plus a business-side scorecard that budgets time for learning, documenting your own processes, knowing your stakeholders, and the financials. AI can wear the missing hats — program manager, review board, even an adversarial companion — but only if you learn each role yourself first. Rely solely on the AI to make the decisions and it will make costly mistakes; the better you know what each job requires, the better the whole arrangement works.

And after a career of watching programs live and die, the biggest gap isn't any of the engineering:

Biggest problem, biggest gap today: lack of marketing. That is by far the biggest problem in all of it… As a team of one, you have to know how to do that.

An engineer telling coaches their weakness is marketing — I know how that lands. It's my own current lesson too.

Measured judgment

How do you prove good judgment to someone who can't evaluate it directly? The same way a program proves anything:

It needs to be measured judgment and not arbitrary. It needs to be systematic and follow a framework so it's complete and balanced and fair, and it needs to work ethically.

Demos and real examples. Talk a lot, share a lot, be open to criticism — let people tell you what doesn't work so you can fix it. That ladder — from claims, to someone vouching, to artifacts you can inspect, to outcomes actually measured — is the same idea this directory formalizes in its signal tiers. I didn't invent it; I watched it work for twenty-five years.

"Process kills the human part of the work"

The objection deserves a straight answer, and the answer is that it has things backwards. Processes de-stress — dramatically, including for the person raising the objection. What people are actually reacting to is rules read as black and white, and:

Rules are not meant to be black and white. Processes are there to guide you — they're about improving quality and reducing risk.

There's a real concession inside that: if your process reads as black-and-white rules, that's a bad process — or a bad reading of one — and the objection is earned. Guide rails, not cage bars. The human part of the work was never in danger from the binder. It was in danger from the chaos the binder prevents.

---

That's the conviction True North Vibe is built on: how the directory works is this article applied — evidence over assertion, measurement over vibes, and influence used in the client's interest. If you're looking for help that works this way, take the 3-minute interview or compare business coaches and operations & strategy consultants by what they can actually show.