The Tenhaw Way

Before you write a line of code, ask: "What business outcome does this serve?" If the answer is "well, the client asked for it" or "it was on the roadmap" — that's not good enough. Every piece of work should trace to a measurable result: revenue, retention, efficiency, customer satisfaction. Something you can look at in six weeks and say "that worked" or "that didn't."

This means replacing your feature backlog with an outcome backlog. Instead of "Build export to CSV," you have "Reduce time-to-first-insight for enterprise users by 40%." The CSV export might be part of the solution — but it's not the goal. The goal is the outcome. Everything else is a hypothesis.

Score every epic for business value. Not in abstract t-shirt sizes — in actual estimated impact. Then use that score to prioritise ruthlessly. The moment you stop letting the loudest voice in the room set priorities, everything gets clearer.

Your stakeholders don't care about your velocity. They really don't. They care about one thing: can I trust your commitments? When you say something will ship in March, does it actually ship in March?

Stop giving people single-point estimates. Nobody knows exactly when something will be done — but you can know the probability distribution. Run Monte Carlo simulations against your historical throughput and give stakeholders confidence intervals: "There's an 85% chance we ship by March 15th." That's honest. That's useful. That builds trust.

Watch your flow metrics: cycle time, throughput, work in progress. These tell you the real story. If your cycle time is creeping up, something is wrong — and you'll catch it before it becomes a missed deadline. Limit WIP aggressively. Finishing work is always more valuable than starting new work.

Velocity tells you how fast you're running. It tells you absolutely nothing about whether you're running in the right direction.

After you ship something, go back and check: did it work? Did that onboarding redesign increase activation? Did the performance work reduce churn? If you're not closing the loop, you're just shipping features into the void and hoping for the best.

Set targets for each initiative before you start — "We expect this to improve conversion by 15%" — and then track whether you hit them. Hold the team accountable for outcomes, not outputs. Nobody should be celebrating "we shipped 47 stories this sprint" if none of them moved a business metric.

This is the hardest principle to adopt because it requires honesty. It means admitting when something you shipped didn't work. But that honesty is what separates great teams from teams that are just busy.

Healthy teams ship better software. This isn't fluffy HR talk — it's observable. Teams that skip retros accumulate process debt. Teams that ignore tech debt slow down every sprint. Teams that don't track risks get blindsided by them.

Run regular health checks — not as a box-ticking exercise, but as an honest pulse check. Are people happy with the tooling? Is collaboration working? Are we spending too much time fire-fighting? Track the trends, not just the snapshots. A team that scores 7/10 but has been declining for three months is in worse shape than a team that scores 5/10 and is improving.

Do retros properly. Actually action the items. Check last sprint's actions at the start of this sprint's retro. Generate summaries so you can spot recurring themes — the problems that keep coming back are the ones worth investing in.

Catalogue your tech debt and score it by ROI. Some debt is fine to live with. Some is actively slowing you down. Know the difference, and make paying it down a first-class part of your planning — not something you squeeze in when there's a quiet sprint (there never is).

Your team generates an enormous amount of delivery data every week — commits, cycle times, retro feedback, incident logs, estimation accuracy, throughput trends. No human can synthesise all of that into actionable insight. But AI can.

The point isn't to let AI make decisions for you. It's to let it surface signals you'd otherwise miss. Things like: "Code review is becoming a bottleneck — average wait time has doubled this month." Or: "The auth module has a 78% regression probability based on recent commit patterns." These are signals that a human would catch eventually — but usually too late.

AI-generated status reports that pull from real delivery data instead of someone's Friday-afternoon memory. Natural language queries against your entire delivery history. Summaries of recurring retro themes across quarters. This is where AI genuinely helps — not replacing your team's judgement, but making sure they have the right information when they need it.

A roadmap is a communication tool, not a contract. And definitely not a Gantt chart pretending to be truth.

Near-term items should be committed — backed by data, high confidence, the team has capacity and the work is well-understood. Mid-term items are planned — estimated, moderate confidence, subject to change. Far-term items are exploring — directional, low confidence, this is where we think we're heading.

Make this distinction explicit. When stakeholders understand that "Q4" means "we're exploring this direction" rather than "this will ship in Q4," everyone's happier. Update the roadmap when reality changes — which it always does. A roadmap that never changes isn't a roadmap. It's fiction.

And critically: every item on the roadmap should link to an outcome. If it doesn't serve a strategic goal, it shouldn't be taking up space.