I can’t help but notice that most of the context engineering content I’m consuming is at odds with my real-world experience. I attended a meet-up where 4 talks all focused on how to express good quality knowledge in fancy containers. Knowledge graphs, semantic layers, skills libraries and the like. All seemed smart! But they missed the biggest challenge I’ve been wrestling with - which is how to get domain experts to give you the damn knowledge in the first place.

This is a decades-old challenge from the knowledge management field. But I rarely see any reference to that, or the cautionary tales it contains. Many millions were wasted on consultant-led knowledge management projects which failed to appreciate the true nature of knowledge or people. And it feels like the AI world could be on course to waste some more.

Why gathering quality context is hard

More than a decade ago, Dave Snowden wrote a short article titled Rendering Knowledge, with seven principles he’d developed from years of knowledge management research and practice. Despite being so old, it’s honestly the best thing I’ve read about context engineering. It perfectly crystallises many of the things I’ve felt in my bones from past forays into knowledge management. And helps explain why gathering quality context is so hard.

Knowledge can only be volunteered it cannot be conscripted
Principle 1 | Rendering Knowledge

For two years, I was the product manager of an (award-winning!) automated knowledge platform called FutuCortex. It was an internal system at Futurice, the consultancy I worked for. Consultancies are basically in the business of selling knowledge, so it’s pretty important to ‘know what you know’. But few do. So we were out to rectify that.

The challenge was that asking people to write down what they knew never seemed to work. It’s a request that lacks urgency, in a world where people have no shortage of urgent-feeling things to do. Please document your knowledge because someone, someday, might find it useful (but you’ll probably never find out if they do). Efforts often started with a bang and people would share a bunch of great stuff. But the system would gradually turn into a ghost town, as the death spiral of outdated knowledge → lost trust → lower motivation to document → more outdated knowledge ensued.

Our solution to these challenges was to accept defeat in getting people to write things down. Instead, we automatically harvested knowledge fragments from the (public) digital footprint. That meant scraping documents from high-signal sources (e.g. specific fields in HubSpot or types of files from Google Drive), then automatically removing trash and duplicates. We also inferred expertise from the topics people were talking about on Slack, their hour-marking comments and meeting events. This all came together in a knowledge platform where you could search for the most up-to-date sales materials / references / links / experts.

It definitely got us somewhere useful. But it turned out that the digital footprint, while rich, contained only a fraction of the valuable knowledge. What we collected acted more like breadcrumbs - people still needed to combine pieces with their own thinking to reach meaningful conclusions. Or they’d speak to the authors to get the story behind the words.

In every AI project I’ve done since FutuCortex, I’ve faced the same challenges: motivating people to tell you what they know is really hard. It’s always a battle to get the best ( = usually the busiest) domain experts to share enough time or do literally any documentation task without me standing over them. And what’s already documented in systems will never provide the full picture. So you can’t work around the problem entirely.

We only know what we know when we need to know it
Principle 2 | Rendering Knowledge

The way we know things is not the way we report we know things
Principle 6 | Rendering Knowledge

We always know more than we can say, and we will always say more than we can write down.
Principle 7 | Rendering Knowledge

The problem is not just that people are ‘lazy’. We are. But the task of ‘writing things down’ can be a much bigger one than it looks.

As an example, these last couple of weeks I’ve been drilling my own brain. I’ve created an AI research workflow that reads 100s of potentially relevant articles and pinpoints the 10 most interesting things for me to read each week. It helps me catch all the most relevant / insightful / challenging / viral thinking to soothe my FOMO and prioritise my reading time.

To do this well, I needed to instruct the AI how to search and evaluate like me - or at least a version of me with much more time and patience. The challenge is that I don’t really know how I search or evaluate… I just do it intuitively and know good sources when I see them. So the task of giving the AI the right context isn’t one of documenting thoughts I’ve already had. It’s one of defining what I really think.

I started with my own version of the ‘grill-me’ skill, to dump all my top-of-mind thoughts. Then I worked with AI to review examples, prompt drafts and rough prototypes, which triggered many new questions and thoughts that were nowhere to be seen when thinking abstractly.

I painstakingly turned all the findings into detailed prompts that tried to crystallise the repeatable rules behind my thinking. But, in the first full test run, the AI still mis-evaluated 9/14 cases from my held-out set of manually labelled examples. This was kind of heartbreaking. But it was only through trial and error that I could work out what I really thought…

In all, getting something good enough took 2-3 days of rethinking back and forth, and it’s still far from perfect.

This was a case where I was engineering my own thoughts into context for AI. There was zero friction between me and the developer (also me). Yet it was still a pain in the ass. Getting AI to interview me captured maybe 10% of what was needed, along with a bunch of things I ended up disagreeing with once I saw their implications in practice. Some of my thinking could be effectively turned into generalisable rules that AI could apply. But many tacit, intuitive or context-specific thoughts couldn’t be pinned down in a prompt.

The process can surely be improved, but I don’t see any major shortcuts. Because the answers simply weren’t in my head until I tried things and failed.

Multiplayer mode is harder

All of this gets harder when you include more people. Motivating yourself is one thing. But it’s another to motivate people who don’t care or might even feel actively threatened by the prospect of giving their knowledge to AI. It’d be very rare to get 2-3 days of dedicated time to rethink back and forth with a real client. People also have a tendency to disagree on what the right context is.

In one particularly frustrating client project, we thought we’d struck gold with a recent, rigorous document that seemingly explained everything our AI solution needed to know! Sadly, when we put our first prototype in front of users, it quickly became painfully clear that the document was just one person’s opinion - and that person’s boss (aka our buyer) happened to strongly disagree. The boss had even recommended we use the document in the first place. But I guess they’d never actually read it... So the major misalignment between them and their colleague had sat below the surface, until our friendly AI chatbot brought it into the open.

From my experience working with enterprises, this is a decent representation of the norm. What’s written down doesn’t reflect what people really do. People often disagree. And there are exceptions to every rule.

So gathering good quality context always feels bloody difficult! I'm a bit worried I'm just a laggard who doesn't know all the latest tricks. But I suspect many people are stopping their gathering too early - when only the first layer of knowledge has been peeled back. Or they’re trying to gather knowledge which simply can’t be made explicit. There’s probably a lot of fancy-looking graphs and skills libraries out there, devoid of the actual knowledge they're meant to represent.

AI won’t solve the problem alone

I see a lot of people excited about LLMs doing all the “grunt work” of documenting, structuring, linking, maintaining and retrieving their knowledge. They think knowledge management failed because people were lazy, but now we have AI to do all the things we don’t want to. So it’s all good.

I’m also excited about this! But, beyond very standardised workflows, I’m highly sceptical of any context gathering strategy that relies ONLY on finding knowledge from systems, AI interviews or meeting transcripts.

This feels very attractive, because peeling back the layers of how we really think, defining what matters most, and pinpointing the genuinely reusable context is all high-effort work that our brains try to avoid. But, time and time again, I’ve seen this effort pay off.

