Andrew Ward

"Just confirming, as discussed, that we'll be live by the 28th." Nobody on the team had agreed that date. The email sat in a polite thread for eleven days. No owner. No fallback. Everyone was busy. I've watched versions of that email play out for sixteen years of running Scorchsoft. The work that matters stops moving while everyone stays busy around it. I call it drift, and it costs rework, rescues and trust. So I wrote down what the best operators I've worked with do differently. That became The Control Standard. One idea runs through it: busy is what effort looks like; controlled is what effort produces. It starts with a simple test. Work is under control when it has four things: → one named owner → a dated next step → a decision or escalation date → a fallback With those four in place, someone spots "as discussed" before it hardens into a commitment. The 90-second film below explains the idea. If it rings true for you or your team, the book is out now in paperback, hardback and Kindle: controlstandard.tools/the-bo… #TheControlStandard #Leadership #ProjectManagement #Ownership #Accountability #OperationalExcellence #ManagementTips #BusinessBooks #ScaleUp

Developers, BEWARE of scams like this: a repository supplied in an archive can include malicious Git hooks. Checking out a branch could then trigger a script that downloads and executes code from a remote source. A virus scan may miss it, so a clean result doesn’t guarantee the repository is safe. We’re alert to this kind of threat at Scorchsoft, but it would be easy to overlook. Keep your team informed, inspect unfamiliar repositories before using them, and exercise caution with code supplied by untrusted sources. (The unformatted markdown syntax in the email should also trigger your alarm bells!) #CyberSecurity #SoftwareDevelopment #Git #SecureCoding #Scorchsoft

I discounted my new book, The Control Standard, to 99p on Kindle. Should I keep it at that price? I was lucky enough to get approved for a BookBub promotion, which put the book in front of a much bigger audience.⠀ On 25 September, it sold 236 copies. The following days brought 144, 55, 33 and 28 sales, before settling into a steadier pace of around 10–26 copies a day. That’s almost 700 copies over 18 days, and it’s currently holding the #1 bestseller spot in Career Advancement & Professional Development eBooks. Lovely to see. Slightly less lovely when you look at the royalties. 😂 At 99p, I make roughly 33p per sale. So there’s a trade-off: keep the price low and reach more readers, or increase it and earn more from each copy, potentially losing some of that momentum. My reason for writing the book was to help people take ownership, reduce surprises and become someone leaders trust. Getting it into more people’s hands has value in itself, especially if they read it, use it and recommend it.⠀But how much is that reach worth? And if I raise the price and sales slow down, dropping it back to 99p might not recreate the same momentum. What would you do: keep it at 99p for longer, or put the price back up? I’d be interested in your reasoning, particularly if you’ve faced a similar decision.⠀ If you want to see what the book’s about, it’s here: amazon.co.uk/dp/B0H4LXL5TL #TheControlStandard #Leadership #ProfessionalDevelopment #BookMarketing #KindleBooks

BBVA stopped about 10% of its digital initiatives every quarter. That sounds brutal until you notice the alternative many firms pick: keep almost everything alive, spread good people across too many projects, and then act surprised when none of them moves much. MIT CISR's February 2026 briefing on digital innovation makes a point I wish more leadership teams understood. Successful digital innovation is not one job. It is three different jobs, and when one person or committee tries to do all three badly, the whole thing turns into theatre. Job 1 is the initiative leader. Their job is to prove an idea is desirable, feasible and viable. In plain English: - desirable means customers or users actually want it - feasible means the organisation can build and run it - viable means it can make commercial or operational sense That sounds obvious. Yet plenty of initiatives skip straight from enthusiasm to funding, with very little evidence that any of those three tests have been met. Job 2 is the shared resource leader. Their job is to build reusable capability. This is the bit firms often neglect because it is less glamorous than a shiny new pilot. Shared capability means the data foundations, platforms, tooling, patterns, governance and know-how that multiple initiatives can use. Without that, every team rebuilds the same plumbing in a slightly different way and calls it progress. Job 3 is the portfolio leader. This is where grown-up innovation lives. The portfolio leader re-ranks priorities as new evidence comes in. They move resources. They stop weak initiatives. They pull funding when the case gets worse instead of pretending sunk cost is a strategy. That last job is where many firms lose their nerve. They like the language of innovation. They like demo days, workshops and internal press releases. They like saying they are running 40 initiatives at once. What they do not like is telling a team, politely but clearly, that the evidence is not strong enough and the project is ending. So everything stays alive a bit too long. Nothing gets proper focus. And the organisation confuses activity with learning. The numbers in the briefing are worth paying attention to. Repsol used this discipline to launch 505 digital initiatives over five years and scale 76% of them. BBVA used quarterly portfolio reviews to stop roughly 10% of initiatives that no longer earned the resources. That is a serious operating habit. Quarterly means this was not a dramatic annual clear-out after the budget had already been wasted. It was a regular decision cycle. Evidence came in, priorities changed, and some work was stopped. That is healthier than the usual corporate pattern where dead projects are kept on life support because nobody wants the meeting where it gets called. There is also a useful management lesson here. Autonomy matters. Teams need room to explore, test and learn. But autonomy on its own is not wisdom. If every team gets to pursue its own bright idea indefinitely, you do not have an innovation system. You have expensive parallel play. Real innovation needs freedom at team level and discipline at portfolio level. Those are different muscles. One creates options. The other decides which options still deserve scarce time, money and attention. If you lead an innovation programme, ask a blunt question: what is your kill rate? Not because killing work is virtuous in itself. It is useful because it tells you whether your organisation can update its beliefs when the facts change. If the answer is zero, I would worry. It usually means one of three things: - your standards for evidence are weak - your governance cannot make hard calls - people are rewarded for starting initiatives, not for learning quickly None of those ends well. A portfolio that never stops anything is not full of winners. It is usually full of avoidance. Source: cisr.mit.edu/publication/202…

