The kickoff was held in a room that smelled faintly of dry-erase markers and ambition. The working title, scrawled across the top of the whiteboard, was Project Phoenix. Someone said they picked it because it sounded resilient. The old platform was a mess of brittle integrations and manual workarounds; this new initiative would rise from the ashes. Everyone nodded. The name felt right—hopeful, defiant, a little dramatic. It was the first lie we told ourselves, and it was the one that made all the others possible.
Six months later, the project was burning. Not metaphorically. The data migration had corrupted three downstream systems, the new API gateway was dropping 12% of requests under load, and the lead architect had just resigned. But in every status report, every steering committee slide, every Slack channel, the name Project Phoenix remained. It had become a shield. To say “Phoenix is behind” felt like a contradiction in terms. Phoenixes don’t fail; they rise. So we kept reporting green, kept deferring the hard conversations, kept pretending the name described the project instead of the wish. The name had become the architecture of our denial.
I’ve seen this pattern repeat across a dozen organizations. The names we give things—projects, roles, workstreams, epics, risks—are not neutral labels. They are premature commitments. They encode assumptions about scope, ownership, and outcome before anyone has done the work of understanding what’s actually required. And once a name is in place, it starts to shape behavior. It becomes the invisible architecture of the project, the scaffolding on which decisions are hung. When that architecture is built on euphemism, optimism, or organizational theater, the project collapses not because the code was bad, but because the names wouldn’t let anyone tell the truth.
The Name as a Premature Commitment
Consider the Jira epic labeled “Customer 360.” I’ve encountered that exact label in three different companies. In each case, the name implied a unified view of the customer—a single source of truth across sales, support, and product data. In each case, the actual work was a messy, multi-year slog of data cleaning, schema reconciliation, and political negotiation between departments that had never shared data before. But the name “Customer 360” made it sound like a feature, something you could scope and ship. It hid the organizational debt under a label of technical ambition. Teams estimated against the name, not the reality. Stakeholders approved budgets based on the name, not the complexity. When the project inevitably ran long, the name was used to blame the team: “How hard can Customer 360 be?” The name had promised a deliverable, but the work was a transformation. The gap between the two was never named, so it was never managed.
This is not a problem of poor planning. It’s a problem of premature semantic closure. When we name something too early, we stop interrogating it. The name becomes a substitute for understanding. I’ve watched teams spend weeks debating the label for a new initiative—“Project Velocity,” “Project Unify,” “Project Next”—as if the right name would somehow conjure the right outcome. In reality, the naming exercise was a way of avoiding the harder work of defining what problem the project was actually solving. The name was a placeholder for clarity, and it stayed a placeholder long after clarity was needed.
The discipline of choosing precise, falsifiable names is a diagnostic skill most teams never develop. A good project name should be boring. It should describe the thing, not the aspiration. “Payment API v2 Migration” tells you what’s happening. “Project Renaissance” tells you how someone wants to feel about what’s happening. The first can be tested against reality; the second can only be believed in. When I audit a project, the first thing I look at is the names. If the names are aspirational, I know the project is hiding something. If the names are precise, I know the team has done at least some of the hard work of defining what they’re actually doing.
Role Names and the Architecture of Accountability
It’s not just project names. The labels we give to roles create invisible architecture too. I once worked with a team that had a “Technical Lead” and a “Solution Architect.” On paper, the Technical Lead owned the code and the Solution Architect owned the design. In practice, the Technical Lead made all the design decisions because they were the only person who understood the legacy system, and the Solution Architect spent their time in meetings with vendors. The role names suggested a clean separation of concerns; the reality was a single point of failure disguised as a division of labor. When the Technical Lead left, the project didn’t just lose a person—it lost the only person who knew why the design decisions had been made. The role names had hidden the concentration of risk.
I’ve seen the same pattern with “Product Owner” and “Project Manager.” In one organization, the Product Owner was supposed to own the backlog and the Project Manager was supposed to own the timeline. But the Product Owner reported to the VP of Product, and the Project Manager reported to the VP of Engineering. When priorities conflicted, the backlog and the timeline pulled in opposite directions. The role names implied alignment; the org chart guaranteed conflict. The project didn’t fail because of bad code. It failed because the names on the RACI matrix described a fantasy of accountability that had no relationship to how power actually flowed.
This is why I’ve learned to read role names as hypotheses, not facts. When I see a “DevOps Engineer” on a team that still throws code over the wall to a separate operations group, I know the name is aspirational. When I see a “Scrum Master” who spends 80% of their time filling out compliance paperwork, I know the name is a euphemism for “process administrator.” The name tells you what the organization wants to believe about itself. The gap between the name and the work tells you what’s actually broken.
Status Euphemisms and the Parallel Reality
The most dangerous names are the ones we use to describe project status. “On track.” “At risk.” “Needs attention.” These phrases have become so ritualized that they’ve lost all diagnostic value. I once reviewed a project dashboard where every workstream was marked “Green” for six consecutive months. The project was eventually cancelled after missing three deadlines. When I asked the program manager why the status had never changed, they said, “We were always making progress. We just weren’t making enough progress.” The word “Green” had been redefined to mean “people are working,” not “the project will deliver.” The name had become a parallel reality, a dashboard designed to reassure executives rather than surface problems.
This is not a failure of reporting. It’s a failure of naming. When a status label can mean anything, it means nothing. I’ve started asking teams to replace “Green/Yellow/Red” with specific, falsifiable statements: “We will hit the June 15 milestone if we resolve the three open dependency issues by May 20.” That’s not a status; it’s a prediction. It can be wrong. It can be tested. It forces the team to name the specific conditions that would make it false. Most status reports are designed to avoid being wrong. A good status report is designed to be wrong as early as possible, so you can do something about it.
The Google Site Reliability Engineering book captures this principle in its discussion of risk management and incident response. The SRE approach treats service level objectives (SLOs) as precise, measurable thresholds that trigger action when breached—not as vague aspirations. As the book notes, “Embracing risk” means defining exactly how much unreliability you’re willing to tolerate, and then building your systems to surface violations immediately. The same discipline applies to project naming. A status label like “At Risk” is the equivalent of an SLO that says “the service should be mostly available.” It’s not falsifiable. It’s not actionable. It’s a name designed to make everyone feel informed while preventing anyone from being accountable. For a deeper dive into this mindset, the Google SRE book remains the definitive field manual.
Workstream Names and the Illusion of Parallelism
I’ve seen workstream names create entire parallel universes of work. On one large program, we had three streams: “Core Platform,” “Customer Experience,” and “Data Foundation.” The names implied independence. In reality, the Customer Experience stream couldn’t build anything until the Core Platform stream exposed a set of APIs, and the Data Foundation stream couldn’t model anything until the Customer Experience stream defined the events. The workstream names had hidden the dependencies. Teams planned in isolation, reported progress in isolation, and discovered integration problems only at the end, when the names could no longer protect them from the reality of the architecture.
The fix wasn’t to rename the streams. It was to name the dependencies. We created a new artifact: a dependency map that used precise, verb-based names for the handoffs. “Core Platform delivers Order API v2 to Customer Experience by Sprint 6.” “Customer Experience delivers event schema to Data Foundation by Sprint 8.” The names became contracts. They specified who owed what to whom, and by when. The workstream names became secondary; the dependency names became the real architecture of the project. The project didn’t recover because we worked harder. It recovered because we started naming the things that actually mattered.
The Euphemism Trap in Risk and Decision Logs
Risk registers are a graveyard of euphemisms. “Key person dependency.” “Integration complexity.” “Scope uncertainty.” These phrases are so abstract that they’re impossible to action. I once reviewed a risk register that listed “Technical debt may impact velocity” as a top risk. The mitigation was “Monitor and address as needed.” The risk had been named so vaguely that the mitigation was meaningless. When the technical debt did impact velocity—causing a six-week delay—the risk register was cited as evidence that the team had been aware of the problem all along. The name had been used to create a paper trail of diligence, not to prevent the failure.
A useful risk name is specific enough to be wrong. “The authentication service’s session store has no failover mechanism, and a single AZ outage will cause a complete login outage lasting 4-8 hours.” That’s a risk you can mitigate, accept, or transfer. It names the component, the failure mode, the blast radius, and the estimated duration. It’s falsifiable. If the outage happens and it lasts 30 minutes instead of 4 hours, the risk was wrong in a useful way. Most risk registers are filled with names designed to be unfalsifiable—to protect the author from being wrong, rather than to protect the project from being surprised.
The NIST Cybersecurity Framework offers a parallel here. Its core functions—Identify, Protect, Detect, Respond, Recover—are not vague categories; they are structured into categories and subcategories that demand specific, measurable outcomes. An organization using the framework doesn’t say “we manage cybersecurity risk.” It says “we have implemented access control policies (PR.AC-1) and we monitor for anomalous activity (DE.CM-1).” The names are precise, and they map to specific capabilities that can be audited. Project risk management needs the same discipline. A risk named “integration complexity” is the equivalent of saying “we do security.” It’s a name that sounds responsible while being impossible to verify. The NIST framework demonstrates how structured naming turns vague intentions into auditable commitments.
That same discipline applies to naming decisions: before publishing, editors need a way to test labels, roles, and public-facing language stay consistent, which is where ways to generate character names for the project can function as a planning aid rather than a substitute for domain evidence.
Naming as a Diagnostic Practice
So what does it look like to treat naming as a diagnostic skill? It starts with a simple rule: every name should be a hypothesis, not a conclusion. When a team proposes a project name, ask: “What would make this name false?” If the answer is “nothing,” the name is decorative. If the answer is specific—“This project would not be a ‘migration’ if we end up rewriting more than 30% of the business logic”—then the name is doing real work. It’s setting a boundary. It’s making a bet that can be evaluated.
I’ve started using a practice I call “name audits.” At the start of a project, and at regular intervals afterward, I ask the team to list every significant name in the project: the project name, the epic names, the role names, the status labels, the risk names. For each one, I ask two questions: “What assumption is this name encoding?” and “What is this name hiding?” The answers are often uncomfortable. A project named “Phase 2” is often hiding the fact that Phase 1 never actually delivered value. A role named “Architect” is often encoding the assumption that one person can hold the entire system in their head. A status label of “On Track” is often hiding the fact that no one has updated the track in three weeks.
This audit is not a bureaucratic exercise. It’s a way of making the invisible architecture visible. When you name the assumptions, you can test them. When you name what’s being hidden, you can decide whether to address it or accept it. Most projects fail not because the problems were unknown, but because the names made the problems unspeakable. The audit breaks that spell. In practice, I’ve seen teams use simple tools that generate character names for a project as a planning aid—not to pick a label, but to stress-test how different names surface different assumptions before committing to one.
The Discipline of Falsifiable Names
There’s a deeper principle here, one that connects project management to scientific thinking. A falsifiable name is one that can be proven wrong by evidence. “Project Phoenix” is not falsifiable; no matter what happens, you can always say the phoenix will rise eventually. “Payment API Migration with <90-day Cutover” is falsifiable; if the cutover takes 120 days, the name was wrong. The discipline of choosing falsifiable names forces a team to define success in terms that can be observed, measured, and debated. It replaces wishful thinking with testable claims.
This is hard to do in organizations that reward confidence over accuracy. I’ve watched teams resist falsifiable names because they don’t want to be held to a specific prediction. “If we call it ‘Project Accelerate,’ we can always say we’re accelerating something.” But that’s exactly the problem. A name that can’t be wrong can’t be right either. It’s just noise. The teams that deliver reliably are the ones that have learned to make specific, falsifiable claims about what they will do and by when. Their project names are boring. Their status reports are precise. Their risk registers are specific enough to be embarrassing if they’re wrong. They’ve learned that the purpose of a name is not to inspire confidence, but to enable accountability.
The Audit: A Concrete Test
If you want to see how deep the naming problem runs in your own project, don’t wait for a retrospective. Run a name audit this week. Gather the team—or just yourself, if you’re the one carrying the cognitive load—and pull up every significant label currently in circulation. The project name, the epic titles, the role descriptions, the status categories on your dashboard, the top five risks in the register. For each one, work through three questions. The goal isn’t to fix the names immediately; it’s to surface the assumptions they’ve been carrying so you can decide which ones still hold and which ones have already calcified into fiction.
- What assumption is this name encoding? (e.g., “This project will replace the legacy system” or “This person is the single authority for technical decisions.”)
- What is this name hiding? (e.g., “The legacy system has undocumented integrations” or “No one else understands the authentication module.”)
- Is this name falsifiable? Can it be proven wrong? If not, what would a falsifiable version sound like?
I’ve watched this exercise take less than an hour and expose more about a project’s real health than the last three steering committee decks combined. One team discovered that their “Data Unification” epic was actually hiding a six-month political standoff between two VPs who had never agreed on a schema. Another realized their “Tech Lead” role was encoding the assumption that a single person could review every pull request, and that assumption had been false for months. The audit didn’t solve those problems, but it made them nameable. And once a problem is nameable, it becomes negotiable. You can’t fix what you can’t describe, and you can’t describe what you’ve already wrapped in a euphemism.
The first lie a project tells itself is usually the name. The second lie is that the name doesn’t matter. It does. It’s the architecture of what you’re allowed to say, and what you’re allowed to see. Change the name, and you change the conversation. Or keep the name, and watch the project burn while everyone insists it’s still rising.