The Weekly Engineering Review for Non-Technical Founders

One of the most common things a non-technical founder asks me in the first week of an engagement is some version of: "How am I supposed to know whether engineering is going well?" The honest answer is that most founders never figure out a good answer to this question. They default to either trusting the engineering lead blindly (which works until it does not) or asking so many questions that the team starts spending more time on status updates than on shipping.

There is a middle path. A single weekly engineering review, 30 minutes long, with a fixed agenda, that gives a non-technical founder exactly the visibility they need without drowning the team in overhead. I install this meeting at almost every engagement I take. This article is the exact format, the exact questions, and the signals I train founders to watch for.

The principle: make the invisible visible, without interrogating

The goal of the weekly review is not to audit the team. It is to create a regular moment where the things that usually stay invisible — velocity, blockers, quality trends, incidents, morale — become visible and can be discussed together. When it works, the team comes to the meeting prepared, the founder leaves informed, and neither party feels surveilled.

The worst version of this meeting is a founder pressing for commitments and an engineering lead defending. The best version is a shared conversation about a small set of real numbers and a few specific decisions.

The format

30 minutes. Weekly. Standing calendar invite. Same day every week. The attendees are the founder and the engineering lead (or fractional CTO, or senior engineer if there is no lead yet). Nobody else unless they have something specific to contribute.

The agenda is fixed. No improvising:

Part 1 — Last week (10 min): What shipped, what did not, what was unplanned.

Part 2 — Metrics check (5 min): A small set of numbers the founder can read.

Part 3 — This week's plan (5 min): What the team is committed to this week.

Part 4 — Decisions and risks (5 min): Anything the founder needs to weigh in on or know about.

Part 5 — The open question (5 min): One open discussion topic, rotating week to week.

That is 30 minutes on the dot. If you need more than 30 minutes every week, something is off — either the team is in crisis mode and the meeting is not the right forum for the problem, or one of the two people is not doing their homework before the meeting.

The exact questions a non-technical founder should ask

Here are the specific questions I teach founders to ask in each part of the review. They are simple. That is the point.

Part 1 — Last week

"What shipped last week?" (Look for: specific features and fixes the customers will notice.)
"What was planned but did not ship, and why?" (Look for: honest answers, not excuses.)
"What was unplanned work we took on, and why?" (Look for: a clear reason — customer urgency, incident, dependency — not "we just got pulled into something.")

Part 2 — Metrics check

Pull up the dashboard. Glance at 4–6 numbers together:

Deployment count this week (should be consistent; a sudden drop is a yellow flag).
Error rate trend (flat or down is good; up is a conversation).
Uptime percentage against the SLO.
Open critical bugs count.
Customer-reported issues this week.
Anything else you have agreed to watch (e.g., LLM cost if that is a concern).

The founder does not need to deeply understand what each number measures. They need to notice when a number changes and ask about it. "Error rate doubled this week — what happened?" is the only question needed. The engineering lead will explain.

Part 3 — This week's plan

"What is the team committed to this week?"
"What is the biggest risk to that commitment?"
"Is there anything I need to unblock?"

The third question is the most important. It is the founder's explicit offer to be useful, not just evaluative. Almost always, the team has one or two things a founder can help with — a customer who needs a call, a vendor that is stalling, a hiring decision — and surfacing them in this meeting accelerates them.

Part 4 — Decisions and risks

"Is there anything on your mind that I should know about?" (Open-ended; lets the engineering lead surface their own concerns.)
"Is there a decision I need to make this week?" (Specific; makes any pending decisions visible.)
"Anything you are worried about that you have not told me?" (Optional; only ask when trust is established, but when you do, listen.)

Part 5 — The open question

Rotate a single topic of deeper discussion week to week. Examples:

Team capacity and hiring needs.
Tech debt or architecture concerns.
Incident post-mortems.
Customer feedback that is shaping engineering decisions.
Cost trends (cloud, LLM, vendors).
Quality of recent shipped work.

This section stops the weekly review from becoming entirely tactical. It creates 5 minutes where the engineering lead can zoom out and the founder can ask strategic questions.

The signals to watch

Beyond the specific questions, there are patterns over weeks that give a non-technical founder signal about whether engineering is healthy.

Consistency. Healthy teams ship a predictable amount of work each week, week after week. Wildly variable shipping patterns usually indicate that something is wrong — incidents, unclear priorities, or a team that is firefighting more than building.

Honesty about misses. When a team consistently ships what it plans, either the planning is great or the plans are trivially easy. When a team consistently misses plans, something is off. What you want to see is honest reporting — most weeks the team hits most of the plan, misses something for a clear reason, and learns from the miss.

Unplanned work as a canary. A little unplanned work every week is normal. A lot of unplanned work every week means the team is in reactive mode. If 50% of the week's work is things that were not planned Monday morning, the team cannot build anything meaningful — they are just responding.

Metric drift. A single bad week on any metric is noise. A three-week trend is signal. Error rate up three weeks in a row, or deploy frequency down three weeks in a row, deserves a specific conversation.

Engineering lead's mood. You will notice patterns in how the engineering lead shows up. Energetic and specific is healthy. Vague and defensive is concerning. Exhausted is a warning. The meeting gives you a weekly read on this, which is information you would otherwise miss.

What to do when you see a concerning pattern

When a signal is concerning, resist the temptation to solve it inside the weekly review. The review is for visibility. The problem-solving happens elsewhere — in a follow-up conversation, in a dedicated meeting with other stakeholders, or by asking for a specific analysis.

Example: deploy frequency has been dropping for three weeks. In the review, you say: "I noticed deploys are down. Can you spend 30 minutes this week understanding why and bring me a one-paragraph summary next week?" That is a better response than trying to diagnose it live.

This pattern keeps the review at 30 minutes, protects the engineering lead from feeling cornered, and ensures that the follow-up is thoughtful rather than reactive.

What a fractional CTO brings to this meeting

When I am the fractional CTO on an engagement, I am often in this meeting as a third party — running it, interpreting the metrics, and helping translate between the founder and the engineering lead. My specific contributions:

Calibrating the questions. Teaching the founder what to ask and what is overreach.
Reading the metrics. Explaining what the numbers mean and which trends matter.
Surfacing things the engineering lead may be too close to see. An outside view catches patterns insiders miss.
Coaching the engineering lead on how to communicate up more effectively.

The long-term goal is for the founder and the engineering lead to run this meeting without me. Usually after 4–8 weeks of installing the ritual and sitting in on it, I can step out and the meeting continues running well.

Counterpoint: the meeting is not a substitute for relationship

A warning. The weekly review works when the founder and the engineering lead already have a working relationship and a baseline of trust. If they do not — if the founder is doubting the lead, or the lead is frustrated with the founder — no meeting format will fix it. You need a deeper conversation first. Installing a formal review on top of a broken relationship just creates a weekly session of mutual frustration.

If that is the situation, the weekly review is a good destination but not the first move. The first move is a direct conversation about what is not working, possibly with a neutral third party.

Your next step

This week, put a 30-minute weekly engineering review on the calendar with your engineering lead, for the same time every week going forward. Share the agenda above. Run it at that length for four consecutive weeks. At the end of four weeks, evaluate honestly: do you feel more informed, and does your engineering lead feel like the meeting is worth their time?

Where I come in

Installing the weekly engineering review is part of the first 30 days at nearly every fractional CTO engagement I take with a non-technical founder. Usually I run the first four as the facilitator, coach the founder through the questions, and then hand it off once the rhythm is established. Book a call if you want help setting one up and running it well.