The extreme is people with 10s of skills and subagents that their Claude / Codex has created for them, with instructions they’ve never even read themselves. For the kind of projects I’ve been working on, I think this is a rather terrible approach. It just turns surface level thoughts into bad prompts. Even using the mighty Fable in the research workflow I described above, every prompt draft it created was far off the mark and I had to rewrite the majority of lines myself. The AI isn’t dumb. But it can’t document the right approach until you’ve discovered it yourself.

Hacking a solution together

A couple of weeks ago, I got together with some AI engineer pals who shared some of my frustrations. Between us, we’ve tried all sorts of different workshop and interview formats, AI workflows and even custom context gathering tools. But no great ‘expert brain drilling’ approach has emerged. So we had a hackathon to create it.

This is the basic thinking behind what we built:

We use AI to grab all we can ‘for free’ - but accept it’s just the first layer. Then AI does a lot of structuring and labelling of what’s gathered, so we arrive at each human session with a progressively richer picture. Experts can then just show up and react to + refine the thinking, without having to establish basics or repeat themselves (which, in our experience, they hate).

Human facilitators / interviewers are still crucial at layers 2 and 3. In ~every workshop or interview I’ve done, important information always comes from noticing body language or tone of voice or tension in the air, then asking people to say more. Which AI can’t do yet. But there’s an always-on AI channel that sits alongside them, to grab any thoughts that pop up in between sessions, with minimal friction.

The main goal is to improve the UX for the domain experts and cut the time needed from them, without limiting the depth of thinking they share. In our hackathon, this context was feeding automated evaluators that a software factory could autonomously build against. Which is the sort of cool stuff that becomes practically possible when you invest in gathering good context at the outset. But that’s another story.

When NOT to drill…

I often see an assumption in AI discussions that documenting domain expertise and building agents around it is now the solution to every problem. But I think this overestimates what knowledge CAN and SHOULD be made explicit (another classic Snowden lesson).

Much of what experts know is entangled in experience or emotion that can’t be made explicit. Or will resist being beaten into the shape of generalisable rules that AI can reliably apply.

AI can now tirelessly surface knowledge fragments, from meeting notes or documents or analytics. Which gives us new reason to capture information that humans would’ve previously ignored. But, for complex cases (as I’ve discussed here), we still need people to integrate that information with live, real-world context and define what matters. So, we shouldn’t always try to document the ‘knowledge’ - aka generalisable rules or processes for making sense of the information.

Drilling ‘knowledge’ should be reserved for ordered tasks where repeatable good practice can be defined. Where there’s a right answer to extract, which AI can follow.

As soon as we go beyond this, we risk:

• Enabling AI to confidently spread bad practices at scale, where the original lessons don’t apply or have gone stale.

• Removing opportunities for humans to notice what’s no longer working and innovate new approaches.

• Reducing human interactions where new knowledge is formed - because AI seemingly gives them zero-friction answers instead.

In my last project, I think I spoke to AI more than my teammates. Possibly it made me more effective. But scaled to all my cases, it could destroy the chance for juniors to learn or for me to collide with diverse perspectives that change my approach.

So, we absolutely should design better ways to extract domain knowledge from experts. But it’s only one part of building and spreading knowledge. And maybe not the biggest.

In the context of real need, few people will withhold their knowledge.
Principle 3 | Rendering Knowledge

Overall, I think there’s a lot to learn from knowledge management in the AI space. But I definitely wouldn’t recommend ‘doing knowledge management’. From my experience, most projects under that header try to do too many things for no one in particular, and fail to create lasting value.

Instead, you should use the impetus of AI use cases with clear value to tie knowledge gathering to a real need. If you get concrete successes on the board, you can then ride the momentum towards the second brain or skills library or whatever graph-thingy is calling you. You’ll never actually arrive. But the trip will be worth it if you’re surfacing real knowledge along the way. Just remember, shit spun into beautiful-looking shit is still shit!

Play it yourself. I found it weirdly exhilarating - feeling my little human brain whirring away, taking in every fragment of information to figure out what the hell was going on. With the firehose of new models and benchmark records, it can be hard to put your finger on what’s still uniquely valuable about our human brains. But playing this game, I think you can FEEL it.

ARC-AGI-3 is the flat yellow line on the chart above. The games are designed so that ordinary people can solve them with no training. Yet the best models barely register today. These are the same models that can solve maths problems beyond human reach and automate coding tasks that would take senior devs hours. The labs will no doubt crack this benchmark too, but it represents a very simplified test of the sort of working-it-out-as-we-go that most of us do in our jobs every day. So it points to a bigger gap.

This gap matters a whole lot. Because we can automate the bejesus out of the things AI does well. But we need to keep humans in the driving seat of things beyond its reach. The problem is, we often fail to recognise which is which.

Subscribe now

AI vs. the complex glory of real work

Most AI benchmarks test capabilities on clearly framed tasks, where all the relevant context can be found and there’s a ‘right answer’ to work towards. Real work contains some neat and tidy things like this. But, more often, we’re bobbing about in a sea of emotional humans, trying our best to guess what to do or how to do it.

We tend to picture our jobs as more ordered and predictable than this. Because our brains prefer simplicity and control over uncertainty and mess. But, if we really look at our work, there’s complexity hiding everywhere that AI can’t handle alone.

Gathering Context

As an example, I’ve written a lot of proposals for AI consultancy projects. Not simple workshops or CV selling - but meaty strategy / transformation / custom dev type projects.

The process starts with working out what the client actually wants. If you’re lucky, they’ve given you a written brief. But it never gives you the full picture. So you have to put it together through discovery calls, chats with domain experts, and emails back and forth.

It’s a process of collaborative guesswork - the client has an idea of a development they think will create value. At worst, it can be as loose as ‘we need to do something with AI’. You’re then trying to understand what’s in their head and why. You’re trying to decode the wider context they’re operating in. And what they want constantly changes, as you share ideas and invisible discussions happen in the background.

There’s no set of documents that can tell your AI what’s needed from the outset. Because lots of important information resists documentation - you’re picking up on the small emotional cues, tensions in the air and fragments of tacit knowledge. The act of exploring the context changes it, too. Your questions and advice reshape what the client wants. So your best guess of what to propose at the start of the process might be way off by the end.

Deciding what to do

Once you get to grips with the context, you need to decide what really matters for your proposal. But there’s no recipe to apply. You probably have a gut feeling of what might work, based on years of accumulated experience that’s hard to articulate. You think about what will land with these particular people. You fish around for useful pieces of past content - a slide layout, a visual, a strong reference story. Then you use your judgement to stitch something together, in a way that’s as emotional and intuitive as it is rational.

