Category Archives: Leadership

One Token, Three Tools Deep, 2,500 Companies Across Five Continents

Posted on by

One leaked automation token. Three tools deep. Over 2,500 organisations across five continents exposed. That is the entire anatomy of 2026’s largest AI supply chain breach, and it took roughly forty minutes to happen.

How a Security Scanner Became the Weapon

In March 2026, a threat group tracked as TeamPCP compromised Trivy, a widely used open-source security scanner, through a leaked automation token. From there the attackers force-pushed malicious code into Trivy’s own version tags. When LiteLLM, a popular AI gateway that routes traffic between applications and model providers, pulled the poisoned scanner into its build pipeline, it published two compromised releases to PyPI, versions 1.82.7 and 1.82.8. A hidden file inside those packages executed automatically the moment Python started, no import required, harvesting cloud keys, repository tokens, SSH credentials, Kubernetes secrets and AI provider API keys from anyone who installed it. The malicious packages were live for roughly forty minutes before removal. That was enough.

 

A Genuinely Global Exposure List

CloudSEK’s analysis, later corroborated by an FBI advisory in July, identified more than 2,500 affected organisations and 434,000 exposed CI/CD pipelines. The named companies span the world rather than one region: AWS, Nvidia, Salesforce and Airbus’s US Space and Defense division from the US, Samsung Electronics and MediaTek from Asia, Siemens, Volkswagen and Munich Re from Germany, Thales and Orange from France, Roche from Switzerland, Philips from the Netherlands, Vodafone and the London Stock Exchange Group from the UK, and Thomson Reuters from Canada, alongside Cisco, FedEx, Deloitte and dozens more. This was never a story about one country’s technology sector. It was a demonstration of how deeply a single open-source dependency now sits underneath enterprise infrastructure everywhere.

 

The Same Argument, a Different Layer

This publication has already made the case that The September AI Outage Had Two Real Causes. Almost Everyone Reported One. LiteLLM extends that argument one layer deeper, into the software supply chain feeding the infrastructure itself. A vendor risk register that lists which cloud provider or model vendor an organisation depends on is no longer sufficient. It also needs to account for the open-source scanners, build tools and CI pipelines every one of those vendors quietly depends on, tools most procurement processes never ask about because nobody signed a contract for them.

 

What a PMO Should Actually Check

Three questions belong on every technology steering committee agenda this quarter. First, does anyone in the organisation maintain a current list of the open-source build and security tooling embedded in critical CI/CD pipelines, not just the paid vendors. Second, when was a leaked or rotated credential last tested as an actual incident scenario, rather than a line item in a policy document. Third, if a dependency three layers removed from a primary vendor were compromised tomorrow, how long would it take anyone to notice. The organisations named in the LiteLLM breach were not careless. They were exposed by a dependency most of them did not know they had, which is precisely the risk a vendor register built only around visible, contracted suppliers will always miss.

The September AI Outage Had Two Real Causes. Almost Everyone Reported One.

Posted on by

On the morning of 3 September 2026, ChatGPT, Claude and Grok all failed within roughly ninety minutes of each other. Within hours, most coverage had settled on a single explanation: a shared Microsoft Azure failure had taken down three competing AI platforms at once. The postmortems that actually exist tell a different story, and the difference matters more than the outage itself.

 

What Each Company Actually Said

SpaceXAI was the most direct. The company confirmed a failure at its Memphis compute facility, apologising to what it called its “impacted compute partners,” language that implies other organisations lease capacity in the same facility. Grok was down for roughly three and a half hours. OpenAI gave its own, separate explanation: an engineer identifying as the incident commander stated on Hacker News that the cause was a routing error inside OpenAI’s own infrastructure, surfacing roughly ninety minutes after SpaceXAI’s Memphis failure and unconnected to the GPT-6 Astra launch that followed the next day. Anthropic never published a technical cause at all. It confirmed elevated errors across several Claude models starting around 9:26am ET and reported the issue resolved, but the actual mechanism behind it was never disclosed.

 

Why the Azure Theory Doesn’t Hold Up