A semantic layer is what stops AI becoming a very polite liar. Across a lot of firms, the first AI failure is not the model. It is the meaning of the data. That sounds abstract until you see it in practice. One system says a customer is anyone with an account. Another says it is anyone who has paid in the last 12 months. Finance excludes refunded orders from margin. Sales does not. Operations logs an exception one way. Compliance logs it another. Then someone plugs AI into the workflow and expects clarity. The model still answers. Of course it does. That is what makes this dangerous. It answers with confidence built on missing context, mixed definitions and half-true relationships. MIT CISR put numbers on the gap. Only 21% of executives said their data curation practices were somewhat or very well developed. Those organisations were more than 3x as likely to execute value-realising data and AI initiatives, and 2x as likely to report meaningful competitive advantage. That is a useful statistic because it points to something unfashionable: tidy data meaning beats model shopping. A semantic layer is the mechanism for that. It sits between raw data and the user, whether that user is a person, a dashboard, a chatbot or an agent. It carries the definitions, relationships, business rules, permissions and acceptable usage that give data its actual meaning. Plain English: it gives the business one consistent memory. Without that layer, AI has to infer what your business means from whatever scraps it can find. Sometimes it gets lucky. Sometimes it produces something plausible enough to pass a quick glance, which is worse. Bad answers that look polished can travel a long way before anyone notices. This is why so many AI demos look clever and so many real deployments feel flaky. The demo is usually run on a narrow, cleaned-up slice of reality. The live business is full of edge cases, exceptions, old labels, duplicate records, permission issues and definitions that changed three reorganisations ago. And yes, people often ask the wrong question. Boards love asking which model to buy. The uglier question is whether the data underneath the workflow means the same thing everywhere it appears. If the answer is no, more agents do not fix it. They multiply confusion at machine speed. That matters even more now because firms are moving from one-off prompts to AI woven into operations. MIT CISR's August 2026 briefing makes the second half of the point: reliable outcomes at scale are the real test. Not whether the pilot looked impressive. Not whether someone got a nice summary from a chatbot. Whether the system keeps producing dependable results when it touches real work. That is where semantics stops being a technical nicety and becomes an operating issue. If you are a leader, you do not need to become a data architect. But you do need to ask a few blunt questions: - What does this term mean here? - Is that definition the same across finance, sales and operations? - Who owns that definition? - Where do exceptions live? - What is the fallback when the data conflicts? Those questions are less glamorous than talking about agents, copilots and the latest model release. They are also far closer to where value is won or lost. A lot of AI disappointment is really semantic debt. Old inconsistencies, tolerated for years because humans could work around them, suddenly become expensive when machines are asked to act on them. So before you add another layer of AI, check whether your business has one consistent version of what key things mean. Customer. Product. Margin. Approval. Risk. Exception. If those words drift from system to system, your AI will drift with them. Sources: cisr.mit.edu/publication/202… cisr.mit.edu/publication/202…

AI agents are about to get spending power. Not metaphorically. Gartner predicts that by 2030, 1 in 5 monetary transactions could become programmable, allowing money to carry rules about how an AI agent might use it. That could remove enormous friction. It also introduces a completely different level of consequence. The moment AI can spend, governance stops being paperwork and becomes financial control. Have you thought about what this could mean for your business as the agent economy grows?

