Your Team Agreed on Success? You Have a Problem
Knowledge Management start with knowing what you want.
This article explains how semantics and AI can help you better define what you want and align it with what other want.
When everyone nods at the word “success,” they are usually agreeing to different things, and the bill arrives late.
The kickoff of your project goes well and people agree the initiative will be “a success,” and everyone leaves the room satisfied. Four months later the same people are in conflict: The sponsor wanted visible momentum, engineers wanted a system they could maintain, compliance lead wanted an audit trail and a user, somewhere, just wanted the thing to be easier than the spreadsheet it replaced. Nobody lied in that first meeting, they simply heard the same word and filled it with different meaning.
This is the failure that happens before any deadline slips. Most teams treat success as an outcome to be measured at the end; I think it is better understood as a definition to be negotiated at the start. The team that makes that definition explicit early wins back the months that other teams lose to quiet, accumulating misalignment.
Success is not one thing
Ask ten capable people what success looks like and you will get ten defensible answers. One means hitting the goal, another means the result actually worked in the world, a third means recognition, a fourth means the team learned something it can reuse, a fifth means nobody burned out getting there. These are not competing errors to be corrected but different facets of a genuinely multidimensional idea: achievement, effectiveness, recognition, well-being, meaning, relationships, growth, and legacy can all be called “success” without anyone misusing the word.
Philosophy has circled this for centuries. The Western tradition tends to frame success as personal: Aristotle’s flourishing, Emerson’s self-reliance, Nietzsche’s self-overcoming. The Confucian and Platonic traditions tend to frame it socially, as contribution to a well-ordered whole. Both are coherent and simply answer different questions.
That is the practical trap: “Are we successful?” cannot be answered until someone asks the harder version: successful for whom, at what, judged by which standard, using what metrics, over what time horizon, and at what cost? A team that skips those questions only postpones them until they cost more.
The default definition you inherited
No team starts from a blank page; each one carries a default picture of success absorbed from the enterprise culture, and that default quietly decides what gets celebrated.
In much of the Anglo-Saxon business world, the default is the self-made winner: the individual who starts from nothing, works relentlessly, and is validated by visible achievement and financial performance. It is a powerful story and also a partial one: It tends to credit the outcome to individual effort and to discount the conditions that made the outcome possible, the timing, the access, the team, the luck, the contribution of others and the collateral damages. Decades of work on how context shapes achievement, from cultural-values research to popular treatments like Gladwell’s Outliers, point the same direction: visible success is rarely the work of one heroic actor.
Context decides more than we admit. An individualist culture reads moving abroad for a job as ambition; a collectivist one may read the same move against duty to family. A team under survival pressure defines success as security; a comfortable one redefines it as meaning. Short time horizons reward the visible quarter, long ones reward the reputation built over a decade.
When a team adopts its inherited default without examining it, the cost is specific. It celebrates the launch and ignores whether anyone adopted the thing. It rewards the person who was loudest in the room over the one who quietly kept the system running. It books a local win that creates a global loss, the sale that erodes trust, the speed that creates a year of technical debt. None of this makes the default wrong everywhere. It makes it something to choose deliberately rather than inherit.
Why now: cheap signals, expensive illusions
Here is what has changed with social media and generative AI, and why this matters more than it did five years ago.
Producing the appearance of expertise used to be expensive. It required study, access, and time. Now a model can draft it, a platform can amplify it, and a template can make ordinary thinking look authoritative. The signals we once trusted as proxies for competence (a polished deck, a fluent explanation, a confident post, a full content calendar) have become cheap to manufacture and therefore close to worthless as evidence.
That collapse changes the meaning of “success”. It can no longer be visibility, fluency, or reach. Those are signals, and signals are now free.
The useful test is a chain, and each link is harder than the one before it: data in context becomes information, information answering/solving questions/problems becomes knowledge, knowledge leads to decisions that shall be executed thoroughly, execution becomes value, value becomes value delivered again and again. Knowing what good looks like is the easy part, and AI has made it easier still. Applying that knowledge under real constraints, a tired team, a skeptical client, a legacy system, a deadline, is harder. Producing something a real beneficiary is measurably better off using is harder again. Doing it repeatedly, under changing conditions, is the only thing that honestly earns the word expertise.
I have watched capable groups mistake motion for progress at every one of those links. The danger shows up most clearly in the metrics we let stand in for reality: number of followers, number of posts, number of pilots, number of dashboards, number of “AI use cases delivered.” Each is easy to count; none of them, on its own, tells you whether anyone is better off. A metric detached from a beneficiary is decoration.
So the question that cuts through it is blunt: who, specifically, is better off, in what concrete way, and how would we know if they weren’t? If a success measure cannot survive that question, it is theater, and the AI era has made theater very cheap to produce.
The move: a shared success contract
People are allowed to keep their own private definition of success. The team’s job is narrower: agree on one shared, operating definition for this work.
Start by making the hidden definitions visible. Ask each important stakeholder a single question: at the end of this, what would make you say it succeeded? Capture the answers without debating them. You are not looking for consensus yet. You are surfacing the assumptions that would otherwise collide in month four.
Then separate two things that teams routinely blur:
- outcomes are what you are trying to achieve
- constraints are what you must not violate while achieving them
“Launch quickly” is weak, rather “Deliver a validated prototype used by at least three pilot teams by September 30, without compromising data privacy or team sustainability” is a definition you can actually steer by.
The hardest and most valuable part is the trade-off conversation. Most teams agree on success only because they have not yet said out loud what happens when speed and quality collide, or when a sponsor’s appetite for visible progress meets a regulator’s appetite for documentation. Naming those tensions early turns them into decisions. Hiding them turns them into politics later.
A workable success contract is short. It names the purpose, the primary outcome, what each key stakeholder needs, how success is defined and will be evidenced, the trade-off rules, the non-negotiables, and when the definition will be revisited.
Make it operational without making it bureaucratic
A contract no one can apply is its own kind of theater. You want to keep the method light.
First, define success in three levels instead of a binary:
- Minimum success is what must be true for this not to count as a failure
- Target success is what would make it a credible, good result.
- Exceptional success is what would make it a model others copy. Three levels stop perfectionism from blocking delivery and stop low ambition from passing as alignment.
Second, measure across more than one dimension. A balanced set covers the outcome, the value created, the quality, stakeholder trust, the health of the process, the learning gained, and the ethical constraints. Mix leading indicators that tell you success is becoming possible with lagging ones that confirm it happened. Adoption, for instance, is not the count of people who logged in. It is whether the right people now rely on the thing for real work and would notice if it vanished.
Third, write it on one page. A simple canvas keeps the conversation honest and repeatable:
Field Prompt Purpose Why does this matter now? Stakeholders Who must judge this as successful? Minimum / Target / Exceptional What does each level look like? Measures and evidence What would convince a reasonable skeptic? Constraints What must not be compromised? Trade-offs What wins when priorities conflict? Owners Who is accountable for each criterion? Review rhythm When do we revisit this definition?
Then revisit it. Success criteria should not change weekly, but freezing them is its own failure. Strategy shifts, stakeholders learn, risks appear. A short, scheduled review keeps the definition alive without letting it drift.
There is a real limit to all of this, and it is worth saying plainly: a success contract written too early, or held too rigidly, can blind a team to a better goal that only becomes visible mid-flight. And any explicit metric can be gamed: name a number, and people will optimize the number rather than the intent behind it. The contract guarantees nothing on its own. It is a forcing function for an honest conversation, and it has to stay open to the possibility that the conversation was, at the start, partly wrong.
Now hand the contract to a machine
A success contract on one page is already useful. Its next job is to become readable by software, because the place where success quietly changes is the place no one can fully watch: the running stream of meetings, transcripts, emails, decision logs, and steering packs a project throws off every week. The knowledge is all there. It is just scattered across different words, formats, and stakeholder dialects, which is exactly why one team can call a project on track while another calls it lost.
Two artefacts close that gap. A terminology fixes what the words mean: what counts as an outcome, a constraint, a measure, a named beneficiary, a trade-off rule. An ontology fixes how they connect: a contract has criteria, criteria need evidence, outcomes must benefit a named person, constraints must not be broken (https://www.biomedima.org/project/biz-val-o/). The terminology gives an AI agent language; the ontology gives it structure. Together they are rails.
That is the line between a generic assistant and a value agent. A generic assistant tells you what was said in the meeting. A value agent asks whether what was said still matches what you agreed success would be. The success contract stops being a document and becomes the object every note, metric, and decision is checked against.
From reporting to steering
Point the agent at the project’s own communication and let it annotate as it reads. “We need to show progress before the steering committee” gets tagged as a visibility expectation and a possible proxy-success risk. “The site teams won’t use this if it adds another login” becomes a beneficiary need and an adoption constraint. Scattered chatter turns into a structured memory of what success meant and when that meaning moved.
Two moves do most of the work. The first is disambiguation: “adoption” might mean training completed, logins counted, or people actually relying on the thing for real work, and only the last is real evidence, so the agent flags the ambiguity and asks the team to choose. The second is reconciliation: a sponsor wants momentum, a process owner wants cycle-time, compliance wants auditability, and these are usually facets of one contract rather than rival definitions, so the agent links each stakeholder need to an outcome, a criterion, a measure, and the evidence behind it.
From there it watches for drift. The outcome slides toward easier outputs. The metric slides toward what is convenient to count. The constraint weakens under deadline pressure. A new stakeholder arrives uncaptured. The word “success” itself shifts meaning between kickoff and crisis without anyone deciding it should. Each of these is cheap to fix early and expensive to discover late.
None of this replaces the project manager, the product owner, or the sponsor. It changes what they can see. Most reporting looks backward and asks what is green, amber, or red; steering asks whether the right people are getting measurably better off, and whether we are still honouring the constraints we set. In a small team a few experienced people can hold all of that in their heads. In a large, regulated organization, no one can, and the semantic layer becomes the shared memory of value.
It guarantees nothing. A project can be fully instrumented and still chase the wrong goal. What it buys is earlier sight of the drift, while correction is still cheap. That is the whole aim: not more governance, but better steering, and success that behaves less like a slogan and more like an operating system.
What this means for leaders
If you sponsor or lead initiatives, change one habit: run the success-definition conversation at kickoff, before the plan, not at the review when expectations have already diverged. It costs an afternoon. It routinely saves a quarter.
Demand a named beneficiary and real-world evidence for every headline metric your teams report. When someone presents “twelve AI use cases delivered” or “engagement up,” ask who is concretely better off and how you would know if they weren’t. Refuse proxies that cannot answer.
Write the trade-off rules down while everyone is still calm. “When speed and compliance conflict, compliance wins” is cheap to agree to in a planning room and expensive to litigate in a crisis. And set the review cadence that lets the definition evolve on purpose rather than by drift.