Resource · Fractional Engineering Leadership
The Team assessment.
Most teams that call themselves cross-functional are running as feature factories, measured on output, not outcomes, and quietly losing their autonomy one approval gate at a time. Five capabilities, one honest score, about five minutes. From engineers who have led product teams, not just watched them.
At the end, you walk away with
- A cross-functional score out of 25, and whether you run a product team or a feature factory
- A capability-by-capability read, from end-to-end ownership to clear outcomes
- The blocking capabilities to fix first, the ones scoring 0 or 1
- The option of a written read from us, free, within two working days
- A one-click way to send the whole result to a colleague
Scored on this page. Your answers go nowhere unless you ask for the written read.
Why this exists
Cross-functional team, or feature factory in disguise?
Most teams that call themselves cross-functional are running as feature factories: measured on output, not outcomes, and quietly losing their autonomy one approval gate at a time. The five capabilities above are the honest test. The sections below are the frameworks behind them, and the plan for closing whatever the score surfaces.
The slide from product team to feature factory is rarely announced. It happens one small concession at a time, until nobody can remember owning the problem instead of the backlog.
A note on the canon: the term "feature factory" is John Cutler's, and the empowered product-team framing behind it is Marty Cagan's. The diagnostic here, and the fix plan below, are our own, built from running this with real teams.
Behind the score · Decision autonomy
The autonomy audit
Decision authority is one of the five capabilities, and this is how to pressure-test your answer. Think back over the last ten significant decisions the team made, architecture calls, scope cuts, priority changes, and classify each one. A + C above seven is real autonomy; R + D above five means the team is operating closer to a delivery contractor than a product team.
A
Full autonomy
The team decided without external approval.
C
Consultation
The team consulted others but made the final call.
R
Approval required
The team proposed; someone else approved.
D
Directed
Someone else decided; the team executed.
Behind the score · Dependency debt
The dependency debt idea
A complete skill set is the fourth capability; dependency debt is what a low score really costs. Count three things: the teams you coordinate with to ship value, the approval layers for common decisions, and the shared systems you depend on but can’t modify. The higher the total, the more the team’s speed belongs to someone else’s calendar.
0-5
Low debt, the team can move fast
6-10
Moderate debt, coordination overhead
11+
High debt, the team is structurally blocked
Behind the score · Warning signs
Feature factory red flags
If your score worries you, these are usually why. Each one signals output-orientation has won over outcome-orientation. Two or fewer and you’re broadly outcome-oriented; six or more and you’re running a feature factory whatever the org chart says.
The roadmap is a Gantt chart of feature delivery dates.
Teams are measured on velocity or story points.
Product managers spend most of their time on specs and status meetings.
Engineering estimates drive what gets prioritised.
You have "alignment meetings" every week.
Features ship regularly but business metrics don’t move.
Teams can’t say no to stakeholder requests.
"We can’t because…" is a common phrase.
Behind the score · The acid test
One question that overrides the rest
Can the team run a meaningful experiment, from hypothesis to learning, in two weeks or less, without getting approval from anyone outside the team?
If the answer is no, a high score on the five capabilities is decorative: the team is structurally incapable of learning fast enough to be a product team. Fixing that answer is the highest-leverage change you can make, and it usually shows up first as a low score on decision authority above.
After the score
30-60-90 day transformation plan
Whatever the assessment surfaced, this is the sequence for closing it. Start with the capability that scored lowest; it is the critical path.
30 days
Create visibility and measure current state
- · Run the five-capabilities assessment above honestly, with the team
- · Identify the outcome metric the team will be held to and start tracking it
- · Surface the top three blockers, name them in writing
60 days
Remove the top three dependencies
- · Negotiate the team’s scope to absorb (or shed) the worst dependencies
- · Get one cross-functional skill onto the team that was previously borrowed
- · Move at least one repeated approval to a documented decision right
90 days
Shift to outcome-based measurement
- · Replace velocity / story-point reporting with outcome metrics
- · Tie sprint or quarterly planning explicitly to the outcome metric
- · Re-run the assessment to see what actually moved
Frequently asked
Questions we get
What’s the difference between a cross-functional team and a feature factory?
A cross-functional team owns a problem and a metric; a feature factory owns a backlog and a velocity number. The cross-functional team can say "we shipped this and customers came back", the feature factory can say "we shipped 27 features last quarter" without being able to point to a single one that moved the needle. Most organisations slide from the first to the second without noticing, usually because shipping output is easier to measure than improving an outcome.
Our team scores 12. Should we worry?
12 means you're partially cross-functional, usually a real product mandate held back by two or three structural issues. It's the most fixable score on the scale, because the gaps are small enough to name and the team has enough autonomy to address them. Fix any capability scoring 0 or 1 first; those are blocking, the critical path. The ones at 2 or 3 need attention next.
How do you turn "directed" decisions into autonomous ones?
By moving them, one at a time, into a documented decision right that the team can exercise without coming back for approval. The trick is choosing low-stakes decisions first, tooling choices, refactor priorities, sprint sequencing, so the team builds a track record before tackling the higher-stakes ones. Taking on product strategy in week one rarely works; doing it in month three after demonstrated judgement usually does.
Can you have a cross-functional team if your company isn’t structured that way?
Partially, but only partially. A single cross-functional team inside a feature-factory org is fragile, every quarter it gets squeezed back into the gravity well of approval gates and velocity metrics. The lasting fix is at the org level: how teams are scoped, what they’re held accountable for, and what gets reported up. The team-level work buys you breathing room while the org changes around it.
How often should we run this assessment?
Quarterly is the rhythm we recommend. Often enough to see whether deliberate changes actually moved the score; not so often that nobody bothers to fill it in. Same assessor each time keeps the calibration consistent.
Run the assessment, then change what it surfaces.
Reorienting a team from feature factory to product team is the work of fractional engineering leadership, and it’s rarely solo work. If you’re running this assessment honestly and the score worries you, that’s the moment to bring in an outside perspective.