The Azure theory spread fast because it was the simplest explanation available in the first few hours, and it fit an existing assumption that most enterprise AI risk registers already carry: if these vendors compete, their infrastructure probably doesn’t overlap. It did not hold up. Microsoft logged no Azure incident for that window, and Cloudflare said in a statement that it was not experiencing any significant service disruptions. The timeline argues against one shared trigger too, SpaceXAI’s and Anthropic’s incidents began four minutes apart from each other, and OpenAI’s followed roughly ninety minutes later, a pattern that fits three separate incidents more comfortably than one shared one.

 

The Question Nobody Answered

The part worth noticing is not that the Azure story was wrong. It is that the two companies which did give an explanation gave two different ones, and the one that stayed quiet is the one whose incident opened four minutes before SpaceXAI’s, the tightest timing overlap of the three. Nobody, including Anthropic, ever confirmed or ruled out whether Claude’s infrastructure touches the same Memphis facility SpaceXAI apologised to its partners about. A vendor risk register cannot verify a question its own vendor never answers.

None of this means multi-vendor AI strategy is worthless. It means the diversification most risk registers assume is rarely something a customer can actually verify from the outside, and the one moment it gets tested, a real outage, is also the moment vendors are least likely to disclose the detail that would let you check. Two of three companies gave a specific, different cause. One gave none. Whichever of those a programme is depending on, the honest entry in a vendor risk register reads “unconfirmed,” not “diversified.”

Three Regulators, Three Continents, One 72-Hour Deadline Nobody Is Ready For

Posted on by

Three regulators, on three different continents, converged on almost the same number this year, entirely independently. Washington set 72 hours. Brussels set 72 hours, after an initial 24-hour early warning. Abu Dhabi’s own financial free zones set 24 to 72 hours, depending on which one is asking. None of them coordinated on this. All three concluded, at roughly the same time, that a cyber incident report cannot wait for an organisation to feel ready to send it.

 

What Each Regime Actually Requires

In the United States, the Cyber Incident Reporting for Critical Infrastructure Act, CIRCIA, is expected to be finalised this month. It will require covered entities across 16 critical infrastructure sectors, an estimated 300,000 organisations in total, to report a significant cyber incident within 72 hours and a ransomware payment within 24. In the European Union, the NIS2 Directive is already live. Essential entities, those with 250 or more staff or turnover above 50 million euros, across energy, healthcare, banking, water and digital infrastructure, must send an early warning within 24 hours, a full assessment within 72, and a final report within a month. In the UAE, the pattern repeats at the free zone level. Firms regulated by Abu Dhabi Global Market must report a material cyber incident to the regulator within 24 hours, weekends and public holidays included. Firms in the Dubai International Financial Centre generally work to a 72-hour window. Three jurisdictions, three legal systems, the same rough number.

 

Why This Is a Delivery Problem, Not a Legal One

Most organisations have handed this requirement to legal or compliance to interpret, which is the wrong owner. A 72-hour reporting deadline is not primarily a question of what the law says. It is a question of whether an organisation can detect an incident, assess its materiality, assemble the right people, and produce an accurate report, all inside three days, under pressure, without the benefit of hindsight. That is a programme capability, not a policy position. Legal can tell you what the deadline is. Legal cannot build the operating rhythm that hits it.

 

The Capability Most Organisations Are Missing

The gap rarely shows up in the reporting template. It shows up upstream, in whether anyone can say, inside the first few hours, what actually happened. A US hospital system’s own social media accounts were hijacked by the ransomware group that had already breached it, which posted ransom demands directly to the public before the organisation regained control, a case study in how quickly a slow, uncoordinated response becomes the story itself. A reporting deadline assumes an organisation already knows what it is looking at. Most of the work that determines whether a report is accurate, or even possible, happens before anyone opens the compliance template.

 

What a Real Programme Looks Like

A credible response to any of these three regimes looks less like a legal memo and more like a programme: a named incident commander, a materiality assessment framework agreed before an incident rather than during one, a communications protocol that assumes attackers may control channels an organisation thinks are its own, and a rehearsal cadence, not a policy filed away and never tested. None of that is jurisdiction-specific. An organisation that builds this properly for NIS2 has, with minor adjustment, built it for CIRCIA and for ADGM as well.

