There is power in a name. Primitive cultures often believed that to know the name of something or someone is to have power over it. Much superstition, and "magic" or spell casting has been based in this principle. It fact, even in more modern religions, exorcism can require the name of the possessing power, and certainly the deity that is casting out the demon. You may laugh or ask what does this have to do with leadership?
In our enlightened age, we no longer believe that that kind of power is able to be expressed by invoking the name of some person, object, or power. However, in leadership, there is power in naming things. That is, you can name a practice, a brand, a problem, a role – and in effect by naming it, you are claiming power or authority over it. This is true in the same way explorers and frontiersmen in centuries past claimed land in the name of their king, and named that land, thereby solidifying their claim to it.
Now we recognized that naming is only the beginning of it, and that after naming something, one must define it. One must give it boundaries or shape. One may have to conquer the natives who are "squatting". One may have to colonize it. All of these activities are valuable – but none can be done until the thing has a name.
So why is this important? Because names are important. Names have denotative and connotative meaning, they imply specific meaning. In fact, at times, by naming something, you confer definition, and boundaries and shape to something without intending to. Carelessly naming things can cause confusion, and can make subsequent colonization and conquest difficult. If the name is ambiguous, then it needs to be separated by the definition from the other similar things. If a name is meaningless, then it survives on the establishment of a definition or a brand. If the name is misleading (i.e. you call something by a name that confers the wrong definition, boundary, or shape) then you will spend all of your energy explaining it.
Here are some tips or ideas for naming things:
Problems – Names should express impact and/or cause if known. Often problems are named for symptoms, and this can be misleading. (e.g. Client trades delayed by network firewall outage vs. Trader order entry application is unavailable)
Roles – Names should confer responsibility, more than activity. Often roles are based on industry categories or HR constructs, but may those may not be team or project specific. (e.g. Software Quality Analyst vs. Tester)
Practices – Names should articulate principle and activity. (e.g. Domain Driven Design vs. eXtreme Programming)
So when you have the opportunity to name something, take advantage, and then use the name to drive clarity and urgency into the situation, rather than ambiguity, confusion, or apathy.
No Comments