Rami Tamirco-founder and CEO of Salto.
getty
We grew rapidly at one of my previous companies. We learned a lot about our buyers. Then the sales team had a realization and wanted to update a definition in our product and in our CRM. Such a change should have been easy. It was not. And not being able to make it hampered the agility of the entire company.
At the time, I concluded that we had made a rookie mistake. A CRM expert would certainly have solved it. But now on to my next business, and as I talk to others, I’ve learned that this inflexibility is actually inherent in many business systems. I eventually started a company to address this by using software development concepts in business applications.
Today I want to share the story of that unchanging environment and some of the lessons I’ve learned in the meantime.
The unworkable change
At my previous company, our SaaS product was closely tied to our CRM and marketing automation system. We relied on that connection to better understand our prospects’ journey from leads to closed won (or lost) and beyond. We deployed our business systems using external sources and then brought those teams and tasks in-house so we could make changes faster. We wanted our business systems to adapt as quickly as our product.
Then we got into trouble when the sales team asked to change the definition of an ‘organization’. We first made that change to our SaaS product, and it took that team less than a week to complete and deploy. But the operations team couldn’t keep up. They couldn’t even give me an estimate of the time. When I pressured the person in charge, he admitted that making such a change could disrupt the entire CRM production. Or maybe not. But it could. And the danger was too great. He actually refused to try.
We let the indecision linger, and with the change not implemented, our salespeople’s lives became more difficult. The salespeople had to manually maintain the mapping outside of the system, and as we grew, that complexity grew. It burdens that team. And worse, it aroused suspicion because it seemed like we weren’t listening.
Interfaces without code
The reason the outcome of that change was not known was because of the way the solutions are done on top of CRMs and on many business systems: without code.
No-code is a way to democratize software configuration. It’s the point-and-click interface of a CRM, ERP, or other business system that reconfigures the underlying software. It allows administrators, who are not software developers, to build and launch solutions without a research and development cycle.
A no-code interface by definition has no code. And the methods of modern software delivery are based on having text files, aka code. If you have that, you can use a source control system to store versions of it, and this provides the perfect documentation of everything ever done with that system. It’s easy to see what’s implemented and anyone can search to see how different components depend on each other.
The reason my team was able to plan and launch the change in our SaaS product is that they were working with code and thus could use a strong software delivery process. Whereas in our CRM, all that information was buried in a no-code interface that, in order to democratize access, severely limited what they could see or do.
I’ve noticed that most of the systems businesses run today are not code. They are as important as a company’s product, but the way companies build solutions on them is fragile and inflexible because it is difficult to quickly understand what has been implemented.
How to tackle these problems?
If we want to avoid these problems, I think we need more control over our business systems. And we don’t have to invent anything new. We just need to copy the way software is delivered. That industry has spent decades perfecting those practices, and we can borrow. That means pulling bits of your configuration out of those systems and into DevOps tools to document, version, and collaborate.
The best place to start is to define your release process. That means, on paper, defining the stages you follow to release features or configuration changes. For example:
1. Plan.
2. Design.
3. Build.
4. Testing.
5. User Acceptance Test.
6. Launch.
Record what each of those phases means, assign roles to each of the phases, and make sure you have the right controls in place as you progress between the phases. Whenever possible, use sandboxes and don’t (really) apply changes directly to production.
To overcome any challenges, I recommend getting your software team involved in designing it all. They can provide insight into the kind of snags that can occur. For example, plans or processes to undo changes if something goes wrong, ideally automatically based on tests.
All of this can slow things down in the short term, but you can get to a point where a single field change takes your sales numbers down and blocks growth.
ukbusinessupdates.com Business Council is the leading growth and networking organization for entrepreneurs and leaders. Am I eligible?
