"Is it done?"
"Almost."
Six weeks later, same question, same answer. The founder cannot tell if the engineer is stuck, lying, or simply right that it takes this long. There is no way to open the file and check. There is only the word "almost," repeated on a rhythm that has stopped meaning anything.
I have sat on both sides of that exchange: as the engineer giving the vague answer early in my career, and later as the person a non-technical founder brought in because they could no longer tell whether "almost" meant tomorrow or never. The founders who handle this well are rarely the ones who taught themselves to read code. They are the ones who learned what to watch instead.
The scene above is a composite, drawn from several founders I have advised. The pattern is real even where the exact conversation is not.
The Real Problem: You Are Managing an Output You Cannot Inspect
Most management advice assumes you can check the work. A sales leader can listen to a call. A non-technical founder cannot open the code and see whether it is good, because code does not reveal itself to inspection without years of training you do not have time to acquire.
That leaves two bad instincts: trust completely and stop asking, or pile on status updates and meetings you cannot evaluate. Both try to solve a reading problem with more attention instead of different evidence.
The fix is learning to read the things around the code: what ships, how often, what breaks, and how people talk when something is wrong. None of that requires a technical background. It requires a system, because without one a talented engineer looks a lot like a smart person who is not being productive, for reasons that have nothing to do with talent.
What You Can Observe Without Reading a Line of Code
Working demos, on a schedule you did not have to chase. A feature shown to you running, on a cadence set in advance, tells you more than any status report. It is the difference between someone describing progress and someone showing it.
Deploy frequency. How often anything reaches production or a real test environment. A team that ships in small pieces, often, is telling you something true about how the work is organized. A team that goes silent for weeks and then delivers one enormous change is accumulating risk you cannot see until it lands.
Incident count, and what happens after one. Every team has things break. What matters is whether the same thing breaks twice, and whether anyone can tell you, in plain language, what changed. A team with zero incidents ever reported to you is not a team with zero incidents. It is a team not telling you about them.
How questions get answered. This signal is social, not technical, which is why founders miss it. Ask a direct question, then listen for specificity, not confidence. A specific answer has texture: names, tradeoffs, a reason. A vague answer, however confident, is smooth all the way through, the same test I use for evaluating a demo handed to a non-technical founder.
Defining Done in Outcomes, Not Code
The highest-leverage habit for a non-technical founder is writing down what "done" means before the work starts, in terms you can check yourself. Three examples, because the pattern only becomes usable once you see it applied.
Not: "Build the signup flow." Instead: "A new user can create an account, receive a confirmation email within two minutes, and land on a working dashboard, using a real address I test myself." You do not need to see the code. You need to try it and watch it work, or fail, in front of you.
Not: "Make the app faster." Instead: "The main dashboard loads in under three seconds on a normal connection, timed with a stopwatch on my own laptop, not described to me as fixed." Speed is a number you measure with a clock, not a code review.
Not: "Handle payments properly." Instead: "A customer can pay, receive a receipt by email, and see the charge reflected in our own records within an hour, tested with a real small transaction." This one doubles as a security check: gaps here are where the expensive surprises live, the kind an audit of an AI-built product turns up.
All three share the same shape: a test you run yourself, with your own hands, without anyone explaining what happened. "Done" is not a description. It is a thing you can try.
The Weekly Cadence That Replaces Reading the Code
One good habit, repeated every week, does more for your ability to lead engineers than catching up on technical vocabulary. Three pieces, none of them long.
A weekly demo, fifteen minutes, same time every week. Not a slide deck. Something running, clicked through live. Nothing to show two weeks in a row is itself the finding.
A short written plan, one page, updated weekly. What shipped, what is planned next, what is blocked. You are not evaluating the technical content. You are checking that the plan and the demo line up. When they consistently do not, that gap is what needs your attention.
A short daily signal, two or three lines, asynchronous. What I worked on, what I am stuck on, what I need. It makes "stuck" visible the day it happens, instead of six weeks later when the founder finally asks and gets "almost" for the fifth time.
This cadence is deliberately light. It is not a quality system; a founder who tries to be the only quality gate learns that the hard way. It is the minimum structure that turns "trust me" into "watch me," on a schedule nobody can quietly let slip.
Trust Signals Versus Red Flags
The same cadence surfaces a pattern in how people communicate, long before it shows up as a missed deadline.
| Trust signal | Red flag | |---|---| | Says "I don't know yet" and names when they will | Says "should be fine" about something unchecked | | Raises a problem before you ask | Only discusses problems when confronted | | Explains a tradeoff unprompted, in plain language | Gets more technical exactly when pushed for detail | | Estimates shift gradually, with a stated reason | Estimates stay flat for weeks, then collapse at once | | Welcomes a second technical opinion | Resists outside review, framed as "they won't get it" | | Demo shows something new most weeks | Demo repeats last week's version, almost exactly |
None of these require you to judge the work itself. They require noticing how someone talks about their own work, a skill you already have from running the rest of the company.
What I Do Differently
The habits above close most of the gap, but not all of it. Some questions a founder genuinely cannot answer alone: will this architecture hold up at ten times the users, is this the right technology choice, is this specific answer actually a good one. That is not a discipline problem. It is a knowledge problem, and the honest fix is one senior technical voice available to answer it.
That is most of what a fractional CTO does for the founders I work with: not managing the team day to day, which stays with the founder, but being the qualified second opinion when a decision is too technical to evaluate from outside. Ask that person to explain the reasoning, not just deliver a verdict, so your own pattern recognition improves and fewer questions need the outside voice. Whether that voice should be part-time or a full technical co-founder is a decision worth making deliberately.
The Counterintuitive Part
Founders assume this structure is something they are imposing on engineers who would rather be left alone. In my experience it is the opposite. Good engineers want a clear definition of done, because ambiguous done turns a good week into a bad conversation later. They want a demo cadence, because showing beats summarizing. They want structured attention, because the alternative is not freedom. It is a founder checking in anxiously at random moments, worse for everyone.
The engineer who quietly disengages rarely got too much structure. Far more often, structure was missing, and the person filled the gap with guesswork, guessed wrong more than once, and stopped trying. That is the failure mode behind why a first engineering hire quits within a few months: oversight with no shared definition of what it was checking for.
What to Do Tomorrow
-
Write one definition of done, this week, for whatever is in progress. Make it something you can personally test, not something you take someone's word for.
-
Schedule the weekly demo as a standing calendar event, starting next week. Fifteen minutes, same time, something running on screen. Nothing to show twice in a row is data, not an accident.
-
Ask one direct technical question in your next conversation and grade the answer on specificity, not confidence. You are listening for texture, not correctness, and you can hear the difference either way.
Frequently Asked Questions
How do I manage engineers if I have no technical background at all? You manage what you can evaluate: whether something demonstrably works, how often it ships, whether problems get raised early, and whether answers are specific or vague. That takes a weekly cadence and a written definition of done, both skills you already use elsewhere in the company.
Should I hire a technical advisor even if my engineers seem trustworthy? Trustworthy people still make wrong technical calls, not from dishonesty but because judgment on unfamiliar tradeoffs takes specific experience. An advisor is not a sign of distrust. It is insurance against the narrow set of decisions that are genuinely too technical to evaluate any other way.
What is the fastest way to tell if an engineer is stuck versus stalling? Watch the daily signal, not the weekly demo. Someone stuck says so specifically: what they tried, what did not work, what they need. Someone stalling stays vague across several days, with the same non-answer repeated.
How often should a non-technical founder review engineering work? Weekly, in a fixed, light cadence: one demo, one written plan, short daily updates. More often becomes anxious hovering. Less often lets misunderstandings compound into the kind of six-week "almost" that opened this piece.
If you are leading engineers without a technical background and want a second, qualified opinion in the room, Fractional CTO & Technical Advisory is built for exactly that, and a diagnostic call is the place to start.