You are accountable for clarity, not for code
The most valuable things a non-technical manager provides are a clear goal, fast decisions, protection from churn, and an environment where problems get raised early. None require technical depth.
What does require care is knowing which answers to accept and which to probe.
Ask to see it working
Progress percentages are unreliable, not because people lie but because remaining effort is genuinely hard to judge from inside a task. Working software is not ambiguous.
Ask for a short demonstration of something real at the end of each cycle. If nothing can be shown, that is itself the most important status report you will receive.
Watch for the ninety percent plateau
A task reported as nearly finished for several weeks running is the most reliable distress signal in software delivery. It usually means an unexpected problem that the person has not yet found a way to raise.
Respond by asking what specifically remains and what is making it hard — not by asking for a new completion date, which only adds pressure to the estimate that is already failing.
Make bad news cheap to deliver
Teams hide problems when raising them is punished, and hidden problems are discovered later, when they are more expensive. Your reaction to the first piece of bad news sets the cost of every subsequent one.
Thank people for raising things early, and be visibly more concerned by late surprises than by early warnings.
Insist on written decisions
Decisions made in conversation are remembered differently by everyone present, and their reasons are lost entirely. A short written record — what was decided, why, what was rejected — prevents the same discussion recurring and helps whoever inherits the project.
This is a habit you can enforce without technical knowledge, and it pays back repeatedly.
Understand the trade-offs you are making
You do not need to evaluate a technical approach, but you should understand what each option costs in time, risk, and future flexibility. Ask for options with trade-offs rather than a recommendation alone.
If an engineer cannot explain a choice in terms of consequences you understand, that is usually a sign the choice has not been thought through — not a sign that you lack the background.
Protect the team from churn
Changing priorities mid-cycle is the most common way for well-staffed projects to deliver nothing. Batch changes to cycle boundaries where possible, and be explicit about what a new request displaces.
This is the part of the job that is genuinely yours, and it has more effect on delivery than any technical decision you might be tempted to weigh in on.