A few years back, during a project kickoff, we organized our engineers into teams, each intended to solve specific problems and deliver subsets of the overall project functionality. Experimenting with some Agile concepts, we invited the teams to name themselves.
The team I was leading took this opportunity seriously; we campaigned for names we liked, we had suggestions both serious and humorous, and in the end we voted. Our team name became Daemon. We adopted the FreeBSD mascot for our informal internal communications, and often accompanied our team name with the following quote someone found online describing Unix daemons:
Thus, a daemon is something that works magically without anyone being much aware of it.
Over the next year, our team shifted to align with that definition. We took pride in low bug counts, in delivering services that “just worked” and required very little configuration or setup. Our focus shifted away from administrative use cases and focused more on infrastructure. We sought out work that aligned with our mission.
In other words, naming ourselves helped define and shape our behavior.
We obviously took the name because we were proud of our ability to quietly deliver high quality work. But that in turn shaped us to focus more on the traits we took from our name.
As another example, I’ve noticed this same pattern when defining strengths in performance reviews. Once someone names a strength, they are more apt to think of that as a character trait and seek out opportunities to prove it again. Likewise, once the team leadership begins to discuss a person in certain terms, those terms may follow that person around their career (for better or worse).
So naming (or even labeling) can be powerful, and we should respect that. Use it to your own advantage (the ever-present “personal brand”), help your teams use it to define their mission — but use it cautiously when defining others.