Manufacturing in the 2010s was still carrying the shadow of 1900. That sounds exaggerated until you see the research. An NBER paper found that the largest US manufacturing firms in the 1910s, 1950s and 2010s disproportionately trace back to around 1900. The authors' explanation is simple enough to matter: scalable technology plus learning-by-doing. In plain English, early entry mattered when it kicked off a learning loop that kept compounding. That is a much better way to think about AI than the usual panic about timing. Founders keep asking, "Are we late to AI?" I think that is too vague to be useful. Late to what, exactly? Buying a licence? Shipping a chatbot? Putting "AI" on a slide deck so the board can feel modern for ten minutes? The better question is this: Where can we start a learning loop that compounds for our business? That shifts the conversation from theatre to advantage. Because durable advantage usually does not arrive with fanfare. It does not show up as one dramatic launch day where you suddenly become uncatchable. It tends to arrive in a less glamorous form: Repeated exposure. Better data. Slightly better systems. Better judgement. A team that sees one class of problem more often than everyone else. That last one matters more than people think. If your team handles the same messy workflow 500 times, or reviews the same type of customer query every day, or spots the same operational failure pattern week after week, you are building judgement. If you instrument that work properly, you are also building data. If you improve the process each cycle, you are building systems. Give that enough time and you stop relying on enthusiasm. You start relying on accumulated understanding. That is why copying someone else's stack rarely copies their edge. You can buy the same model. The same tools. The same vendor. In some cases you can even copy the interface pixel for pixel. What you cannot buy off the shelf is the learning wrapped around it. You cannot instantly import the weird edge cases they have already seen, the prompts they have refined, the failure modes they know to catch, the handoffs they have cleaned up, or the judgement their people have built from using the thing in anger. And this is where a lot of AI strategy goes sideways. Leaders treat the tool as the advantage, so they shop for features. They compare model benchmarks, buy access, run a pilot, then wonder why nothing meaningful changed. But if ten firms buy the same tool, the interesting question is not who bought it first. It is who built the best learning loop around real work. That means choosing a use case where: - the problem happens often - the feedback is clear enough to learn from - the team can actually change the process - the gains stack over time A good AI use case is often a boring one. Not because boring is virtuous, but because repetition is where learning compounds. If I were advising a non-technical leadership team, I would push them away from the grand question, "What is our AI strategy?" and towards something more grounded: Where do we have enough volume, enough repetition and enough control to get smarter every week? That might be support triage. Proposal drafting. Document review. Internal search. Sales follow-up. Operations reporting. Pick one lane where the work keeps happening and the team can learn faster than competitors. The point is not to look advanced. The point is to become hard to catch. Technology shifts do create winners. The durable part is usually the accumulated learning around the tool. That was true in manufacturing. I suspect it will be true in AI as well. Source: nber.org/papers/w34194

Are you the person who fixes everything? That can feel like being valuable. But as an organisation grows, firefighting stops being a strength. What matters is whether people can trust you to take ownership, make good judgements, escalate the right things, and keep things moving without constant direction. That’s why I wrote The Control Standard: a practical way to turn uncertainty, reactivity, and busyness into clarity, ownership, and forwards motion. If you want to become the person leaders trust to own what matters, now’s a good time to pick up a copy.

The UK government is telling civil servants to use AI sparingly to protect the environment. But I think that misses half the equation: What is the environmental cost of NOT using AI? A typical AI prompt uses a tiny amount of electricity. Meanwhile, some government trials have found AI saving workers around 19–26 minutes per day. Those minutes aren't free. They represent human time, laptops and monitors running, offices being heated, commuting, and ultimately the amount of economic output we can produce from the energy we consume. That doesn't mean AI has no environmental cost. Far from it. Data centres use huge amounts of electricity. AI agents can consume substantially more compute than a simple prompt. Rebound effects are real. So are hallucinations, job displacement and governance problems. But measuring the tokens while ignoring the minutes they replace gives you an incomplete answer. And the bigger question goes beyond productivity. What happens if AI accelerates drug discovery, engineering, clean energy, scientific research or economic growth? Even a small sustained productivity improvement compounds enormously over time. So I went properly down the rabbit hole on this one: government trials, model efficiency, data centres, AI agents, productivity research, economics... and an unreasonable number of calculations involving kettles. My conclusion isn't "use as much AI as possible". It's: Use the right AI for the job. Measure what it saves. Count the minutes, not just the tokens. Full video below 👇 How many minutes did AI save you this week?

