When we start out on a new project with a client, we get every member of staff involved in a mini competition to name the system that we're building. This article will explain the reasoning behind this and why it's so critical to the process of delivering a successful project.
We humans name things. We name our cars, plants, sourdough starter and of course we name our children. Naming things gives us an immediate bond with that thing or person. Granted, when my own children were born, my wife and I didn't know their genders, but we did have name choices. But I also understand the desire to know, because for one, you can form an immediate bond with your baby through its name. The other thing about naming things is that it is entirely in your control. No one else is there saying "this is its name, so you can't change it".
And so it is the same with software. Usually, when buying software, you're told its name, and it's not usually much fun either. You've had no control over it, so you have to develop a relationship with it over time. That relationship could go in any direction, depending on whether the software in question is any good or not, but it's never a tight bond. You never look at Xero and smile, or Zendesk and have a chuckle, or reminisce about SAP.
On the other hand, we put that ownership into the hands of the people who will use it, and it creates an immediate personal bond. You no longer talk about "the system", but instead find yourself talking about Dave, Hugo, The Oracle, The Abyss, Jordan or whatever your name is (these are actual names our clients have given their systems). And each of these names has a story. Dave is named after the late father of the founders of that particular business, with a unanimous decision to raise new Dave in his memory.
Hugo came about because the system was originally called BOS and every time the name came up, the staff thought about, well, Hugo. So the name was changed, and stuck. The Abyss is a service desk platform for an IT support company, and it's where all your tickets go.
What they all have in common though is that initial bond. And that bond carries through to execution because those same people who named it feel empowered to help guide it on its development journey. As a result, those staff feel a loyalty to both the business and the people in it, and so they stay longer. But they also find themselves smiling at Dave, for reasons beyond my comprehension (because if you think about it, smiling at software is weird and unnatural). And it turns out the best place for your support tickets really is The Abyss.
Because people smile at the software we build, they are less stressed, more productive, and more engaged with the business, more than just their specific task or role. That means the business has lower overheads as the software helps guide and handle all the boring work, leaving staff clear to work on continuous improvement. Further, we find that because people stay, the business doesn't suffer knowledge loss, or rehiring costs, and the staff become evangelists for the system meaning zero system training for new starters.
And so to the business, and its staff, the spoils. More time, less stress, more profit, lower overheads, a jump (more like a giant leap) up on the competition. And the opportunity cost (ie. what if you didn't?) doesn't bear thinking about.