There’s no good feedback loop to help you unpick this in a more precise way. When you win or lose, you might get a few words of high level feedback. But you never really know why. Maybe the whole thing was just procurement theatre, to justify a choice the client had already made. Or maybe your proposal actually sucked. Then the next lead appears and you do it all over again :)

So you can’t define detailed templates or success criteria for agents to follow. Because the right approach changes over time and it’s inherently context-specific. What works with one client might not work with the next. What works for a junior person pitching to a sceptical IT leader might be terrible for a senior person pitching to an enthusiastic CEO.

Taking Action

All this action happens through relationships. You try to show your passion and expertise to the client. You try to understand them and make a human connection. Whether you win or lose depends more on establishing mutual trust and good energy than any proposal doc.

You’re also constantly adapting in the moment. A question the client asks during your pitch might lead you to skip or reframe a whole section of your proposal. Something that makes them sit forward in their seat might make you pivot into showing a related demo.

The AI can’t build these relationships. And right now, it’s nowhere near as good as us at picking up weak signals and adapting on the fly - as ARC-AGI-3 hints.

Complex Systems

What I’ve described is what complexity scientists would call a ‘complex system’. The system behaviour emerges from the interaction of many living parts. It can’t be broken down into universal rules, predicted and controlled. To influence it, we need to try things out, see what happens, and constantly adjust. See also: parenting and forests.

A lot of my work shares these attributes. In my delivery work, I had one long-running client where our check-ins became affectionately known as Jack’s weekly ass-kicking - because I was constantly trying to guess what they really wanted and often got it wrong. In my time as a startup co-founder, we spent years flailing around, in-fighting and colliding with clients on our search for product market fit.

The context is always ambiguous. The ‘right answer’ evolves with each move you take. So you have to continuously try things, learn and adapt.

AI can help us do this work a lot better - as long as we’re there to continuously craft the context and determine what matters. But we can’t define clear constraints up front, so it can’t do the work for us.

The models will keep getting better, but I don’t see this limitation disappearing fast. Because AI’s improving in places where there’s a verifiable outcome to optimise against - code that runs or doesn’t, maths with a proof, or a computer game you win or lose (like ARC-AGI-3). And these don’t exist in complex systems. So, without new paradigms, there’s a structural limit to how well AI will handle complexity.

It’s why AI coding performance has almost doubled in the last year, while I’ve not felt much difference in ideation and sparring capabilities. It’s why my inbox and feed are full of AI slop. And why both OpenAI and Anthropic are starting consulting ventures, to get AI to work in their clients’ complex realities.

Talk of fully autonomous companies and AI replacing all knowledge workers assumes benchmark-like progress will translate into complex domains. But I don’t see evidence for that yet…

Automating the bejesus out of ordered parts

The opposite of a complex system is an ordered one. In ordered systems there’s a clear relationship between cause and effect. Do X → always get Y. They can be broken down into their component parts and understood. Their behaviour can be fully predicted and controlled. Classic examples include a clock, a bridge, or even a rocket ship.

This is where AI and agents kick ass. Give them a clear frame, context and a measurable definition of success, and they can do genuinely amazing things. Those can be very complicated things too. Like software factories that autonomously build against a clear spec for many hours. You just need enough domain expertise to define the right frame.

Even though writing AI consultancy proposals is a complex process, it contains many ordered parts. Generating assets - like branded slides, visualisations, or prototypes - can be clearly framed, once we’ve done the navigation work needed to know what we want. Same with a lot of research tasks, if we can define what we’re looking for.

Where you’re happy to borrow best practices from others and outputs are easy to check, you can typically automate these parts with just a little configuration of off-the-shelf tools. Like building prototypes or running deep web research.

Where the right approach is context-specific and harder to verify, automation will take significant work - to tease success criteria from the heads of domain experts and then evaluate against them. Like generating reports or analysing data. But, if repeatable success criteria can be defined, the bottleneck to automation is likely your AI engineering skills or budget, not the model capabilities.

Not just doing things cheaper…

When we automate the parts, it can have unexpected effects on the whole. Because the whole is complex.

We’ve effectively created abundant capacity to do every bit of work we’ve automated. This creates opportunities to rethink our wider processes entirely. Think about what you’d do differently if you had 100 extra people to run web research, build prototypes or generate slides. Cause that’s kinda what you’ll have. I’ve explored running bespoke analysis and generating quality prototypes for every client, before they pay a penny. Whatever it is, it probably won’t be obvious - as we’re used to designing all our work around limited capacity.

Automations need to develop over time too, as the boundary between ordered and complex is fuzzy and constantly moving. As a professional poker player, I had a principle that if I couldn’t look back on my game from 6 months ago and identify ways I sucked, I wasn’t improving fast enough. Best practice is, by definition, past practice. So, when we lock our judgement into an automation, we risk removing the person who notices it’s stopped working when the ground shifts.

The market dynamics also change, when anything you can do with Claude or Codex can be done by all your competitors too. As Dan Shipper puts it, when cheap competence commoditises “demand for difference” rises. AI-generated content and websites that would’ve impressed me a year ago now actively put me off, because it’s so clear they’re AI-generated. This shifts the value to the parts that can’t be easily automated: knowing what’s needed and what good looks like in your specific context.

So, automation can be great. But you won’t get very far just doing what you do now cheaper. And it’s making people’s ability to navigate complexity more important. Not less.

AI and people maximalism

AI and people maximalists generally fall into separate camps. The former are building agents for everything and think it’s only a matter of time until all knowledge workers are replaced. The latter like to call LLMs next token predictors and think human judgement will never be replaced by this paradigm of AI.

I think we should adopt the mindset of both - depending on whether we’re focused on ordered or complex challenges. Use AI and humans to their maximum, in the places where they shine.

The key is to distinguish the ordered parts we can delegate to AI from the complex whole where we should collaborate with AI. With the latter, AI’s role is still very significant. It can help us process more information, analyse more options and run more experiments. And it can use agents + automations on our behalf, to free our time for thinking, learning, and building relationships. But it needs us there, to continuously define where to go and what matters.

In our sales example, this is the model I’m working towards, with people firmly in the driving seat…

No fancy ‘AI colleagues’ or end-to-end automation. And building this to the quality level needed for real-world impact is difficult:

• Automations either take time and expertise to build, or they’re a limited source of competitive advantage

• A knowledge layer easily misses a lot of the real-world context an AI needs to collaborate effectively

• Without a human process for evolution, the whole thing might be a very expensive way to destroy innovation

But this is my current best guess on how to integrate AI, in a way that accounts for its strengths in ordered systems and weaknesses in complex ones. It’s focused on our sales example, but given most knowledge work is complex, I think a similar sort of approach can apply to all sorts of jobs.

Maybe one day we’ll have new AI models that can automate the whole damn thing. But AI’s amazing performance in ordered systems isn’t evidence that they’re imminent. So, for now, I’m putting my time into designing systems that make people do complex work better, not trying to get AI to do it for us.

Subscribe now

