Debunking the holy system entity
All that works with software development have been there. Having that discussions with customers/users and stakeholders about an entity or attribute which you cannot fully grasp. You have heard from the previous discussions that this attribute/entity, let us call it MustHave, is really really important and crucial Perhaps you can see it in the contract, the users brought it up during the first meeting and they keep coming back to it.
But you cannot understand why this is so important. For you it’s just another entity or more often an attribute. But for many of the users it’s the very foundation of the system.
In many cases it’s some kind of ID or number. The users know these numbers by heart and often there is one or two who can name all 250 of these unique numbers. But for you… It’s just a number. Why should the users see or know that?
The problem is that if you bring up the issue, stating that MustHave is not so crucial at all; that you can make it visible, mandatory, what ever, but that you see it as anything else in the system, you risk becoming crucified. You get a long lecture about how important Mustave is and how long they’ve been using MustHave in the company.
An you start to think about the new people coming into the company who have to learn all that. And perhaps you try to talk back.
But stop right now and think. Don’t think about how important MustHave is to the system and to the company. Think about how important is it to the users. MustHave can be the one thing that today tell a senior member of staff from a newbie. You are accepted in the group when you know all there is to know about MustHave. MustHave is an initiation rite in the organization.
The users probably does not see is as that. They are so into the ritual that they cannot get above that knowing long number series are no longer important.
What you do when you start treating MustHave as anything else in the system is that you take it from the secret knowledge of the seniors and you make it public knowledge. And the knowledge of all those who have spent decades mastering MustHave becomes useless.
The fastest person in the group is not those who have been there the longest and knows MustHave, it can be anyone who masters the systems.
When you demystify something like MustHave, you change the hierarchy and the definition of a competent employee.
But what should you do? My answer is: Agree in the communication but disagree in the system architecture. Comfort everyone involved by stating how important and special MustHave is but don’t make it special in the system. In all cases I’ve used this strategy, the MustHave of the system becomes debunked by itself. But without stepping on anyone’s toes and by letting people learn a new way without anyone discarding their previous competence.