Your Language Is Not a Reason to Rebuild the Basics

By David Figueroa

Someone weighing a fully custom build said this to me: "No one can understand our language, so we need to build everything ourselves."

The concern is familiar. It is also a reasonable instinct. Every organization has its own names, its own workflows, and its own rules. Operators are the ones who use the words to move the work, so the difference feels larger to them than it may be. The question is whether that difference justifies building everything.

It usually does not. The work underneath the names still has to be performed, whoever you are. Give a deal stage a name no other company uses. It is still a stage. You own the word. Nearly everyone else still has to perform the same function. Living inside the local words does not turn a shared function into a private one.

Before you approve the build, map what the system must actually do. Take the internal terms off the table and list the actions.

It has to capture information. It has to apply logic. It has to move work forward. It has to report results. It has to support decisions.

That list is not glamorous. It is the work. Once the work is described as actions instead of as the words your team uses in meetings, the differences between organizations get smaller than they first appear. The names were doing much of the convincing. The actions are widely shared. An operator who can say the actions out loud has already done the hardest part of the review.

That is the cut I want made before money and people are committed. Keep the parts that are common across organizations maintainable. Put customization on the operating model, which is where the business value sits. Your specific model belongs there. Your thresholds belong there. Your way of working belongs there. Those are worth making your own, because they change what the company does, not merely what it calls things. The basic capabilities under them are not a strategy. They are a load you will have to carry if you rebuild them from scratch.

Every company has work it treats as its own creation. People built it. They grew it. They taught everyone around it to speak its language. The attachment is real. It does not change the upkeep. They still have to breathe. They still have to connect to other systems. They still have to be maintained. Custom work does not stop costing you after launch. The commitment continues. Launch day is the start of that commitment, not the end of it.

So translate before you approve. Take the language your team is protecting and turn it into functions. Some differences will still matter. When they matter, they usually show up as a threshold, a rule, or a way of working, not as a private version of capturing information or moving work forward. Many of the underlying problems will look familiar once the names are stripped off. When they look familiar, the better answer is a system that works in your language, on top of capabilities that are already proven. The worse answer is a rebuild of the basics, justified by a vocabulary no outsider knows.

Operators are the right people to force that translation. You know which threshold is truly yours. You know which name is only a local label for a step other companies also perform. A deal stage with a private name is the example I trust, because I heard one offered as proof that the whole system must be original. The name proves that you have a language. It does not prove that capture, logic, movement, reporting, and decision support are yours alone.

If you skip the translation, you will fund a custom system that recreates those five actions, and you will call the result unique because it uses your words. You will also inherit the commitment that follows. Someone has to keep it breathing. Someone has to keep it connected to other systems. Someone has to maintain it. That is a long commitment for a difference that was mostly in the words.

Ask for the function list before you ask for the build plan. If the list is those five actions, do not rebuild them. Customize the operating model that sits on top: the thresholds, the rules that are actually yours, and the way your people work. Leave the common capabilities in a form you can maintain. A local language is a reason to make the operating model yours. It is not a reason to own every basic capability underneath it.

Say the concern back in plain words before you approve anything. "No one outside can understand our language" can be true. "Therefore we must build every basic capability ourselves" does not follow. Translate first. Then decide what is actually custom.

David Figueroa is president of PRIME-TIME Systems.