Why internal names matter
A project without an internal name is a project the team doesn't remember. 'The initiative to migrate the payments backend to microservices' is technical description, not a name. Your team will say it three times and then say 'that project'. Project Atlas will be mentioned in a hundred meetings effortlessly.
Internal names serve three functions: identity (the team recognizes itself working on something with its own name), confidentiality (in-development projects can be mentioned without revealing functionality before launch) and memorability (in post-mortems, retros and future learnings, you remember names better than descriptions).
Apple uses big cat names for OS in development (Cheetah, Tiger, Snow Leopard). Google uses desserts in Android (KitKat, Oreo, Pie). Microsoft uses city names in Windows. These internal conventions create culture and help document decades of projects without name collision.
Conventions that work in software companies
The thematic convention is the most adopted: your organization picks a family (animals, cities, stars, mythology, food) and christens each project with a different member. Advantages: a new project always has available candidates, names share aesthetic, and a newcomer quickly understands the pattern.
The versioned convention adds version prefix or suffix: Atlas v1, Atlas v2. Works if your organization has projects evolving in big jumps. But confuses if Atlas v1 and Atlas v2 are entirely different products: better change the root name when nature changes.
The phonetic convention uses names encoding team identity. If the team is called 'Pampa' and all their projects bear Argentine bird names (Hornero, Cardinal, Condor), it builds squad identity without being obvious externally. This reinforces belonging.
Avoid conventions encoding sensitive info: Project NPS-50 reveals you're behind improving NPS to 50. Project Andromeda says nothing to a casual industrial spy. Internal name opacity is a feature, not a bug.
Common mistakes when naming projects
Names that are already commercial products: Project Slack, Project Notion, Project Stripe. Even for internal use, you generate confusion in docs, JIRA and cross-team conversations. Google searches also contaminate.
Names with politically or culturally problematic meaning: review your proposal before adopting. Operation Spartan is fine, Operation Crusade has problematic historical baggage. Project Neptune is fine, Project Cortez evokes colonialism in LATAM. Your internal name will be mentioned in presentations, emails and eventually leaks: care about connotations.
Names requiring public explanation if leaked: if your project is called Operation Black Box and a journalist discovers it, the name alone is headline. Project Atlas is opaque and boring for external narratives. When choosing, imagine your name leaked in TechCrunch: does it generate scandal or just curiosity?
Overabundance of Phoenix-named projects: probably the most used project name in software. If you want differentiation, avoid common ones (Phoenix, Apollo, Atlas, Olympus). Opt for less plundered mythologies: Norse, Slavic, African, Japanese.
From internal name to public brand
Sometimes the internal name becomes public brand. This happens when the internal project works so well it becomes a product. Spotify's Apollo, the Manhattan Project's Manhattan, Tesla's Olympus are examples. If you raise that possibility from the start, avoid names too team-specific or loaded with internal jargon.
Before promoting an internal name to public, do complete due diligence: trademark check, domain search, social media, conflicts with similar products. What was opaque for internal use can collide ugly in open market. Project Cortana internally is fine; launching Cortana to the world requires you to have the trademark registered.
For projects you know from the start will be products, use two names: one internal (operation) and one for product. This separation lets you keep working on Operation Atlas while developing the public brand in parallel. Atlas can be taken while you're in development; Operation Atlas remains yours internally.
Document your naming system in an internal wiki page. After 50 projects, there will be collisions, doubts and forgetfulness. A simple page with 'Naming conventions · Used names list · Available thematic families' saves future meetings and maintains organizational coherence.