You hired a developer. They seem capable. They show up to calls, they talk about what they’re working on, and every week they tell you things are going well. The problem is you have no way to verify any of it. You don’t know if three weeks for a feature is fast or slow. You don’t know if the code they’re writing will hold up. You don’t know what questions to ask that would even surface a problem.
The good news is that you don’t need to read code to manage developers well. You need to manage outcomes, not activity — and outcomes are visible even without technical knowledge.
The Shift: Measure What Ships, Not What’s Happening
Most non-technical founders default to measuring activity: How many hours did they work? How many commits did they make? Are they responsive on Slack? These feel like proxies for progress but they’re not. A developer can be visibly busy for weeks while making no real progress, and a great developer can ship something significant in two focused days.
The right question is: what exists now that didn’t exist last week?
That means every week there should be something you can see, test, or point to. A working feature, even a rough one. A fix that resolves a bug you were tracking. A decision made and documented. If you’re consistently getting updates about what someone is working on rather than what they’ve completed, that’s the first signal worth paying attention to.
The Questions That Work in Any Standup
You don’t need technical knowledge to run a useful check-in. You need three questions asked consistently:
What did you finish since we last talked? Not “what are you working on” — what is done. Done means you can look at it, use it, or hand it to someone else.
Are we still on track for the deadline we agreed on? If not, what changed and how does it affect the plan? Timeline slippage is normal. Undisclosed timeline slippage is a management problem.
Is there anything you’re concerned about that I haven’t asked? This question does more work than most founders realise. A developer who is paying attention to your business will flag things you didn’t think to ask about. One who is just executing tasks will answer only what’s asked.
What Good Looks Like Without Reading the Code
A well-run engineering relationship has a few observable characteristics that don’t require technical knowledge to spot.
You can always see something. Good developers default to showing work in progress. Rough demos, screenshots, links to staging environments. If every update is verbal and you never get to interact with what’s being built until it’s “done,” something is off.
Estimates come with reasoning. When a developer tells you something will take two weeks, they should be able to explain the main variables: what the work involves, what could make it faster or slower, what they’re uncertain about. An estimate delivered without explanation is a guess delivered with false confidence.
They push back sometimes. A developer who agrees with everything you suggest is not helping you. Good developers tell you when an approach won’t work, when your timeline isn’t realistic, or when a feature is more complex than you’ve scoped. No pushback ever is a sign they’re telling you what you want to hear.
They can explain what they built in plain English. Not every detail, but the main idea. If a developer can’t describe a feature clearly to someone who doesn’t code, that’s either a communication problem or a sign that what they built isn’t as clean as it should be.
The Red Flags That Don’t Require Technical Knowledge
Some warning signs are visible without any technical background.
“It’s almost done” stays the answer for more than one check-in. Almost done should resolve into done within a week. If it doesn’t, something is being managed around rather than fixed.
Estimates keep growing without a clear explanation. Some scope changes are legitimate. A feature that grows from one week to three without an explanation of what changed is a pattern worth addressing directly.
You can’t test anything. If you’ve been told something is ready but every time you try it, it’s broken or not quite there, the definition of “ready” is different for them than for you. That gap needs to be made explicit.
They can’t answer questions about what they’re building without getting technical. Complexity is real, but a good developer can navigate between the technical reality and the plain-English version. If every question gets answered with jargon, either they don’t have a clear picture of what they’re doing or they’ve learned that jargon stops questions.
You feel like you’d be the last to know if something was wrong. Trust your instinct here. If the relationship has a quality of being managed rather than collaborated with, that feeling usually has a source.
The Bus Factor Test
Here’s a practical way to assess the health of any developer relationship: if this person left tomorrow with no notice, how long would it take another developer to understand what they built and pick up where they left off?
If the honest answer is weeks, that’s a yellow flag. If the honest answer is “I have no idea” because there’s no documentation, no clear structure, and no one else who has looked at the code, that’s a red one.
A developer who builds things only they understand — whether intentionally or just out of habit — creates dependency that limits your options as a founder. Good code is written for the next person, not just to work today.
You don’t have to audit the code to assess this. Ask directly: if you were unavailable for two weeks, what would another developer need to get up to speed? The quality of the answer tells you most of what you need to know.
When to Bring in Outside Eyes
Even with good weekly management, there are moments when you need someone technical to verify that what’s being built is actually sound. These aren’t audits designed to catch someone out. They’re normal practice in well-run engineering teams.
The clearest trigger is when a decision is about to lock you in. Choosing how to structure your database, deciding whether to split your codebase into separate services, moving to a new infrastructure setup: these are choices that are cheap to get right early and expensive to undo later. A fractional CTO doing a periodic review — even a few hours every couple of months — can surface issues that aren’t visible from the outside and give you confidence that what’s being built will hold up. If you’re also hiring, our guide on how to evaluate developers covers what to look for when you can’t assess the code yourself.
Frame it as a normal part of how you operate, not as a vote of no confidence. “We’re growing and I want to make sure we’re building on solid ground” is a reasonable thing for any founder to say.
Managing Well Is a Skill, Not a Technical Requirement
The founders who manage developers well without technical backgrounds have a few things in common. They’re consistent: same questions, same expectations, same standards every week. They’re direct: they say clearly when something isn’t working rather than hoping it resolves itself. And they separate the work from the person: a slipping timeline or a missed expectation is a problem to solve, not a relationship to protect.
Most developer management problems aren’t technical. They’re communication gaps, unclear expectations, and the discomfort of asking direct questions when you’re not sure you’ll understand the answer.
You don’t need to understand the code. You need to know what done looks like, hold to it consistently, and be willing to bring in outside help when your instincts tell you something isn’t right.
If you’re not sure whether your current setup is working, talk to a fractional CTO. A single conversation can tell you whether what you’re seeing is normal or worth addressing.