Technology governance for non-technical leaders: a practical framework

Most technology governance fails quietly. Not because the non-technical leader is uninterested, not because the development team is hiding anything, and not because the reporting templates are wrong. It fails because the information moving between the two sides is framed in a language that doesn't let the business make decisions.

The development team reports what it's doing. The business needs to know what's happening, which is a different thing entirely. That gap is the real problem, and it's where good governance has to operate.

This post is written for operations directors, managing directors, and non-technical board members who are accountable for technology outcomes they can't inspect directly. It's a practical framework, not a theoretical one. If you apply it, you should be able to evaluate your technology team's performance with roughly the same confidence you apply to any other business function.

What good governance actually looks like

Before the framework, the standard. Good technology governance has four observable qualities.

Visibility. You know what the team is working on, why, and how it connects to business goals. You don't need to read the code to understand the answer to "what is being built this quarter and why." If you can't get a clear answer to that question, governance is already broken.

Predictability. Delivery against commitments is stable enough to plan around. Not perfect (software delivery isn't manufacturing), but consistent enough that when the team says "this will be ready in March," the business can make commitments that depend on that date.

Accountability. When things go wrong, it's clear what happened, who is addressing it, and what's changing to prevent it from happening again. "Problems are accepted but not learned from" is a governance failure.

No surprises. The board doesn't learn about major technology problems from a customer complaint, a competitor announcement, or a social media post. They hear about them from the technology team, in advance, with a plan already forming.

If your current governance delivers all four of these qualities, you don't need this post. Most organisations I see struggle on at least two.

The four pillars of technology governance

Most governance frameworks are too generic to use. This one is structured around four questions a board member should be able to ask at any time, and the team should be able to answer.

1. Delivery oversight

The question: What is being built, what is on track, and what is not?

This is the most common area of failure. The surface-level mechanics (sprint planning, status meetings, Jira boards) are usually in place. The governance issue is that they generate activity reports, not outcome reports.

Useful delivery oversight has three components:

• A short list of major milestones tied to business outcomes, not internal development states. "Payment integration live in Q2" is a milestone. "Complete refactoring of the payment module" isn't. It's work, and the business doesn't care about work in isolation.
• Confidence levels against those milestones (high, medium, low) updated monthly. The dev team will resist this because they don't like committing to a number, but vague confidence is the thing governance exists to remove.
• What has changed since last month, explicitly. Not just "progress is being made." What moved, what slipped, what risks were closed, what new risks emerged.

The test of whether you've got delivery oversight is simple. If you asked your technology leader right now, "Which of our major milestones am I most at risk of missing, and what is the current plan?" can they answer in two sentences? If no, the oversight isn't in place.

2. Quality oversight

The question: Is the thing we're building actually working, and is it getting better or worse?

Quality is where most non-technical leaders feel most blind, and it's where good measurement matters most. You don't need to understand the codebase to track quality. You need the team to report a handful of numbers consistently.

The numbers worth tracking:

• Customer-facing incidents per month. How many times in the last month did a customer experience a problem the platform caused? The trend matters more than the absolute number.
• Time to resolve incidents. When things break, how long before they're fixed? If this is increasing, quality is deteriorating.
• Defects detected before release vs after release. The ratio tells you whether testing is catching problems. If more defects are found in production than in testing, the quality gate is failing.
• Deployment frequency and failure rate. How often can the team ship? How often do those shipments cause a problem? Fast, reliable shipping is a quality signal; slow, failure-prone shipping is not.

If your team doesn't measure these, that's the first problem. If they measure them and are reluctant to share them, that's a bigger problem.

3. Financial oversight

The question: Are we getting value for what we're spending?

Technology spending is easy to report and hard to evaluate. Most organisations know what they spent. Fewer know what they got for it.

The governance challenge is to connect spend to outcomes without pretending software is a manufacturing process. Reasonable approaches:

• Spend against plan, monthly. The basic hygiene. If actual is diverging from plan, understand why. Scope creep and unplanned firefighting are the usual culprits, and both are solvable once named.
• Cost per major deliverable, tracked across the year. Not in a punitive way (this isn't about developer productivity metrics, which are famously misleading). It's about whether the big things the business asked for are delivered at roughly the cost that was forecast.
• Technical debt investment, as a proportion of total engineering time. Healthy teams spend 15-25% of their time on maintenance and debt reduction. Under that, debt accumulates invisibly. Over that, the business is underinvesting in new capability. The ratio is worth knowing.

4. Risk oversight

The question: What could go seriously wrong, and what are we doing about it?

This is the pillar most often missing entirely. Teams report status; they rarely report risk systematically. Good risk oversight has two parts.

First, a short, maintained list of technology risks (typically five to ten at any time), each with a description, a likelihood, an impact, an owner, and a current action. Examples from real engagements: "Single-point-of-failure in payment processing," "Lead developer leaving in Q3," "GDPR subject access requests cannot be fulfilled within deadlines."

Second, regular review of that list, monthly or quarterly, with items added, reframed, resolved, or escalated. Risks that never change are usually not being actively managed. Risks that disappear without explanation are being forgotten, not resolved.

A non-technical leader should be able to ask "what is on the technology risk register" and get a clear answer. If there's no register, or the register is theatre, that's the first thing to fix.

The one-page monthly board report

Most technology reporting I see is either twenty-slide status decks (too long for the audience) or two sentences of reassurance (too short to be useful). A one-page monthly report, used consistently, is usually the right answer. Here's the structure I use:

Section 1: Executive summary (three bullet points, max). The three things a board member needs to know if they read nothing else.

Section 2: Delivery status. Each major milestone with confidence level (high/medium/low), any change since last month, and next month's focus.

Section 3: Quality metrics. Four to five numbers with month-over-month trend. Incidents, resolution time, deployment frequency and any failure rate, and one or two product-specific quality metrics.

Section 4: Budget position. Spend against plan, flagged if diverging by more than 10%.

Section 5: Risks. Top three risks on the register, with current status. Any new risks added this month, any risks retired.

Section 6: Decisions needed. What the technology team needs the business to decide or approve. If this section is persistently empty, the team is making decisions the business should be involved in, or the business isn't being informed about decisions it should care about.

That's the whole report. If it takes more than one page, the team is working harder to generate the report than the report is working for the business.

Four heuristics for interrogating developer estimates

The most common governance failure I see is estimates accepted at face value. "This will take three weeks" is treated as a fact rather than a forecast. Here are four questions that turn it back into a forecast the business can work with.

1. "What is your confidence range?" Ask for best case, expected case, and worst case. A team that can only give you a single number hasn't thought about the risk. A team that gives you three numbers has. If the worst case is more than double the best case, the scope needs more work before estimating again.

2. "What would make this take twice as long?" The team should be able to name two or three specific things: unclear requirements, an unknown third-party integration, a migration that might be harder than it looks. If the answer is "nothing, it will be fine," ask the question again in a week.

3. "What would make this take half as long?" The mirror image. If the team can't name opportunities for simplification, they haven't looked for them. Estimates are often negotiable on scope in ways the team doesn't volunteer unless asked.

4. "How does this compare to previous estimates that turned out right?" Patterns are more informative than forecasts. If similar work has consistently taken 50% longer than estimated, the next estimate needs adjusting before it's accepted.

Track estimate-to-actual over time. Not to punish, to calibrate. A team that consistently takes 40% longer than estimated isn't dishonest. They have a systemic estimation bias that the business can plan around once it's measured.

Ten questions a non-technical leader should be asking

Shareable, scannable, practical. Not all monthly. Some are quarterly, some are "ask when something feels off."

1. Which of our major milestones am I most at risk of missing, and what is the current plan?
2. How many customer-facing incidents did we have last month, and is the trend improving or worsening?
3. What is the biggest risk on the technology risk register right now?
4. What proportion of engineering time is going to maintenance and technical debt?
5. When we've estimated work wrong in the last six months, was it in the same direction? By how much?
6. If our lead developer left tomorrow, what would be most at risk?
7. What decision is the technology team waiting on from the business?
8. How does our current architecture constrain the business strategy for the next eighteen months?
9. If we needed to cut technology spend by 20% next quarter, what would we cut first?
10. What would your team do differently if they were setting the technology direction rather than executing it?

The last one is the most important. It surfaces things the team believes but hasn't said.

When governance fails: the warning signs

Good governance has a visible signature. So does failing governance. Watch for:

• Vague status updates. "Progress is being made." "We are tracking well." The specifics that used to be in reports have quietly disappeared.
• Reluctance to demo. The team would rather present slides than show working software. Working software reveals state; slides conceal it.
• "It's complicated" becoming the stock answer. Any question that could be embarrassing is met with a complexity defence. Real complexity is explainable; this version is defensive.
• Round-number estimates. "Two weeks." "Three months." "About a year." Estimates are becoming gestures rather than forecasts.
• Missed issues surfacing late. The business hears about a problem from a customer before hearing about it from the team.
• Team turnover without clear succession. Developers leaving and the knowledge leaving with them.

If you recognise three or more of these, the first intervention isn't a new governance framework. It's a direct conversation, ideally with outside help, about what has gone wrong. I wrote more about these patterns in signs your software project is in trouble.

Frequently asked questions

I've never run a technology team. How do I know if I'm asking the right questions?

The test is whether the answers you get change what you do next. If every question produces reassurance with no action implied, the questions are probably too generic. The ten questions above are designed to produce answers you can act on.

What if the team tells me the governance approach is too onerous?

The test of "too onerous" is whether it's taking more than a few hours a month to produce. If the monthly report takes two hours to prepare, it's fine. If it takes two days, the team is doing something wrong, or the organisation is asking for reporting it doesn't actually use. Real governance should take a few hours a month of the team's time and produce real value for the business. If it does neither, fix it.

How do I bring this in without making the team defensive?

Frame it as governance the business needs, not as distrust of the team. Involve them in designing the reporting. Ask what they think is worth tracking. Most developers actually want their work to be legible to the business. They've just rarely been asked what would make it so.

What if the team says we need all this in a specialist tool?

Probably not. A one-page monthly report in a shared document is better than a beautiful dashboard nobody reads. Specialist tools can come later. Start with the questions and the reporting rhythm. The tool question comes when the reporting is stable.

What if my current team can't or won't do this?

That's a diagnostic finding. A team that can't produce a one-page monthly report describing what they're doing is either overloaded, under-led, or under-skilled. All three are fixable, but only after they're named. Bringing in outside senior leadership (whether interim, fractional, or project-based) is often the fastest way to establish the governance and then hand it back to the team in a sustainable form.

What to do next

If you recognise your organisation in any of this, the first step is usually not a new framework. It's a diagnostic conversation with someone who has seen what good looks like.

I work with organisations in this position through fractional CTO and strategic technology leadership engagements. The shape depends on what you need. Sometimes an ongoing governance role, sometimes a three-month engagement to establish the framework and then step back.

If you'd like a thirty-minute conversation about what your current governance is producing and where it could be stronger, get in touch. I won't pitch you a service. I'll tell you what I think is going on and what the lowest-risk next step looks like.

Technology governance doesn't need to be elaborate. It needs to be consistent and directed at the questions the business actually has. Most organisations I see are closer to getting this right than they think. The change is often a reframing, not a rebuild.

---

Related reading:

• Signs your software project is in trouble
• How to tell if your software project can be rescued, or if you should start again