The interesting part of this story is not which country moved first. Three regulators, working independently on three continents, arrived at the same conclusion, that organisations cannot be trusted to disclose on their own timeline, so a timeline was imposed. Whichever regime applies, the question worth asking this quarter is simple. Could the organisation hit the deadline today, if the incident happened this afternoon?

Your AI Steering Committee Meets Monthly. Your AI Ships Weekly.

Posted on by

Most AI governance committees meet on a monthly or quarterly cadence. Most AI systems do not wait for them.

Anthropic’s own release notes tell the story in a single scroll. Opus 5 launched in late July 2026, a step-change release over Opus 4.8, which was barely two months old at the time. Sonnet 5 landed a month before that, at the end of June. Opus 4.8 before that, in late May. Opus 4.7 before that, in April, with breaking API changes attached. Opus 4.5 in November 2025. Sonnet 4.5 in September. Six major model versions inside ten months, with incremental API and feature changes logged in between on a near-weekly basis. That is one vendor’s changelog. Most enterprises are running several.

 

The Governance Side Has Not Kept Pace

Deloitte’s 2026 State of AI in the Enterprise survey, covering 3,235 business and IT leaders across 24 countries, found that only 21% of organisations have a mature governance model in place for agentic AI. Meanwhile, 74% of the same leaders expect their organisation to be using AI agents at least moderately by 2027, with 23% expecting extensive use and 5% expecting full integration.

That is not a small gap closing gradually. It is deployment intent running well ahead of the governance capable of managing it, at the exact moment agentic systems are gaining the authority to act rather than just draft.

 

People Have Already Stopped Waiting

The gap does not sit quietly while committees catch up. A Cybernews survey of more than 1,000 US employees found that 59% use AI tools their employer never approved. Among executives and senior managers specifically, the same survey found 93% do the same. The people who would sit on the steering committee approving AI use are, by a wide margin, the people going around it.

That is the quiet part of this problem. The people with the authority to slow things down are the ones setting the pace of the tools rather than the pace of the committee.

 

What Happens When the Gap Surfaces

Gartner’s prediction for next year is specific: 40% of enterprises will have their autonomous AI efforts partly derailed by governance gaps discovered only after a production incident, not before one. Sanchit Vir Gogia of Greyhound Research, commenting on the same data, put the mechanism plainly: “the real governance problem is not model intelligence. It is delegated operational authority moving across trust boundaries faster than enterprises can instrument, constrain, or audit it.” His own warning, in his words: “Do not scale agents faster than you can govern their authority. A small number of well-governed agents will create more enterprise value than a sprawling estate of clever, fragile, over-permissioned digital apprentices.”

 

What Governance Cadence Actually Needs to Look Like

The fix is not more meetings. A committee that reviews AI deployment quarterly cannot govern a system that changes weekly, no matter how thorough each quarterly review is. What changes the equation is moving from periodic review to continuous, tiered oversight: automatic flags for any new agent or capability change above an agreed risk threshold, standing authority delegated to a smaller operational group empowered to act between full committee meetings, and a real audit trail that lets the full committee review what was approved at pace, after the fact, rather than approving everything before the fact and creating the exact bottleneck this problem describes.

Keeping oversight in place does not mean keeping the quarterly cadence that was designed for a technology that no longer exists.

 

The Question Worth Asking Before the Next Steering Committee Meeting

Ask what actually changed in your AI environment since the last meeting, specifically, not generally. If nobody in the room can answer that with real detail, the governance structure is reviewing a snapshot that was already out of date the moment the meeting started.

The organisations that get this right are not the ones meeting more often. They are the ones who redesigned what needs a meeting at all, and gave someone standing authority to handle everything else in between.

The Difference Between an AI Pilot and an AI Programme Is Who Gets Blamed When It Fails.

Posted on by

A pilot has no name attached to its failure. A programme does. That is the entire distinction, and almost nobody treats it as the one that matters.

