You don't manage developers by reading their code. You manage outcomes, access and a handful of signals, and that's enough to surface many problems early. Three habits cover it: hold the admin keys to everything the company depends on, read a weekly demo plus a few numbers, and buy a second technical opinion when the signals conflict.
This assumes the team, freelancer or agency already exists and is building. It sits alongside the other early-stage guides in Startup CTO guides: leadership, diligence and the first hires.
What should you own from day one?
The accounts. Every system your product runs on should sit in the company's name, with you or a co-founder as an owner and the developers holding a lower role. Developers can do their work from a member seat with access to the repositories they work on. They don't need to own the account.
GitHub's documentation says organization owners have complete administrative access to an organization, and that the owner role should be limited, but to no less than two people. Two is the point. One owner is a single point of failure, and a former contractor holding the only owner seat is a bad week waiting to happen (that reasoning is our judgment, not GitHub's).
AWS's root user guidance asks for a business-managed email address that forwards to a group, so the account survives people leaving. It requires multi-factor authentication, advises against access keys for the root user, and says no one person should hold both the email inbox and the phone used for recovery. Day-to-day work should go through an administrative user, not root.
Apple's developer program documentation says whoever enrols becomes the Account Holder. For an organization, that person renews the annual membership, accepts legal agreements on the company's behalf, adds the first Admins and approves banking changes. Paid apps and in-app purchases also need the Account Holder to sign the Paid Applications Agreement. If a freelancer enrolled in their own name, they are the Account Holder, and renewals, legal agreements and banking changes run through them rather than the company.
| Account | What you hold | What the developer gets instead |
|---|---|---|
| Code repository (GitHub organization) | Owner role, at least two owners | Member role, with access to the repos they work in through a team |
| Cloud (AWS) | Root user, group email, MFA | An administrative user for daily work |
| App store (Apple Developer) | Account Holder | App Manager or Developer role (our judgment on which fits) |
| Domain and DNS | Registrar login in the company name | Access to DNS records only if they need it |
| CI and error tracking | Billing owner | Team member seats |
The last two rows are our judgment, not vendor guidance, but the logic is the same. If any of this is already in someone else's name, get it transferred to the company before anything else on this page.
What does a good week look like?
Boring and regular. Three things, 30 minutes, the same day each week (the time is our judgment, not a standard).
The first is a demo of working software, shown to you. The Scrum Guide says the purpose of the sprint review is to inspect the outcome of the sprint and determine future adaptations, and that the team presents the results of its work to key stakeholders. You're the stakeholder. A demo of something you can click beats any status slide, because you can see whether last week's promise exists.
The second is a short written update with five lines: shipped, blocked, next, risks, and one line on what slipped and why. The last line matters most. Teams that can say "this slipped, here's the reason" are usually fine. Teams that never report a slip are worth a question.
The third is a decision list: the two or three things the team needs from you this week, with a date. Slow founder decisions look like slow developers from the outside, and a visible list keeps both sides honest.
Which numbers can you read without code?
DORA defines five software delivery metrics on its metrics guide. Three measure throughput and two measure instability. You don't compute them. You ask the team to report them each month and watch the direction.
Change lead time is how long a change takes to get from committed in version control to deployed in production. Deployment frequency is how often the team ships to production. Failed deployment recovery time is how long it takes to recover when a deployment goes wrong. Change fail rate is the share of deployments that cause a failure needing a fix. Deployment rework rate is the share of deployments that are unplanned and happen because of an incident in production. For exact definitions and benchmark figures, see how DORA metrics are defined.
For a team of two to five, treat these as trends, not targets. A lead time that creeps from two days to eight over a quarter tells you something. A single number compared with someone else's benchmark tells you little. That's our judgment.
Add two signals that aren't part of DORA, also our judgment. Scope carried over: how much work rolls from one sprint into the next. And bugs reopened: how often something marked fixed comes back. Both are cheap to count in any tracker, and a rising trend in either is worth a question.
Red flags you can see without reading code
None of these proves anything alone. They're our judgment, each paired with a question to ask.
"Almost done" for more than one demo. Ask: "What exactly is left, and can I see the finished part today?"
Nothing to demo. Weeks of work, no working software. Ask: "What can I click on by Friday?"
Estimates that slip by the same ratio every time. If everything takes twice as long as quoted, the estimate method is broken, not the individual task. Ask: "What have we learned from the last three estimates?"
One person who is the only one who can deploy. That's key-person risk. Ask: "What would break if you were out for two weeks?"
Reluctance to give you admin access or documentation. Ask: "Can I have owner access to the repository this week?" A reasonable developer says yes before you finish the sentence.
Defensiveness when you suggest a second opinion. Good engineers like review. Ask: "Would you walk an outside reviewer through the code?"
When should you buy a second opinion?
Our triggers, all judgment: two red flags in the same month, a proposal to rebuild from scratch, a quote that doubled, or a funding round or contract renewal coming up. Any of those and you're making a large decision on a story you can't check.
You have three options.
| Option | What you get | Best when |
|---|---|---|
| One-off independent review | A written deliverable: ranked findings, no retainer | You need an answer to one question, such as "is this rebuild necessary?" |
| Fractional CTO | Ongoing technical decisions and a sparring partner | The questions keep coming and you'd rather not keep buying reviews |
| Senior engineer added to the team | An in-team reviewer who also ships | The team is thin and a reviewer would otherwise be idle most weeks |
We found no published price for a review-only engagement, so we won't quote one. Ask for quotes. For the ongoing option, what a fractional CTO does is the place to start.
Scope a review in writing before it starts: the deliverable, the number of hours, and a clear statement that the reviewer isn't selling you the rebuild. A reviewer who profits from the answer isn't independent. The same logic runs through our article on when to stop vibe coding and hire a developer.
What to do when the review says it's bad
Take the findings to your board or co-founders in business terms: what it costs per month to leave things as they are, and what it costs to fix. How to explain technical debt to a non-technical CEO gives you the language.
If the findings say recover, restart or rewrite, that's project rescue territory and a different decision from oversight. Bring in someone who has done it, with a fixed scope, before you sign anything open-ended.
What this means for your team
The decision is who provides technical oversight of the people building your product: you alone, a part-time technical lead, or a senior engineer added to the team.
Our rule, offered as judgment. If you hold the keys and can read the weekly numbers but can't judge the answers you get when you ask about them, add a second technical voice. If your team is one person or one vendor, add that voice before the next big spend, not after it. If you hold the keys, understand the answers and the numbers are steady, keep going on your own and revisit when something changes.
The harder case is when oversight isn't enough, because you need someone who shares the risk of the company. For that, read whether you need a technical co-founder instead.
Adding senior oversight through HighCircl
If your answer is a part-time technical lead, fractional CTOs through HighCircl are an option, and HighCircl also matches senior engineers to work inside your team. A shortlist of three to five candidates arrives within 72 hours. About 1 in 10 applicants passes the four-stage vetting, and the network covers 7 European countries (6 EU plus Serbia). There's no subscription, no recruitment fee and no minimum hour commitment, and if an engagement isn't working, HighCircl replaces the engineer at no additional recruitment cost.
FAQ
How much time should a non-technical founder spend on the dev team?
There's no sourced figure, so treat this as judgment. The weekly rhythm above takes about 30 minutes for the demo and update, plus time for your decision list and a monthly look at the numbers. Early on, or when something is off, spend more.
How do I know if my developers are any good?
Look at what they ship and how they talk about it. Working software every week, honest slippage and a clear answer to "what would break if you were out" are good signs. If you can't judge the answers yourself, a one-off independent review gives you a ranked, written verdict.
What should a weekly update contain?
Five lines: what shipped, what's blocked, what's next, risks, and what slipped and why. Pair it with a demo of working software and a short list of decisions the team needs from you.
Do I need a fractional CTO to oversee developers?
Not always. If you hold the admin keys, get a weekly demo and the team's numbers hold steady, you may not. If you can't evaluate the answers, or the team is a single person or vendor, a part-time technical lead or a one-off review is worth the money before your next large spend.