How to baseline a product delivery team in 30 days.

If you sit above an engineering or product delivery team, whether as a founder, COO, CTO, VP, or Head of Delivery, here's a question worth sitting with: how would you know, today, whether your team is doing well?

Most of the answers we hear are circular. "They seem busy." "We're shipping things." "The senior engineers say we're on track." Those are vibes, not data. Vibes are what get you to the eighteenth month of a slow rebuild before realizing the team plateaued in month four.

You can't improve what you can't see. The first 30 days of an embedded delivery engagement is mostly about installing visibility. Not as a surveillance project, but as a way to tell the difference between a team that's getting better and a team that's just getting busier. Here's how that work runs.

Why the question is hard

Delivery performance is genuinely difficult to measure, and the trap deepens when leaders look only at engineering signals. Lines of code is a vanity metric. Story points are made up. Velocity moves with team composition. Tickets closed depends on how tickets are sized. Even commits per week can be gamed by anyone who knows you're watching commits. And none of those numbers tell you whether the team is building the right thing in the first place, or whether they can change direction when the answer turns out to be no.

The trap most leaders fall into is picking any single metric and tracking it weekly. The metric becomes the goal, the team optimizes for it, the goal stops mapping to outcomes. Goodhart's Law lives in every delivery organization: as soon as a measure becomes a target, it stops being a useful measure.

The fix isn't to find a better single metric. It's to triangulate across four lenses simultaneously, covering both halves of the question (are we building the right thing, and are we building it well?), and to baseline once before deciding which to optimize.

The four lenses

The four-lens approach is what we run on our own systems through Concordance, and it's the same lens we use to baseline a new engagement's team:

1. Outcomes and alignment

Is the team building the right thing? At any scale, this lens comes down to four questions. Is there a clearly named outcome the team is working toward, expressed in language users and the business both recognize (e.g. a North Star metric, OKRs, outcome-based goals rather than feature counts)? Is there a defined feedback path from user signal to backlog (e.g. journey mapping, value stream mapping, direct PO-led discovery, telemetry pipelines), and how stale does the signal get before it shows up in a sprint plan? Are business and product/engineering leadership synchronized at a cadence that matches the speed of the market, or do they meet quarterly and hope? When was the last time the strategy was meaningfully challenged (e.g. through a Zero-Based Design exercise) rather than incrementally adjusted?

Signals we'd look at:

• How the team's outcome or North Star is expressed, and where it lives (deck, dashboard, wall, slide footer, nobody can find it)
• Whether outcomes (OKRs, KRs, or the local language) trace cleanly to the current backlog, or sit as a parallel artifact
• The path from user signal to backlog: tools, cadence, who owns it, how long the signal sits before it shows up in a sprint plan
• Working cadence between business, product, and engineering leadership: weekly working sessions versus quarterly reviews with status decks in between
• When the strategy was last meaningfully challenged rather than incrementally adjusted (e.g. through a Zero-Based Design exercise)

A team building the wrong thing efficiently is a worse problem than a team building the right thing inefficiently. Whatever shape this lens takes inside your org, it names that risk first, before anything else.

2. Delivery health

Can the team produce reliable, valuable software at a sustainable pace? Engineering indicators (deployment frequency without incident, test coverage trajectory, code review cycle time, change failure rate, time to recover) sit alongside product indicators (Sprint Goal achievement, discovery cadence, ratio of feature work to maintenance, whether the team can take a week off without things falling over). Sprint Goals are an underrated diagnostic here: the gap between "a sprint with a goal" and "a sprint with a task list" tells you more about delivery health than velocity ever will.

Signals we'd look at:

• Deployment frequency, change failure rate, time to recover, code review cycle time, test coverage trajectory
• Sprint Goal hygiene: whether each sprint is set up around a goal or a task list, and how often the goal is genuinely achieved
• Discovery cadence: tracked as its own track, or collapsed into build pressure
• Ratio of feature work to maintenance, and how visible technical debt is to leadership
• Whether the team can take a week off without on-call carnage