Ask most organisations why their AI initiative is still called a pilot eighteen months after launch and the answer usually involves budget, integration complexity or waiting for the model to mature. The real answer is simpler and less comfortable. Nobody has agreed who owns the outcome if it goes wrong, and a pilot is the one structure where that question never has to be answered.

 

The Pilot Was Never Built to Answer This Question

MIT’s Project NANDA found that 95% of generative AI pilots fail to deliver a measurable return, based on 150 leadership interviews, a survey of 350 employees and analysis of 300 public deployments. The report itself points to a different explanation: tools that never adapt to how the organisation actually works, budgets aimed at sales and marketing while the real return sits in back-office automation, and internal builds that consistently underperform specialist vendor partnerships.

Underneath all three is the same gap. A pilot is built to prove a capability exists. Whether anyone is answerable for what happens once that capability touches real customers, real decisions and real money is a different question, one a pilot was never built to answer. Most organisations discover this the hard way, months into a pilot that technically works and still cannot get budget to go further, because nobody signed up to own what happens next.

 

Ownership Is the Line, Not Scale or Budget

Grant Thornton’s 2026 AI Impact Survey of 950 senior leaders found 78% lack strong confidence they could pass an independent AI governance audit within 90 days. Among organisations still piloting, that confidence drops further, to just 7%. The gap shows up directly in results: organisations with fully integrated AI are close to four times more likely to report AI-driven revenue growth than those still piloting, 58% against 15%.

Grant Thornton’s Tom Puthiyamadam put the underlying issue plainly: organisations that have invested in governance move faster precisely because they have the confidence to scale, while the ones without it are one incident away from a far harder conversation.

MIT’s own findings point the same way: among the factors separating pilots that scale from the ones that stall, the report names empowering line managers, not just centralised AI labs, to drive adoption. A central lab can build a working model, but naming who answers for what that model does inside someone else’s process is a separate task entirely, one a programme takes on and a pilot leaves undone.

 

What a Programme Actually Commits To

Turning a pilot into a programme is not a budget decision. It is naming, before the next phase starts, who is accountable if the thing fails in production, what failing actually means in that specific context, and what happens in the following week if it does. None of that requires new technology. It requires a decision most organisations postpone precisely because a pilot lets them.

Just 38% of organisations have a formal, comprehensive AI policy in place, up from 28% the year before, according to ISACA’s 2026 research covering more than 3,400 digital trust professionals globally, which means most of what currently passes for AI governance gets improvised the first time something breaks, rather than designed before it ships. An owner named after an incident is not accountability. It is damage control wearing accountability’s name.

The organisations closing the gap treat this as day-one work, not late-stage paperwork. A named business owner, not a technical one, accountable for the outcome. And a clear definition of what failure looks like for that specific use case, agreed before launch rather than improvised during the post-mortem.

 

Whose Name Is on This When It Breaks

Before the next AI initiative gets called a programme instead of a pilot, ask one thing in the room where budget gets approved: if this fails next month, whose name is on the outcome, and did they agree to that before it happened or only after.

Most organisations cannot answer that today. That gap explains why so many pilots never leave the lab.

Patience Is Not Passive. It Is the Hardest Active Choice Most People Never Make

Posted on by

Patience gets treated as the absence of action: the thing you’re doing while you wait for something else to happen. The clearest evidence says that’s backwards, not from child-development research, but from what happens when trained professionals are given a straight choice between waiting and acting. Patience is usually the harder, more active choice, and impulsive action is often the easier one dressed up as decisiveness.

 

Retiring the Marshmallow Test

Any conversation about patience eventually reaches for the marshmallow test, the classic finding that children who delayed eating one marshmallow to get two later did better in life. A 2024 replication study in Child Development, using far larger and more representative data than the original, found the test doesn’t reliably predict adult outcomes at all: nearly every regression-adjusted relationship between childhood marshmallow performance and adult achievement, health, or behaviour came back statistically insignificant. The honest version of patience research doesn’t lean on a famous but shaky finding about children. It looks at what patience actually costs adults making real decisions.

 

The Bias That Makes Patience Feel Wrong