Last month, a Stanford paper once again showed that “by default, AI advice does not tell people that they’re wrong nor give them ‘tough love’”. A Wharton paper from a few weeks earlier showed how we demonstrate “cognitive surrender” in response - frequently adopting incorrect answers from AI and growing more confident in the process.

This is not a bug that will be fixed. All leading LLMs are still trained, in part, by humans voting on what sorts of responses they prefer. They’re quite literally optimising for responses we ‘like’. But decades of behavioural science research has shown that what we ‘intuitively like’ is often misaligned with what’s in our best interest. So, unless we use them with care, LLMs can draw us away from what we NEED to hear to move forward.

What grabs the headlines is the tragic consequences this can have on validating delusional beliefs (like this case…) . But I see less discussion on how this impacts day-to-day work. And I’ve noticed that it impacts mine quite a bloody lot.

Me and My Sycophantic AI

I use AI as a sparring partner for basically all of my work. Most of the time, it’s pretty wonderful. But I often catch myself indulging AI’s tendency to tell me what I want to hear. Intuitively, I want to use it as a shortcut for deep thinking, rather than an accelerator of it.

I get just what I ask for

Prompts STILL have a big bearing on the types of responses you get. Lead the AI, and it will obediently follow. Here’s me asking ChatGPT 5.4 Thinking for some feedback on a recent substack post.

The first prompt is the sort of lazy, conversational prompt I might throw out without thinking. But my enthusiasm leads to much more positive comments and a higher rating than an explicit request for objective feedback.

The third prompt is what I do when I’m on good behaviour. But I always feel some internal resistance to asking questions like this. So, I intuitively gravitate towards something closer to the first - and the validating response feels like genuine feedback that permits me to move on. Even though I’ve not been challenged at all.

In practice, the conversation history, system prompts and context retrieved can all lead the AI in subtle ways too. When using Claude Code my carefully crafted memory files explaining the architectural choices are instantly adopted as valid assumptions. Whatever is decided in the last session, is accepted as a good decision in the next.

Then there’s all the stuff I don’t ask for. The LLM is built to give me what I want - so unless I ask it to explore what I’m missing, the gap will rarely be filled. If I only ask for research on my side of a debate, it’s not going to tell me what others are saying. I’m never proactively told to step back and rethink the problem or the why. And I often find myself forgetting to ask.

The blind are leading the blind

AI is helping me to stretch into areas where I have less expertise, which is great! But when I’m less able to objectively judge what’s actually good, there’s no internal alarm bell to tell me when the AI’s confident affirmations are wrong.

Take coding. In the last few months, I built my first web app without a real developer in the loop - just me and Claude Code. Oh boy did it feel good! Progress was way faster than I expected and I felt like I was applying all my product management instincts to guide the AI towards sensible choices. The problem was, my lack of real coding knowledge meant I didn’t know what I didn’t know. So, important architectural choices were being made without my knowledge and faulty assumptions from previous sessions were left unchallenged.

What I was missing was the grumpy (human) dev who would usually be on hand to happily tell me my idea was stupid or fight for choices I didn’t even understand. That absence became clear when I shared the project on LinkedIn and my grumpy dev pal JP was happy to oblige with a roast…

He made this roast with Opus 4.6 - the exact same model I’d asked for a deep codebase review before launch. The same model I was repeatedly prompting to double check for code cleanliness, security and performance issues. But my context, questions and framing all led the AI to avoid the issues JP highlighted. And I was none the wiser.

The scary thing is that, in domains I know well, I spot issues with the AI’s responses all the time. Yet, intuitively, I was all too happy to trust its coding choices, as if those experiences never happened. It’s Gell-Mann Amnesia, AI-style.

If I don’t want to hear it, there’s no one to make me

For important tasks, I often ask multiple AIs for multiple perspectives. Red team. Do external research. Find counterpoints to that paper I like. Then I quickly sift through the pile of responses to find valuable insights to act on.

Very rigorous! But it counts for nothing if I’m not careful about how I choose what feedback to incorporate. It’s all too easy to be drawn to the things that fit within my existing thinking, and blind or dismissive to the things that don’t. And, with AI, there’s no one but me policing this confirmation bias. If I ignore an objectively important point, the AI doesn’t call me out. If I choose to push back, it concedes the point 9 times out of 10.

I honestly don’t know if any of these concessions were right or wrong. Because, as soon as I get a ‘fair point’, I usually move on without thinking twice.

Given the AIs seem so human-like, this process has the appearance and feeling of human-feedback. I subconsciously use the AI’s feedback as validation, as if it was a human interaction. But it’s not equivalent to human-feedback at all. If I dismissed the same amount of input from a person, they’d push back. Or get angry. Or tell people I’m an asshole. If a person conceded that many points to me in a single conversation, I wouldn’t go back for their advice again.

All that social friction can be annoying. But it forces me to actually engage with feedback I’d rather ignore.

The appearance of work

At its worst, sycophantic AI helps me to go through the motions of rigorous thinking, while avoiding the pain and effort of doing it for real. I continuously make progress and produce things. I do external research, ask for counterarguments and gather feedback. But, at times, it’s all verging on theatre.

If I think of anything good I’ve achieved, there was always a lot of questioning my assumptions, going back to square one, struggling and iterating. The end product was usually nowhere near what I thought I was going to produce in the first place.

Now I’m replacing human collaborators with AI that doesn’t challenge my framing, produces whatever I ask, folds when I push back and rarely raises the alarm when I’m going off course. It makes it all too easy to avoid the hard parts that lead to real value creation, while still feeling productive. And it’s kinda addictive…

The cost of building has collapsed too. I can now just tell Claude Code or Codex what to build, and something appears before my eyes. That’s obviously wonderful. But when building something took me months and cost many thousands, it forced me to think and rethink carefully. Now I can build without thinking - which can be a great way to learn. But as my app with no users might tell you, it’s not the best way to create real value.

Doing real work with a ‘yes-man’

This is not a problem you can wait for the AI labs to solve. The human preference voting that causes sycophancy is still a key element of model post-training, with no clear replacement. And, beyond the high risk areas like indulging delusional thought, there’s limited demand for reduced sycophancy - because most people like it in practice.

The good news is that AI is also a great tool for solving this problem it’s created. So, it’s certainly not about going back to the old world, but finding new triggers and techniques for deep thinking with AI.

These are some of the habits that have stuck for me:

• I continuously push AI to expand my perspective and challenge me. It ‘red teams’ plans before I lock them in. Searches for ‘knowledge gaps’ when I’m doing research. I take the time to articulate my disagreements, then ask AI to defend. This is all increasingly systematised in project instructions, claude.mds and skills, so it comes automatically or easily.

• Where I lack the expertise to judge AI’s outputs, I delegate to outside experts. I ask AI to research the best critiques of new ideas / methodologies / technologies I’m considering. I query multiple models. In code projects, sub-agents with clean context review all my plans and PRs - free from the assumptions I’ve built up.