A 25% AI-driven boost to world output could raise projected warming from 3.3C to 3.6C by 2100. That line should make a few board decks look very incomplete. MIT Sloan's August 2026 piece on AI and climate is useful for one reason in particular: it drags attention back to the rebound effect. The rebound effect is simple. If AI makes work cheaper, faster and more productive, people do more of it. Firms run more processes. Customers consume more output. Markets expand. And the energy and emissions saved in one place can come back through the side door somewhere else. This is where a lot of AI strategy gets a bit childish. The spreadsheet shows labour saved, cycle time reduced, maybe a bump in sales conversion, and everyone nods along as if the case is complete. Then the maths mysteriously stops before power demand, infrastructure upgrades, model usage, reporting obligations and decarbonisation costs enter the room. That is not serious capital allocation. It is a half-built case wearing a suit. Data centres do matter, obviously. Training and inference are not free. If you are adding AI into core workflows at scale, electricity use and compute costs belong in the model from day one. But the more interesting point is that direct compute cost may not be the biggest issue. The second-order demand effect may matter more. If AI helps your sales team process 3 times as many leads, your service team handle more tickets, your product team ship more features, or your operations team squeeze more throughput from the same headcount, the economy does not politely freeze around those gains. Activity expands. More gets made. More gets moved. More gets consumed. Efficiency can lower the cost of action. Lowering the cost of action usually increases the amount of action. That does not mean "do not use AI". I am very much in favour of useful technology. We build software and AI integrations for a living. But it does mean leaders should stop treating efficiency as an automatic climate virtue. Sometimes it is. Sometimes it plainly is not. If you are making AI decisions in a business, I would want to see four things in the case: 1. Direct energy and infrastructure cost. What extra compute, storage, vendor spend and internal support does this create? 2. Demand expansion. If this makes a process cheaper or faster, how much more of that process will we now do? 3. Emissions accountability. How will we measure the extra footprint, report it properly and explain it to customers, investors or regulators if asked? 4. Decarbonisation plan. If AI increases activity, what offsets that increase in practical terms? Cleaner hosting, better architecture, less waste elsewhere, or a deliberate cap on low-value usage? Without those, you do not have an AI strategy. You have a productivity story with the awkward bits removed. And this matters beyond climate. Second-order effects are where plenty of tech decisions go wrong. Leaders approve the obvious gain, then act surprised when the wider system responds. More software creates more process. Faster decisions create more decisions. Easier content creation creates more content to review, govern and store. Cheap output has a habit of generating expensive complexity. So yes, ask what AI can save. But also ask what it causes. That is the more adult question. Source: mitsloan.mit.edu/ideas-made-…

The Census Bureau's new high-tech dataset defines tech better than most board decks. For the September 2026 release, a sector only qualifies if its STEM share was at least 5x the national average in 6 of 11 years. That is a far better standard than the vague corporate habit of calling anything with software in it "tech". And yes, this sounds nerdy. It is also practical. Definitions quietly run strategy. If you use a woolly category, you get woolly decisions. You compare yourself with the wrong peers. You overestimate how digital your market really is. You treat a normal software feature as if it makes you a technology company. Then everyone acts surprised when the economics do not behave like one. A decent category does three useful things. It gives you a cleaner benchmark. If you are looking at growth, hiring, productivity, margins, or firm formation, the answer depends heavily on who got included in the bucket. It stops status inflation. Plenty of firms like the sound of "tech" because it suggests speed, valuation, and modernity. Fine. But strategy built on flattering labels is usually expensive. And it sharpens investment judgement. If a sector repeatedly employs STEM talent at 5 times the national average, over 6 of 11 years, that tells you something durable about how the work gets done. It suggests technical intensity is part of the operating model, not a passing fashion or one ambitious hiring spree. This is the bit boards often miss. Good classification is not admin. It changes what you think is comparable, what you think is possible, and where you think risk sits. Say you run a business with a digital product, some internal automation, and a bit of AI bolted onto customer service. Useful, maybe even commercially important. But that does not automatically place you in the same strategic category as firms whose economics depend on sustained technical depth. Those are different beasts. Different talent mix, different capital needs, different pace of change, different management problems. If you blur them together, you get lazy thinking. You hear "we need to act like a tech company" when what you may actually need is tighter operations, better product choices, or fewer half-funded experiments. I like this Census approach because it is strict enough to be useful. A one-year spike does not count. A fashionable label does not count. The threshold has to hold over time. That is a good general rule for business analysis too. Do not define a company by its slide deck. Define it by repeated behaviour under a clear threshold. The same logic works well beyond sector labels. If you want to know whether a team is innovative, do not ask whether they had an ideas workshop. Ask what they shipped repeatedly. If you want to know whether AI matters in a business, do not ask whether they bought licences. Ask whether meaningful work now gets done differently, consistently, and at scale. If you want to know whether delivery is under control, do not ask whether people feel confident. Ask whether there is a clear owner, a dated next step, a pre-agreed decision path, and a fallback when plan A slips. Repeated evidence beats self-description. So yes, this is a dataset note from the Census Bureau. But there is a wider lesson in it. Better categories produce better judgement. Better judgement produces better strategy. And better strategy usually saves you from spending money to impress yourself. Source: census.gov/data/experimental…