Behavioural economists have a name for the instinct patience has to fight: action bias, the tendency to act even when the evidence says waiting is the better choice, because acting feels like doing the job and waiting feels like doing nothing. A widely cited study of professional goalkeepers facing 286 penalty kicks found this bias in its purest form: goalkeepers dive left or right the overwhelming majority of the time, even though staying in the centre of the goal is statistically the better strategy, since kicks go there roughly 29% of the time. Goalkeepers dive anyway, because conceding a goal while standing still feels worse, and looks worse, than conceding one while visibly trying.

Medical research on “intervention bias” finds the identical mechanism in physicians: doctors reliably feel more satisfied recommending a treatment than recommending watchful waiting, “giving a sense of greater activism in their patients’ care,” even when the evidence supports doing nothing. Neither of these is really about competence. Both are about how much easier it feels to have visibly acted, regardless of whether acting was actually correct.

 

What Patient Leadership Actually Looks Like

A qualitative study of leaders who are known for patience found something specific underneath the trait: patience functions as a decision-making framework in its own right, not an absence of one, guiding a distinct process for weighing a situation before committing to act on it. A separate survey of 578 working professionals found leaders rated as more patient saw their teams’ self-reported creativity and collaboration rise by an average of 16%, and productivity by 13%.

A six-year study of more than 20 pairs of executives working in genuinely volatile markets coined the useful term for what this looks like in practice: active waiting. Not paralysis, and not indecision. Deliberate preparation during a lull, so that when a real opportunity actually opens, the leader can act decisively rather than reactively.

 

Why the Harder Choice Rarely Gets Made

None of the research above suggests patience is passivity’s better name. It suggests the opposite: patience requires resisting a bias that’s actively working against it in the moment, on a soccer pitch, in an exam room, or in a boardroom under pressure to be seen doing something. The impulsive decision is usually the one that requires less discipline, not more, because it removes the discomfort of visibly not acting while everyone is watching.

 

The Actual Choice Worth Making

The next time waiting is the objectively better move and doing something still feels necessary, the honest question isn’t whether patience is the right call. The research says it usually is. The question is whether you can tolerate looking like you’re doing nothing for exactly as long as doing nothing is correct.

Governance Fatigue Is Real, and It’s Killing the Governance That Matters

Posted on by

Every governance failure gets the same response: add a committee. Nobody ever asks which of the five committees already in the room should be deleted.

I have watched this play out on the same programme, twice, thirteen months apart. An incident happens. A review is commissioned. The review recommends a new gate, a new sign-off, a new board with a name that sounds important. Nobody asks whether the five existing boards had already covered this ground and simply were not being used properly. The new layer gets built. The old layers stay exactly where they were, because retiring a control is a much harder conversation than adding one, and nobody wants to be the person who removed the safeguard right before something went wrong.

Multiply that pattern across a few years of incidents, mergers, audits and regulatory nudges, and you get an organisation with more governance than anyone can actually operate.

 

The sprawl nobody planned and everybody built

Governance frameworks get bloated one reasonable-sounding addition at a time, not in a single decision. A near-miss produces a new checkpoint. An audit finding produces a new form. A departing executive leaves behind a committee that made sense under their sponsorship and none under anyone else’s. Each addition was defensible in isolation. Nobody ever sat down and asked what the whole structure looked like once you added them all together.

The organisations most proud of their governance maturity are often the ones carrying the heaviest version of this problem. More boards. More gates. More documented sign-offs. It reads as rigour on an org chart and feels like wading through treacle to anyone actually trying to get something delivered.

 

Fatigue looks like silence, not rebellion

The expensive part is what people do once the meetings stop making sense to them, not the extra meetings. They do not object. They do not escalate the absurdity of an ninth sign-off. They quietly learn which boxes can be ticked without real scrutiny, which approvals are theatre, and which route gets something through fastest regardless of whether it is the correct one.

That is governance fatigue, and it is far more dangerous than having too little governance in the first place. An organisation with no controls at least knows it is exposed. An organisation with too many controls believes it is protected, right up until the one decision that actually mattered slipped through a gate everyone had stopped taking seriously.

 

Clarity beats volume, every time