• I try to stay accountable to the world outside my AI bubble. AI is now my first level of feedback, but I still push myself to send draft work to real humans, to keep me honest. In each project, I define explicit quality criteria, goals and deadlines - to make it harder to convince myself to continue pursuing productive-feeling things that are going nowhere.

The challenge with all of this, is that I’m always fighting gravity towards the low friction paths AI offers. I don’t WANT to be slowed down. To become uncertain and doubtful. To be shown how I’m wrong. So, I find applying these practices takes real effort. I still regularly catch myself slipping into fancy AI procrastination and my sycophantic partner never calls me on my bullshit.

It all feels rather familiar. As a professional poker player for a decade, recognising and limiting the impact of your bias was always central. When we had our own mini-AI revolution with ‘solvers’, bias led many to draw the wrong conclusions and get more confident in the process.

Today’s AI tools are very different. But the cognitive battle is not. I reckon those who take it seriously will be the ones that create real outcomes with AI, not just more outputs.

With this, clients can get real outcomes cheaper and faster than buying consultants by the hour. And you - the entrepreneur starting this - can get more SaaS-like margins, while accessing clients’ larger service budgets.

The shift from traditional consulting looks something like this:

Sounds wonderful in theory. But what do those light red boxes actually mean in practice? How do you turn learnings from consultancy projects into high value products? What is really worth building, when each new release from the AI labs gobbles up the value propositions of dozens of AI startups?

This article digs into each box. Specifically: for a Scotsman in Newcastle who doesn’t really fancy moving to Silicon Valley or getting tied up with tens of millions of VC funding (even if I could).

Box 1: Compound Learning & Productisation

In asset-based consulting, the goal is to create a fast learning loop. Solving real problems with clients shows you what’s worth building. Then you generalise the best solutions to scale what works. Again and again.

Speed is particularly important right now, because the AI market is not really a market at all. The segments, business models and shapes of solutions are still constantly changing, so it’s really hard to predict what the winning strategies will be. Which means adapting fast matters more than “moats”.

The potential to get faster is getting much bigger too: those who do the work to develop genuinely AI-enabled processes can move far ahead of the rest.

The issue is that, in every company I’ve worked with, the time needed to get faster is rarely protected. Despite all the meetings about “boosting productivity with AI”, everyone’s too focused on the next urgent thing to create real change. So, we need better operating models (not just more initiatives).

Going slower to get faster

One such model can be found in Every’s Compound Engineering concept - where “each unit of work should make the subsequent units easier”. To achieve this, they allocate “50 percent of engineering time to building features, and 50 percent to improving the system”. That means half of their time (!!) is spent extracting their “taste into the system”, building infrastructure and context for AI, and developing human-AI processes - so their AI system can do more and more high quality work autonomously.

Think how alien this concept is for most companies. Just imagine what people would say if you proposed spending 50% of everyone’s time on internal process optimisation!

But also think how much value you could create with that time today.

In the 3 weeks since I quit my job, I’ve been able to dive into the long list of AI tools and approaches I was unable to make a dent in while fully booked in client projects and sales. And I can tell you, it’s amazing how much better I’ve got at my job, from not actually doing it…

It took me just a handful of days to set up Claude Code, build a real working application, and then optimise my development workflow to build the next thing better. That’s a task that sat on my ToDo list for more than 6 months. Now, with a few days’ investment, I’d be confident to take on a significant amount of technical work that was completely outside my scope before.

5 years ago, if you spent a few days learning new tools, it might have made you marginally more efficient. Now, I can think of 10+ examples like this, where investing just a little dedicated time could make me significantly better at my job. From coding, to lead generation, to automated client research and proposal writing.

I’m sure all the big consultancies will cook up a version of this “compound learning” philosophy. But I’m equally sure the vast majority will edit out the real time investment needed to make it a reality.

The key for new players is to find a business and operating model that makes that time investment possible. You need constraints that fight the gravity towards urgent work. Then you need a business model that ensures you bank the value of increased productivity, to pay for it.

I see some new players starting with traditional time & material consulting to get established, with the plan to pivot to something asset-based later. But, to me, this is reintroducing the structural constraints of incumbents. You’re choosing to be trapped by billing targets and giving up your freedom to invest in speed.

I don’t know what the alternative looks like exactly. But this is what I’m planning to try out:

• Split time equally between client delivery and asset development. Half goes to solving real problems with clients. Half goes to 1) generalising solutions to deliver better / faster for the next client, and 2) building a system that makes each unit of product work faster to deliver than the last.

• Never sell experts by the hour. Controversial. But I’ve heard way too many people talk about moving away from T&M without actually doing it (myself included). So, I think an enabling constraint is needed to force us to build better business models - be it fixed, subscription or outcome-based.

• Seek revenue from day 1, but not profitability. Doing real client work brings revenue. But aiming for profitability too soon will destroy our ability to build effective assets. We don’t need millions in VC, but we do need runway to operate at a loss while the assets and model takes shape.

There are many reasons why these might not work. But it sure sounds like a company I want to work at!

Box 2: Reusable AI Workflows, Agents & Applications

With this fast learning cycle running, client insights and experimentation should guide most of what’s built. But it’s really easy to build overly general solutions that take too much time to adapt for the next client. Or waste time reinventing solutions VC-backed startups have already spent millions building better. So, what are the areas where defensible competitive advantage is likely to be found?

Where foundation models dominate

Foundation models shine when there’s:

• A large amount of public data available for pre-training

• Clear, universal definitions of right and wrong to fuel reinforcement learning in post training

• A strong incentive for AI labs to prioritise development

The obvious example is coding. There’s a ton of public code and documentation online. The quality of code can largely be objectively tested. And building the best AI model for coding is a huge commercial opportunity plus an enabler for the labs’ AGI missions.

So, I reckon building assets that compete with the leading labs’ AI coding capabilities is a bad idea 🙂

Thankfully, many (or most?) knowledge work tasks don’t share these qualities.

• Doing them well relies on non-public data - about your specific industry, company or preferences

• Defining what good looks like is a pain in the ass

• They’re too niche for AI labs to care

As YC put it:

“If you’re working in one of the big model labs and there’s teams of people trying to invent AGI, it’s going to be hard to get jazzed about nailing the final five percent on your like KYC tool”.

This is the sort of place where assets worth building live.

AI that really works in a specific domain

LLMs can be deceptive in these areas. Because they already produce outputs that look competent at a glance. Ask an LLM to write a sales proposal for your company and it’ll spit out something that resembles a sales proposal. But the closer you look, the more you’ll see issues. So, wherever quality really matters, foundation models + basic prompts won’t be enough.

Many people I speak to disagree. They think the amazing out of the box capabilities LLMs have in areas like coding will transfer into use cases that rely on private data and subjective quality criteria. Or they fail to see the massive gap between the demos they can create in minutes and real-world production solutions.

