Onwards Analytics

There's a version of thorough that becomes a bottleneck. When every piece of work requires full senior involvement at every stage — every requirement documented, every decision reviewed — you get accurate, considered output. You also get a queue that never clears. The test: if the most senior person in the room went on leave for two weeks, would work stop or slow? If it stops, you've built a high-context trap. The fix isn't less rigour — it's distributing the context so more than one person holds it.

The first technical hire almost everyone makes is wrong. Not the person — the criteria. They hire for technical skill before they understand what needs to be built. So they get someone who can build things, but who waits to be told what to build. What you actually need first is someone who can help you figure out what to build. That requires curiosity about the business problem, the judgment to push back when the brief is wrong, and the ability to explain tradeoffs without jargon. Pure technical skill with none of those things produces technically impressive work that misses the point. It's a specific and very expensive kind of wrong.

There's a stereotype that developers only work 15 minutes a day. It's uncomfortably close to the truth — and the honest reason why is more useful than either defending it or dismissing it. Deep technical work can't be sustained for eight hours. Two hours of genuine concentrated effort from a senior developer can produce more value than two weeks of fragmented, interrupted, context-switching work from the same person. Most organisations have never created the conditions for that flow state to exist. The fix isn't hiring different people. It's designing the environment so concentrated work is actually possible — fewer interruptions, fewer status meetings, fewer things that break the conditions required for the actual work to happen.

When a problem feels unclear, I run backwards from the outcome instead of forward from the situation. Not "what's going wrong" — "what does fixed look like, specifically, for the person experiencing it?" Then: what has to be true for that to be possible? And what has to be true for that to be true? You keep going until you hit something concrete enough to act on. It's slower than jumping to a solution. It's faster than building the wrong thing and finding out three months later.

BHP 70 engineers unblocked Leadership asked: "why are we worse than five years ago?" We pulled HR records and org data. Nothing obvious. So we pushed further. Root cause: a cost-saving tool migration had moved 70 engineers from $10–15k/user specialist tools to $100/user Power BI. The saving was real. Nobody had counted what the engineers stopped being able to do. They still had the capability. They were doing their jobs with two hands tied behind their backs. Result after fixing it: 70 process engineers self-serving answers in under an hour. A supervisor asks about night shift performance — working answer ready before the first morning meeting. Measure the saving. Also measure what the saving cost.

Scope expansion on a vendor project is rarely accidental. The business model most professional services firms run — acquire a client, maximise revenue, reduce delivery cost — means scope expansion isn't a failure of the engagement. It's the goal of the engagement. What it looks like: the initial quote is built from what you appear willing to pay, not what the work actually costs. Then each phase surfaces the next thing that needs doing. Reasonable additions, each time. The protection isn't a tighter contract. It's understanding what the work actually costs before you start — which means having someone who can evaluate the technical scope independently, before you sign anything.

The organisations pulling ahead with AI aren't doing it because they found a better use case. They're doing it because someone senior made a broad decision, accepted that some things would go wrong, and gave people permission to find the applications themselves. Most AI projects are the opposite — individual sponsors, narrow risk budgets, optimised for safety over impact. The result: the most capable tool most knowledge workers have ever had access to, and most of them are using it quietly on their own because the official platform isn't approved yet. That's a governance problem, not a technology problem.

The context gaps that cost the most aren't the ones that were missed because they were complex. They're the ones that seemed too obvious to check. I had a predictive modelling project recently. The brief was specific. The client had budget, a business case, a competitor demo. Everything pointed to a sophisticated buyer. Somewhere in the middle of it I realised they had no idea what predictive modelling actually was. Not a partial understanding — none. Nobody had ever asked if they understood what the output would be and what they'd do with it. Including me. That question takes thirty seconds. Not asking it cost weeks. The more convincing the signals of sophistication, the more worth checking the basics.

When evaluating whether AI is right for a specific enterprise use case, I use three filters: → Volume — is there enough of this work that automation has a meaningful impact? → Tolerance for error — what happens when the output is wrong? Is it caught before it matters, or does it flow downstream unchecked? → Reversibility — if the AI gets it wrong, how hard is it to fix? High volume, high error tolerance, high reversibility: strong candidate. Low volume, low error tolerance, low reversibility: leave it for now. Most of the AI projects that fail skip filter two. The output looks right. Nobody built a review step. The wrong answer gets acted on.

Knowledge that walks out the door. When a key person leaves, the thing that's hardest to replace isn't their skill. It's the context they were carrying that was never written down — why that system was built that way, which client decision led to that workaround, what the original requirement actually was before it changed. That context doesn't appear on any handover document because it was never considered documentation. It was just knowledge. Too obvious to write down. The time to capture it is before someone decides to leave — when it still feels stable and nothing is urgent. One conversation. One hour. "What do you know that nobody else knows?" Recorded, not summarised.