The research on decision rights backs this up more directly than most governance debates acknowledge. Itonics’s analysis of partner and programme governance found that organisations using a properly maintained RACI framework report 70 per cent fewer “who decides” disputes and 25 per cent faster decision cycle times. RACI works by replacing ambiguity with a single, shared answer to a question that used to require a meeting to resolve, not by adding another layer. The gain comes from governance that is unambiguous enough that people stop needing to ask, rather than from adding more of it.

That is the distinction most organisations miss when they respond to a failure by adding structure. The problem was usually oversight so diffuse that nobody could say, without checking three separate documents, who actually held the decision.

 

The discipline of taking something away

Fixing this requires a habit most organisations have never built: retiring governance on purpose. Every new control should come with an audit of what it is replacing, not just what it is adding. Every steering board should have to justify its existence against a simple test: if this group disappeared tomorrow, what decision would genuinely not get made anywhere else? If the answer is “nothing, it would just move up a level,” that board is inertia with a calendar invite, not governance.

The organisations that manage this well treat their governance structure the way a good engineer treats a system under load, asking what is carrying weight it no longer needs to carry and taking it out, rather than just adding capacity when something breaks.

Governance was never supposed to be heavy. It was supposed to be clear. Somewhere along the way, most organisations mistook the two for the same thing.

 

What We Found When We Measured Adoption, Not Just Deployment.

Posted on by

A go live report is easy to write. Every site is on the new system, every licence is issued, every training session delivered on schedule. Three months later, the usage dashboard tells a different story, and it is the dashboard nobody puts in front of the steering committee.

 

The Metric Everyone Reports

Deployment is countable in a way adoption never is. Percentage of sites migrated, number of licences activated, hours of training delivered, these are the figures that go into a programme status report because they can be measured on the day the rollout finishes. None of them says whether anyone is still using the system a quarter later, or whether they have quietly gone back to the spreadsheet it was meant to replace.

 

The Number Nobody Puts in the Steering Deck

IBM’s 2026 Global CEO Study, based on more than 2,000 chief executives surveyed worldwide by the IBM Institute for Business Value, found that only 25 per cent of workers use AI regularly in their jobs, even though 86 per cent of CEOs believe their workforce already has the skills to do so. Eighty three per cent of the same CEOs said AI’s success depends more on people’s adoption than on the technology itself. The rollout finished on schedule. The adoption did not follow.

 

What Poor Adoption Actually Costs

A Forrester Consulting study commissioned by Whatfix, surveying 335 senior decision makers at large organisations across North America, Europe, APAC and India, put a figure on what that gap costs a mid-sized enterprise, $10.9 million a year, plus 728 hours lost per employee navigating systems that were rolled out but never properly embedded. That is not a training budget line. It is the ongoing cost of a deployment nobody followed up on. The same research found a wide gap between organisations with adoption maturity and those without, 53 per cent of mature adopters reported improved user experience against 28 per cent of the rest, and 56 per cent reported stronger return on investment against 28 per cent.

 

Why Deployment Metrics Miss This

Programme reporting is built around milestones a PMO can close off: go live achieved, training complete, licences distributed. Adoption behaves more like a curve than a milestone, one that keeps moving long after the project has been marked complete and the team has moved on to the next initiative. By the time low usage shows up in a satisfaction survey or a renewal conversation, the people who owned the rollout are three programmes further down the roadmap.

Part of the reason adoption rarely gets measured is that almost nothing in a typical programme is set up to reward it. Vendor contracts are frequently structured around go live milestones rather than usage thresholds, so the commercial incentive to keep measuring stops the day the system switches on. Programme teams are resourced to deliver a rollout, not to own what happens to it afterwards, and by the time adoption data would be available, the team has usually been reallocated to the next initiative. None of this is deliberate. It simply reflects a reporting structure and an ownership structure that both end at the same milestone.

 

What We Started Measuring Instead

On some programmes I have run, the fix had less to do with better software and more to do with what the steering committee agreed to look at. We started tracking active usage at 30, 60 and 90 days after go live, alongside a simple drop off rate, how many people who logged in during week one had stopped logging in by week twelve. We also moved benefits realisation sign off away from the go live date and tied it to a usage threshold instead, so a project could not be closed as successful until people were actually using what had been built. It is a small governance change, and it surfaces problems a deployment report never will.