But, for these sorts of context-specific tasks, every production-level LLM project I’ve been involved in has involved 3 particular types of pain.

1. You start with the very human problem of defining what ‘quality’ even means in your domain. If it isn’t defined, we can’t engineer a quality AI solution. But think about what a good sales proposal, or business strategy, or piece of creative writing looks like. The answer is context-specific, subjective and probably no one’s tried to define it before. I’ve been tasked with forming these definitions with domain experts across retail, energy and professional services. It’s literally never been straightforward. The conclusion is typically a multi-faceted list of principles no one is fully happy with. And it always turns out to be somewhat wrong once we start testing things for real.

2. Then you need to measure whether the blobs of text / code / visuals your AI spits out actually align with your multi-faceted definition of good. This task is unlike any traditional software testing. Most of the issues you encounter aren’t clear ‘bugs’. They’re subjective: is the tone of this paragraph really matching our tone of voice guidelines? Is the LLM citing the same document a domain expert would choose? There’s a whole AI Evaluations discipline emerging around this challenge, led by people like Hamel Husain. But it’s a new world and probably no one’s good at it yet.

3. Finally, once you’ve actually found a measurable problem, you need to decide how to develop your LLM pipeline to move the needle. But the right prompting, RAG, workflow and agentic approaches to use are constantly changing, with few established best practices. What’s worse; these bloody LLMs are so damn sensitive and unpredictable. So, if you’re not careful, you can easily get stuck in a never-ending game of AI-engineering whack-a-mole - where fixing one thing inadvertently breaks another.

Within all this pain lies opportunity. NOT writing a few prompts to get your LLM to adopt a superficial persona. But creating a world-class definition of good in a specific domain. Then using the latest evaluation and engineering approaches to get your LLM to reliably meet that bar.

In practice, this might mean:

• Co-creating with clients who really know what good looks like in a particular niche, to define and iteratively build market leading quality

• Finding opportunities in less digitally-native sectors that the big players aren’t paying as much attention to - like construction, agriculture or local government

• Building meta-solutions that make this whole evaluation-driven development loop less painful

Box 3: Proprietary Datasets

The final piece, which often fuels these domain specific AI solutions, is data. Connecting LLMs to the internet or organisational knowledge bases is becoming trivial. But there’s a lot of potential to feed AI with insights from curated datasets that can’t be found anywhere else. Think:

• Competitive intelligence that enables you to quickly benchmark against your peers in a particular domain

• Market intelligence that enables you to understand emerging trends and customer behaviours

• Groundtruths and rubrics that show AI what good looks like in a particular task

There’s already a whole market of third party data providers, which are worth using. But what interests me most is the new types of datasets LLMs are enabling us to create.

LLM-Enabled Datasets

We can now use AI to harvest data from noisy sources, clean it, and enhance it in ways which would have previously required human judgement. The data generated from AI interactions is also creating a whole new data source to work with (carefully and transparently).

We explored this at my previous company, Futurice. For example, we analysed the open job positions companies post online, to see what they were really investing in beyond all their grand public announcements. From this, we were doing automated data & AI maturity assessments, where we compared a company’s hiring with their peers, to map where they stood. We even mapped the data & AI maturity of countries.

I’ve presented these sorts of insights in many leadership rooms, and it always surprises me how much new insight you can give people about their own companies, just from enhancing public sources.

But doing it well is not straightforward - you need to cobble together a dataset with high quality coverage. You need to remove all sorts of boiler plate from the job positions where companies bang on about their green / AI / DEI / impact credentials. You need to define what is and isn’t an AI job, then build AI classifiers that reliably apply your definitions. 3rd party data providers help, but none take you the whole way.

That leaves lots of scope to go deep and differentiate with LLM-enabled datasets like this.

So, that’s my best guess on how to make asset-based consulting work:

• An equal split between consulting and assets - with a real investment in developing a fast learning loop between the two

• Fixed, subscription & outcome-based business models only, to bank the value of that investment

• Building measurably high quality AI solutions in specific domains that AI labs don’t care about, fed by LLM-enabled datasets

It’s a foundation I’m excited to build on! Now just the small task of deciding what specific problems to solve for who first…

If building this sort of company sounds exciting to you too - I’m on the lookout for collaborators. If it sounds like a bad idea - please let me know before it’s too late!

But, it also feels like a rather dangerous time. Few value propositions feel safe from the constantly growing capabilities of foundation models. And there’s a horde of well-backed startups and powerful incumbents fighting over what’s left.

Many are saying that SaaS and consulting are dead, in one form or another.

So, what are the winning business opportunities that remain? I’m keen to explore the answer, so I don’t invest my time and money into something dumb!

Part 1: The ‘death’ of traditional SaaS & Consulting

Let’s start by looking at the supposed victims of AI disruption.

Consulting 🪦

In consulting, the story goes that AI can increasingly do many of the things companies pay consultants for today. Millions already use AI for core consultancy tasks like web research, analysis, content drafting and coding. Even where AI can’t yet do the job on its own, it’s democratising knowledge and helping non-experts catch up. So, why pay expensive consultants for things that AI can do (or help you do) faster / cheaper / sometimes better?

Of course, as AI kills old consulting opportunities, it’s creating new ones. Just about every digitally focused company could improve with AI, but few have the time or expertise to do it themselves. So, there’s a lot of demand right now for consultants who can help.

The challenge for traditional consultancies is that they’re low margin businesses where consultants have to bill as many hours as possible for them to profit. This doesn’t leave much space for developing genuine expertise in fast-moving AI capabilities. Their dominant business model also creates a barrier. Typically, they sell experts’ time by the hour. So, if they use AI to ‘10x’ the output of each hour without changing that model, they’ll just earn less money.

This means existing consultancies have to rethink a large part of their business and operating model to keep up. Most know it - and some will surely manage. But it ain’t easy to do.

SaaS 🪦

In SaaS, the story goes that demand for all sorts of general purpose software solutions will reduce as AI makes bespoke solutions much easier and cheaper to build. AI coding capabilities have been increasing quite dramatically. So, the 100s of thousands of lines of code that were once part of the major SaaS platforms’ advantage may no longer count for much.

Simon Willison recently shared how StrongDM’s engineering team used AI “software factories” to build clones of a bunch of major SaaS platforms just for testing. If I think back to my own SaaS startup in the late 2010s, I’d wager that the platform we spent years building could now be rebuilt better in a weekend hackathon.

With these capabilities, many companies may choose to avoid the pain of adapting to the way Salesforce, SAP, etc., tell them to work. Instead, they’ll either build bespoke solutions tailored to their needs, or choose from the growing wave of AI-native solutions made possible by the low barriers to entry.

Unlike the traditional consultancies, the major SaaS players have huge R&D budgets to invest in AI. But they’re slowed down by legacy codebases and customer expectations to maintain their current products. And they too have a business model that might create a barrier - with price per seat potentially misaligned with a world where agents will replace many users.

