Name the Mission, Not the System
Engineering organizations sometimes organize teams around the infrastructure they run: the Kafka Team, the HBase Team, the Docker Team. That naming convention is a signal that the team's priorities may be pointed in the wrong direction.
The issue is one of ownership. When a team is defined by the system it owns, decision-making tends to optimize for that system's health rather than the company's broader goals. Encouraging engineers to treat a system like a beloved sports franchise creates exactly the wrong incentives. The people who can most effectively advocate for replacing a system are the ones who know it best, and a team named after the system will rarely be the ones to sound that alarm.
From Codename to Strategic Mandate
Dropbox's Magic Pocket storage system went through a deliberate rebranding after launch. The original team, named for the system it built, was renamed the Storage Infrastructure Team. That was not a cosmetic exercise. The goal was to reframe the team's identity around the problem space rather than the particular implementation. If the Magic Pocket system stopped being the right way to store data, the storage domain experts would be the ones to identify that and argue for a change. Naming the team after the system would have aligned their incentives with defending the status quo.
The importance of that framing became clear when the lead engineer made the call to kill a cold-storage project he had championed. The system he was responsible for had become overly complex and wasn't in the company's long-term interest. Killing his own "baby" was the right move, even if it wasn't the easy one. A few days later, he produced a simpler design that shipped ahead of schedule. That kind of judgment is more likely when people see themselves as solving a problem for the company rather than advocating for a piece of code.
Recognizing System Bias
Bias toward a system you've built or operated is natural, but it shows up in counterproductive ways and not just in the obvious forms. The team spending six months to squeeze out a 10% performance gain that no one needed, or insisting that everyone use their internal tooling even when it's the wrong fit, are clear red flags.
More subtle is the tendency to fill sprint plans with work on an existing system simply because there is always more to polish. When a team's mission is the system itself, any improvement can look essential. Engineers who are encouraged to think about the company's problems rather than their system's backlog are better positioned to judge whether a task justifies its cost.
A useful question to ask engineers: if the team's resources could be applied to any project in the company right now, would this still be the best use of time? If the answer is no, the mission is likely scoped too narrowly around the tool rather than the outcome.
Crafting a Broader Mission
Teams should be oriented around the problem they solve, not the tools involved. A good mission statement is short, one or two sentences, and focused enough to create a team identity. It should not lock in implementation choices. Starting with the question "what problem do we solve?" is a reasonable path to a mission that encourages wider thinking.
Fighting Silos Within the Team
Organizational structures can also push teams into narrow, system-focused thinking, particularly at larger companies. Smaller domains within a team create local priorities that can outweigh the team's broader goals. Instead of assigning engineers as direct owners of tiny subsystems, it helps to make them responsible for a sub-priority while remaining part of the larger team's work. A DRI for a component should represent an area of focus, not a permanent identity or an excuse to ignore the team's wider responsibilities.
The point is to make sure engineers are spending their time on problems that matter, not on defending the turf they happen to occupy. A mission statement and a team structure that reward that orientation are the mechanisms for getting there.