Rollout dates and licence counts still matter, deployment discipline was never the issue. What most programmes are missing is a second dashboard sitting next to the first one, what deployment made possible, and what adoption is showing three months after anyone stopped watching. The programmes that quietly fail are rarely the ones that missed a go live date. They are the ones that hit it, reported it as a win, and never checked what happened next.

Your Reputation Travels Faster Than You Do. Act Accordingly.

Posted on by

Most executives manage their reputation like a local matter: how you’re seen in this room, on this team, in this market. That’s the wrong frame. Reputation moves through networks faster and further than any individual career move, and it arrives in the next room before you do.

 

The Research Behind Why Word Travels

A 2022 study in Science, based on five years of randomised experiments across 20 million LinkedIn users, 2 billion new connections, and 70 million job applications, found that professional information travels most efficiently through weak ties, not close friends. The loose, wide network of people who know you a little, rather than the small circle who know you well, is what actually carries information about you into rooms you haven’t entered yet.

That mechanism cuts both ways. It is exactly how good work gets you noticed somewhere new. It is also exactly how a reputation for cutting corners, mistreating people, or leaving a mess behind you gets there first.

 

What Happens to Reputation That Travels Badly

The clearest, most rigorously measured evidence of this comes not from executive search literature, which is surprisingly thin on hard numbers, but from corporate governance research on company directors. A 2005 study in the Journal of Accounting Research tracked 409 US firms that restated their earnings between 1997 and 2001. Directors of those firms lost roughly a quarter of their positions on other, unrelated companies’ boards afterward, not just the one where the restatement happened. A related 2007 study in the Journal of Financial Economics found that outside directors named in shareholder fraud lawsuits saw a measurable decline in how many other directorships they held, even at companies with no connection to the original case, at an estimated cost of roughly $1 million per lost seat.

That is reputation travelling, quantified: conduct in one boardroom measurably closing doors in boardrooms that had nothing to do with it.

 

Real Cases, Not Hypotheticals

Steve Wynn resigned from Wynn Resorts in 2018 following sexual misconduct allegations. The consequences did not stay in Nevada. Massachusetts gaming regulators, investigating a market he had never previously operated in, fined the company $35 million and forced it to strip his name from its brand-new $2.6 billion property before it opened, renaming Wynn Boston Harbor to Encore Boston Harbor specifically to distance the business from him. He personally paid $10 million in 2023 to permanently exit the Nevada gaming industry. A reputation formed in one state travelled into a state where he had never done business, and shaped how a market he’d never worked in treated him before he arrived.

Travis Kalanick’s departure from Uber followed him into an entirely new, unrelated venture years later. Coverage of his food-delivery startup CloudKitchens traces his Uber exit “amid a firestorm of privacy concerns, allegations of widespread sexual harassment and gender discrimination,” then quotes a former CloudKitchens executive calling it “the most toxic place I’ve ever seen or experienced,” and an operator who said the company “tried to destroy” the brand he had built there. The new business was never assessed purely on its own merits. It was read through the lens of the one he had just left.

Not every case ends the same way. Andreessen Horowitz invested $350 million in Adam Neumann’s new venture Flow in 2022, valuing it above $1 billion before it had launched, despite WeWork’s collapse from a $47 billion to an $8 billion valuation under his leadership. Marc Andreessen’s public justification leaned on second chances: “we love seeing repeat-founders build on past successes by growing from lessons learned.” Reputation still shaped every headline, every term, and every question asked about the deal, even though it never blocked the capital.

 

Acting Accordingly

One caveat is worth stating directly: nobody has produced a clean statistic for how much weight boards or recruiters place on informal, back-channel reputation versus formal references. That data mostly doesn’t exist, and anyone who claims otherwise is making it up. The mechanism, though, is well documented: wide, weak professional networks carry information fast, and reputational damage in one role measurably reduces opportunity in entirely unrelated ones.

The practical implication isn’t paranoia. It’s that the version of you that shows up in a room you’ve never been in was written by people you may not remember meeting, months or years before you walked in. Act like the story is already there, because it usually is.