Menlo’s 2025 Enterprise AI report gives some insight into how this market is starting to shift away from incumbents:

Enterprise AI has grown from $1.7B in 2023 to $37.0B in 2025, making it the “fastest growing software category in history”

63% of that spend went to AI startups - meaning startups “captured nearly $2 in revenue for every $1 earned by incumbents”.

As a consultant, I’ve really felt this shift in the enterprises I’ve worked with. The mere mention of CoPilot or Agentforce often attracts groans vs. the enthusiasm I see for AI-native solutions like Claude or Cursor.

Incumbents have advantages too

The conclusion you might draw from this is that you can just slap “AI-native” in front of an existing sector that’s soon to die, then wait for the money to roll in. But it’s (obviously) not so simple...

When people buy the products and services of market leaders, they’re not just buying a solution. They’re buying a trusted brand that ticks all the necessary compliance checkboxes and gives the buyer political cover.

I’ve done a lot of sales for both an unknown startup and an established consultancy with 25 years’ history. The difference is night and day. With my startup, there was ALWAYS such a fight to even get a potential buyer on a call. And when we did get a call, the starting point was usually scepticism. Selling for the consultancy was no picnic, but boy did we benefit from inbuilt trust at every step of the process.

Incumbents have distribution channels and switching costs on their side too. You might be able to build a better AI offering as a startup free from legacy constraints. But it needs to be a lot better to convince a customer to choose it over a similar sounding offering from a partner they’re already married to.

These dynamics won’t change overnight.

One option is to choose your battle (SaaS or consulting) then follow the trusted start-up lessons: find a narrow niche with underserved needs, create an easy-to-buy wedge, borrow trust & distribution through partnerships, etc. That’s probably a very solid approach.

But the opportunity that excites me most is what’s emerging in the space between SaaS and consulting - where incumbents may be less able to defend.

The blurring lines between SaaS & Consulting

Since leaving my job, people have been asking me whether I want to start a product company or a consulting one. My current answer is “both”…

AI Agents are enabling software to do more and more consultant-like things. But I believe consultants will still be crucial to turn that software into impact → customising it to really work in each context, driving adoption and redesigning ways of working.

So, what interests me most is what YC calls “AI-native agencies”, what Sequoia calls “software companies masquerading as services firms”, or what I’ve come to know as asset-based consulting. That is:

Solving each client’s specific problem like a consultancy, but doing a large part of the delivery with proprietary data & AI tools - rather than just selling expert time.

This model is only just emerging, so we don’t know exactly what it looks like in practice. But think curated datasets and AI analysis tools that enable strategy consultants to provide genuine insights from day one. Or AI pipelines optimised to a specific industry, that enable engineers to deliver high accuracy AI solutions in days instead of months. It’s applying a product delivery model to the services business.

Done well, this approach can benefit everyone:

• Clients get a better outcome than buying a one size-fits-all tool, and a cheaper / faster one than buying consultants by the hour

• Employees get the satisfaction of directly solving real-world problems and building products that scale their impact over time

• Owners get more SaaS-like margins, while tapping into service budgets - which Sequoia estimates are 6x bigger than software budgets

Some success stories have already started to emerge. Palantir have popularised the “Forward Deployed Engineer” (FDE) role, which sits at the centre of this product-service hybrid. FDEs split their focus between solving complex challenges with individual clients and generalising what they learn in internal products. Each engagement feeds products that enable them to deliver better / faster outcomes for the next client. Palantir certainly don’t seem to be using their power for good, but nailing this product / service hybrid has been the “secret sauce” in creating a valuation that’s fluctuated between 50-100x of their annual revenue. For a traditional consultancy, that number is typically more like 1-2.5x.

Rough analysis shows the FDE role grew >1000% in 2025, with the likes of OpenAI, Anthropic, Cohere and Salesforce all jumping on the bandwagon. And, from the other side of the fence, all the major consultancy players have been accelerating their productised offerings with AI; from McKinsey’s QuantumBlack, to BCG X, and Deloitte’s CortexAI.

But it’s easier said than done…

The challenge is that this move to the middle is super hard to pull off from either direction. Because, today, product and service companies are completely different worlds - with different operating & business models, client buying expectations, capabilities and culture. So, neither are set up to do what the other does well.

For the last few years of my consultancy life, everyone has been talking about asset-based models. I’ve seen plenty of aspirational comms. But I’ve seen basically no one shift a significant chunk of their revenue to new models. They’re unable to find the budgets or operating model needed to build anything real. They lack the product expertise to build the right things well. Or they fail to convince clients to buy from them in a different way.

There’s a gravity pulling them to the status quo that got them to where they are. Every investment into products hurts the UTZ & EBIT numbers leaders are responsible for. And there’s no shortage of cautionary tales from past product efforts to cast doubt on whether that investment will ever pay off.

This challenge is what gets me excited. Beyond a handful of pioneers, very few seem to have the right capability mix, operating model or business model to succeed with both consulting and product today. And changing all of those things will be really tough for incumbents.

But a new player can design everything for ‘asset-based consulting’ from day 1. So, (I think?) that’s my plan.

On its own, this would be a pretty damn high-level plan! So, I’ve also been exploring what an AI-focused, asset-based consulting company looks like in practice: how does it operate, what problems does it solve, and where does its competitive advantage come from?

More on that in part 2.

We’re bad at thinking statistically.

As Daniel Kahneman said, our brains are like machines for jumping to conclusions. We hate uncertainty and ignore the role of luck. We see patterns and stories where they don’t exist. And we’re often blind to data that challenges our pre-existing beliefs.

Yet, thinking statistically is a skill we need in almost everything we do. In any decision we deliberate over, we’re weighing up some sort of data. Whether that’s evaluating the claims we’re bombarded with in the media everyday. Picking our careers. Or finding new strategies to address the world’s most pressing challenges.

So, it’s a bit of a problem.

But, for most, it’s a problem we find easy to ignore

Poker — A lab for exploring how we think about data

As a professional poker player, I spent years studying ‘Poker Solvers’ — that is, computer programs that calculate Game Theory Optimal poker strategies.

Sparing you the details, with a solver you can set up any poker scenario > click go > then get back a huge amount of data on how every hand in that scenario would be played by two perfect players.

Poker’s way too complex to just copy everything the solver tells you. So your task was to understand why the solver was telling you to play a certain way. With clear principles, you could then generalise strategies across thousands of scenarios and adapt to novel situations on the fly.

In essence, it was about spotting the signal in the noise of a whole lot of data.

This task was a great laboratory for exploring our problems with statistical thinking. Because you could gather data, develop hypotheses and get good feedback on their validity in a matter of days. And your only real incentive was to be accurate. So the learning cycles were fast and focused on just you and the data.

Unfortunately, the feedback I got rarely had good things to say about my natural instincts…

So many questions, so little time