Health is the foundation lens because everything else depends on it. A high-velocity team that's cooking the books on test coverage isn't healthy. They're burning down the future to look productive in the present. Whether that's happening in your org isn't something we can call from outside; it's something the data tells us once we look.

3. Adaptive capacity

When new data emerges (user research, telemetry, a market shift, a regulatory change), how fast can the team actually pivot? Indicators: latency from "we just learned X" to "the backlog now reflects X," whether prioritization is practiced through a defensible mechanism (e.g. WSJF, MoSCoW, Value vs Effort) or done by loudest voice, whether MVP approaches are used to test bets cheaply or every initiative is sized as a full build, whether there are explicit kill criteria for bets that aren't working, whether experiments actually ship or just get talked about.

Signals we'd look at:

• Latency from "we just learned X" to "the backlog reflects X" (a sprint, a quarter, never)
• Whether prioritization is practiced through a defensible mechanism (WSJF, MoSCoW, Value vs Effort, etc.) or driven by loudest voice in the steering committee
• Use of MVP approaches with measurement attached, versus initiatives that get sized as full builds by default
• Whether kill criteria are written into bet briefs before work starts (or assumed and never written)
• Whether experiments ship to production, or stay in slides and conversation

Adaptive capacity is the hardest lens to measure and the most predictive of long-term outcomes. A team with strong delivery health but weak adaptive capacity will execute the wrong plan beautifully. A team with weak delivery health but strong adaptive capacity at least notices and corrects. Where your team sits on that map is what the baseline surfaces.

4. Risk posture

Three risk dimensions, treated together because they're how things go wrong in modern delivery. Compliance evidence: is there an audit trail of decisions, code reviews, deployment approvals, security reviews, incident responses (covering SOX, HIPAA, SOC 2 where applicable)? AI discipline: which tools are approved (and which the team is using anyway), what data is pasted in, how AI-generated code is reviewed before commit, whether there's a clear position on AI in customer-facing communications, whether velocity gains from AI are tracked against quality outcomes. Deployment risk: rollback rate, time to recover from incidents, the percentage of deployments that involve manual steps, whether deployments require senior engineers to be present, on-call workload reality.

Signals we'd look at:

• Compliance evidence: where the audit trail lives (toolchain, Slack threads, notebooks, people's heads) and how easy it is to reconstruct a decision after the fact
• AI discipline: which tools are approved, which are in use anyway, what data is being pasted in, how AI-generated code is reviewed, position on AI in customer-facing communications
• Deployment risk: rollback rate, time to recover, percentage of deployments that involve manual steps, whether deployments depend on specific named people being present
• On-call workload as a real number, distinct from normalized firefighting
• Closure rate of incident post-mortem action items, not just the number generated

If something goes wrong, whether a breach, a bad deploy, a missed launch, or a customer complaint, can you reconstruct what happened and who decided what? At smaller scale this is rarely formal. At enterprise scale the audit trail is the regulator's first ask. Either way, the lens applies. Hidden risk on any of these dimensions compounds quietly until it doesn't.

The 30-day baseline, week by week

Across the four lenses, here's what the actual baseline work looks like:

Week 1: Read the system

The first week is for reading, not interviewing. Source control, deployment logs, the last six months of incident reports, the team's tickets, the architecture diagrams (if they exist), the build pipeline, the test suite, the product backlog, the OKRs, the roadmap commitments. The output is a written summary of what the system looks like from the inside.

This step is the one most often skipped, and it's the one that surfaces the most. Talking to the team gives you their version of the truth. Reading the system gives you the system's version.

Week 2: Talk to the team

One-on-ones with engineers, product owners, designers, the delivery leads, the engineering managers, and any business or operations partners they work with. Forty-five minutes each. The questions are diagnostic, not evaluative: where do you spend most of your time? What slows you down? What's broken that we haven't talked about? What would you change if you could?

The honest answers come in week two, when the trust is fresh and there's no political stake yet. By month three, you'd hear the rehearsed version. By week two, you hear what they actually think.

Week 3: Run the numbers

Pull the actual data across both halves of the question. Engineering signals: deployment frequency, lead time, change failure rate, recovery time, code review cycle, test coverage trends, incident frequency. Product signals: Sprint Goal achievement rate, percentage of backlog tied to a named outcome (e.g. OKR or North Star metric), discovery cadence, time from user signal to backlog item, ratio of validated bets to speculative ones. For each, plot the last six months. Look for trends, not snapshots. A team that's deploying twice a week is doing fine; a team that was deploying twice a week six months ago and now deploys once every two weeks is in trouble. Same logic applies to Sprint Goal hit rate, discovery cadence, and outcome-linked backlog share.

If the data isn't readily available, that's itself a finding. The fix is usually 90% existing tools and 10% setup, not a tools-buying spree. Smaller teams often haven't wired it up; larger organizations often have it siloed across three platforms. Same problem, different cause.

Week 4: Write it up

The output of the baseline is a single document, eight to twelve pages, written for the sponsoring leader and their senior team. Structure:

• Top three risks (specific, named, prioritized)
• Top three opportunities (where small investments compound)
• Score across the four lenses with one paragraph of evidence each
• Recommended priorities for the next 90 days
• What we're not recommending and why

The document isn't the product. The conversation it triggers is the product. By the end of week four, leadership has a shared, evidence-based view of how their delivery organization is actually performing, probably for the first time.

The most valuable thing the baseline produces isn't the score. It's the moment when the sponsoring leader, the senior engineering lead, and the product partner all look at the same data and agree on what's true.

Why the four lenses run together

Each lens on its own can mislead. A team with strong delivery health but weak alignment will execute the wrong thing well. A team with strong alignment but weak adaptive capacity can name the right outcome and still not change course when the outcome moves. A team strong on both can carry hidden risk on the fourth axis until a deploy or an incident surfaces it. The value of the four-lens read is the triangulation, not any one number.

What this kind of baseline deliberately does not do is pre-judge where your team will land. The patterns vary across orgs, and they're shaped by history, regulatory environment, team tenure, leadership relationships, and a hundred other things that don't show up from outside. The point of the baseline is to ground the next leadership conversation in evidence drawn from your team's own data, instead of an outside opinion or a generic playbook. The decisions are still yours.

The trap to avoid

The single biggest failure mode after a baseline is over-correcting on whichever metric scored worst. If outcome alignment is weak, leadership reorganizes the org chart instead of fixing the feedback loop. If adaptive capacity is weak, the team adds three new prioritization frameworks instead of asking why prioritization isn't actually happening. If deployment risk is high, the team installs ten new processes and slows everything down. If AI posture is weak, leadership bans AI tools company-wide.

The point of the baseline isn't to fix everything that scored poorly. It's to pick two or three things to actually move on, and to leave the rest visible but unaddressed for now. A baseline you don't act on is a waste; a baseline you over-react to is worse.

What changes after the baseline

Three things, reliably:

First, leadership stops asking "are we doing well?" and starts asking "are these three numbers moving?" That's a calmer conversation, and a more productive one.

Second, the delivery team stops feeling like their work is invisible. Most engineers, product owners, and delivery leads want to be measured on something real. They hate being measured on vibes. The baseline gives them something concrete.

Third, when something does go wrong, whether a bad deploy, a security incident, a missed launch, or a senior departure, you have a real reference point. "Are things worse than they were six months ago, or is this just a bad week?" becomes answerable. That changes how you respond.

If you don't have a clear, evidence-based view of how your delivery team is actually performing, the free 30-minute discovery call is the right starting point. We'll walk through what a baseline would look like for your specific team and tell you honestly whether it's worth doing now or worth waiting.