EasyJet Fixed an Age Bias in Recruitment. Most Digital Transformation Teams Haven’t

Posted on by

 

The number of easyJet cabin crew aged over 50 has more than doubled since 2022, up 127 per cent, according to the airline’s own figures. EasyJet says crew aged over 60 have “almost quadrupled” over the same period, and the airline has opened a fresh recruitment drive for the 2027 flying season, with applications opening in September. Getting there took a deliberate campaign. A large share of potential applicants assumed cabin crew work was reserved for younger people, and easyJet’s Director of Cabin Services, Michael Brown, put the fix plainly: over-50s bring both the skills to do the job and “a wealth of life experience that is appreciated by our customers and colleagues alike.”

 

This Is a Bigger Problem Than One Airline

The Centre for Ageing Better’s State of Ageing 2025 report shows why that perception carries a cost well beyond one airline. The UK’s employment rate for 55 to 64 year olds sits at 65 per cent, against 75 per cent in the Netherlands and Switzerland and 81 per cent in Iceland. The wider 50 to 64 employment rate sits 14 percentage points below the 25 to 49 rate. Closing that gap by 2030 would add an estimated £9 billion a year to the UK economy and £1.6 billion in annual tax and National Insurance revenue, according to the same research. That is the scale of value sitting behind a single, correctable assumption about who is fit to do a job.

 

The Same Bias, Earlier and More Expensive

The same assumption shows up earlier, and more expensively, in technology. CWJobs, working with the Centre for Ageing Better, surveyed 2,000 UK workers plus 250 people in tech who had experienced age discrimination, and found that tech employees start experiencing age bias at 29 and are considered “too old” by 38, roughly a decade before most people reach senior delivery roles. Forty-one per cent of tech workers report observing ageism at work, against 27 per cent across other sectors. Forty-seven per cent say they weren’t offered a role because of their age, and 31 per cent say they were passed over for promotion for the same reason. “Digital skills shortages mean discriminatory attitudes against age makes no business sense,” CWJobs director Dominic Harvey said when the findings were published, a point that has only got truer as the skills shortage he was describing has continued.

 

The Bias Has Already Reached a Tribunal

In Selazar Limited v McCabe, a tech company’s 29-year-old founder was found to have instructed a recruitment consultant to find “a younger team member who was more in tune with a young tech start company” in place of the firm’s 55-year-old finance director. The tribunal awarded her £125,604.98, including £20,000 for injury to feelings, and heard evidence that the founder had also signalled to potential investors that she was “too old to understand” the business. The case puts a figure on the same instinct easyJet had to overcome in reverse: treating experience as a cultural mismatch with a “young”, “digital” or “agile” identity, rather than as a straightforward capability question.

 

What Transformation Programmes Are Actually Short Of

That instinct is expensive in a way that goes beyond tribunal awards. Transformation programmes run into trouble for reasons that have nothing to do with technical skill: unclear governance, resistance treated as a communications problem rather than early diagnostic information, decisions made by people who have never been accountable for the outcome. Institutional knowledge, stakeholder trust built over years, and the judgement to recognise when a plan won’t survive contact with how the organisation actually operates are not junior capabilities. Screening for “young and agile” screens that experience out at precisely the point a programme needs it most, and does so before anyone has assessed whether the person applying could actually do the job.

 

The Fix Was Never Complicated

EasyJet’s fix did not require lowering a bar. It named the specific bias, redesigned recruitment and onboarding around it, then published the retention data alongside the recruitment numbers rather than stopping at the headline. Technology employers already have research going back years, and a tribunal ruling now sitting on the public record, telling them the same bias exists inside their own hiring and promotion decisions.

 

The Question Worth Asking Before the Next Senior Hire

What’s missing isn’t evidence. It’s a leadership team willing to treat this as a workforce design problem rather than a hiring afterthought. Before the next transformation lead, architect, or programme director role goes out with language built around “energy” or “digital native” instincts, it is worth asking what specific capability that language is actually screening for, and whether the organisation can afford to keep losing the experience it screens out along with it.