The first challenge with solvers was choosing the scenarios to ask our new robot overlord for help in. With only so many hours in the day, we had to define a limited number of questions, among a basically unlimited number of possibilities. Which created a lot of room for error.

Whenever we uncovered a new principle that explained a bunch of weird results it felt great. Running more scenarios to see if it unravelled did not. So there was always a tendency to under-test our hypotheses. And that was easy to justify based on resources — as we couldn’t test everything, could we?

When we did run a test, I’d find myself automatically trying to explain away any conflicting information it dished up. It felt so natural to craft a fancy rationalisation that allowed me to chalk it up as an exception, then get back to the fun stuff.

Essentially, whenever I was balancing the trade-off between time and further research, there was always gravity towards doing what was least disruptive to my current understanding.

That’s pretty dumb, when the whole point was to find better strategies. And the less they resembled my current understanding, the more opportunity they offered to increase my edge.

But conflicting results meant;

• My current understanding was wrong and I was less awesome than I thought.

• I’d have to study more and play the game I loved less.

• I’d have to move from being clear to being uncertain.

These all felt painful. And, intuitively, that was pain I always tried to avoid.

JesusToastFace

This was made worse by the way our brains jump to conclusions. When we see noise, we naturally look for signal, even if it’s not there. So infinite data can just give us infinite ways to find a pattern that supports what we want to believe.

There were many times I’d stitch together a story that supposedly explained the exact reason why the solver was telling us to play a certain way. It’d feel so right. I’d have no shortage of great logic to back it up and I’d keep seeing other data that confirmed it. Yet, as soon as I’d run a robust test, all that clarity would come tumbling down.

This affliction had a few nasty elements:

• It couldn’t be switched off. I could rarely just sit with uncertainty — accepting that I needed more data before any meaningful conclusion could be made. With whatever limited data I had, my brain was always busy spinning up a story which could send me off in the wrong direction.

• The stories it cooked up weren’t an objective estimation of what was right, either. My brain naturally latched onto things I wanted to believe. Stories that avoided the painful task of going back to square one and often ended with ‘I was right all along!’

• To top it all, the principles that conflicted with my prior beliefs never benefited from this auto-search function. This is where the biggest learning was, yet uncovering these principles was usually a much more painful process — if I wasn’t blind to them entirely.

We called this thinking JesusToastFace. Like people are primed to see faces (often Jesus’) in random places (sometimes toast), whenever we thought we uncovered a new principle of good poker strategy, we’d ask ‘Is this just JesusToastFace again?’ And the answer was often yes.

Assessing what worked

Once we finally reached the tables to apply our new robot-approved strategies, there was always some doubt about whether they were actually good. But, in poker, the luck factor means that a winning strategy could lose for months or even years. So assessing what worked wasn’t easy.

The problem was, when I won, my brain would tell me it was because I was awesome. But when I lost, my brain would tell me I was just unlucky.

This was particularly problematic when my strategy was the result of 100s of hours of solver research. I had mathematical “proof” that I was right and this idiot across from me kept getting lucky. What injustice! When it served my ego, it wasn’t difficult to forget the fact that my ‘proof’ might be based on a narrow data set that I analysed badly.

To really uncover mistakes, I needed to be laser focused on all the weak signals — how my opponents were reacting, how their approach differed from mine, or where new solver data might put old principles into question. Then I needed to re-start the cycle of running tests and analysing the data. But, the whole time, there was this internal lawyer in my head, telling me not to raise the alarm.

You suck too

If you’ve taken any interest in behavioural science, I doubt any of this is new to you. Behavioural scientists have fancy names for most of what I’ve described (for example; what you see is all there is, theory-induced blindness, confirmation bias, the narrative fallacy, the representativeness heuristic)

What was unique about poker was how often I got to see myself making these errors. This meant the problem — that I was bad at thinking statistically — wasn’t just an intellectual curiosity or something I’d spot in others. It was something I absolutely had to work on.

In most other paths in life, you can get by barely noticing these errors. When we make decisions to improve our lives, our workplaces and our societies, it can be months or years before we get any feedback on whether we were right. And it’ll usually be ambiguous, in a way that makes it easy for us to rationalise away any harsh truths. So this problem can be really easy to ignore.

But poker players are good at this stuff, and I was good at poker. And by any objective standard of rationality, I suck at thinking clearly about data. So you almost certainly do too.

That means, whether you’re assessing hard numbers, case studies, stories or feelings, you’ve probably made lots of errors in reaching the conclusions you hold dear.

And if you thought more clearly about that data, you might find a lot of room for improvement.

So, what’s the solution?

The solution is not to ‘unbias’ yourself. Behavioural scientists have shown that these errors in thinking aren’t quirks we can easily overcome. They’re the product of millions of years of evolution.

Learning all the names of your favourite biases won’t help much either. Turns out, even the behavioural scientists studying this stuff are seeing a lot of jesus in their toast — meta studies have shown that a majority of their findings can’t be replicated.

What I’ve seen in everyone who’s good at this is a certain mindset:

• Humble: They recognise their own fallibility and are prepared to be wrong — a lot. Even if they’re confident in their abilities relative to others, they recognise their limits vs. a complex world.

• Curious: They reflect on their bias, play devil’s advocate with themselves, and really listen to alternative perspectives.

• Proactive: They ask the difficult question, even when everyone else feels clear. They test their hypotheses, even if unravelling the clarity they’ve built up would be painful.

In Phil Tetlock’s research into expert judgement and forecasting, he identifies similar traits outside the bubble of poker too. As he says, these people treat their beliefs as “hypotheses to be tested, not treasures to be protected”.

With the right mindset, these clearer thinkers then practice interventions that help them limit the impact of their bias. The biases don’t go away. But, with enough practice, the interventions can slowly but surely become automatic too.

In poker, these habits emerged for us:

• Question your questions, before you ask them: What other questions could you ask? What will your data not tell you? Make limitations explicit or else they’ll disappear from later discussion.

• Make proper predictions, before collecting data: When you’re wrong in a way that can’t be ignored, it’s much harder to rationalise away conflicting evidence and keep your current understanding intact. And it’s the best feedback you’ll get to help you learn.

• Always ask; is this just JesusToastFace? Your brain is a machine for jumping to conclusions, so question it’s outputs. Do you have sufficient data to make any meaningful conclusion? Does your story stand up to scrutiny? Where practical, test your hypothesis in a rigorous way, however right it feels.

• Be social and talk about bias: it’s much easier to spot bias in others. So share stories about your own bias and try to make it a safe thing to talk about in your team.

What works for you will depend on your context. So cast your net widely for inspiration (Tetlock’s Superforecasters is a great place to start) and start experimenting.

In all, there’s no shortcut. It’s like building any other skill — practice, reflect, learn. The good news is that you don’t need any fancy technical expertise. Just a willingness to make mistakes and learn from them.

The world needs more statistical thinkers. So get started :)