Making business technology solutions decisions requires determining how to best support an organization’s strategies, people, and processes with the right technology tools at the right time. How should you approach these technology decisions? I had the chance to talk with Mike Sandler the Chief Information Officer at Eligo Energy, LLC. Mike has enjoyed a highly successful career, coming up through the ranks from his start as a software engineer, so they thrilled me to learn more about his perspectives on this topic.
Technology systems must correspond with an organization’s strategies, processes, and people, but how do you go about approaching technology recommendations?
MIKE: It’s a multilayered decision process, and the build versus buy decision is significant. At the highest level, build versus buy decisions tend to be driven by where a company is in its life cycle, and this typically correlates to how much money a company has available. Many early-stage companies will choose the build route because buying would be prohibitively expensive.
One of the decision-making factors is how central the tool will be to the business. The software you opt to build should be related to your organization’s major strengths, or the tool should play a key role in differentiating your company in the market.
For example, I worked for Enova many years ago, and we decided to build a predictive dialer for our call center. Enova is a lending company, not a telephony company; however, we had a large call center and were looking for ways to increase efficiencies. Building a dialer was not exactly related to our core expertise and doing so had nothing to do with how we differentiated ourselves as an online lender. We decided because of the lack of solutions on the market for purchase. In retrospect, we probably should have gone with buying rather than building.
So, if the build versus buy decision is related to the core of your business, I am biased toward building the solution. If not, then I’m biased toward buying.
The next issue is determining the costs. If you can afford it, it usually makes more sense to buy. If you can’t afford the needed solution, you must build it, but the building isn’t free. When you’re building, you must account for the direct costs of paying developers. But especially for small businesses, you must consider the opportunity costs of diverting developers from building features and products central to the company’s revenue growth and profitability to building a project that is not central to the business. Most times, even though buying a solution has a high sticker price, the building is likely more expensive.
What challenges arise when you buy a software solution?
MIKE: A lot of enterprise software programs do everything for everyone, which means they do nothing for anyone without extensive configuration. The configuration is so complex that you are forced to bring in experts. In my career, Atlassian tools are a good example. At several points when I was involved in selecting project management, planning, and scrum enabling tool, JIRA usually entered the consideration set.
My first experiences with JIRA, more than a decade ago, was not that positive because, in the early days, it was more of a ticketing system than a comprehensive task and project management suite. When testing JIRA in recent years, I have tried to sideline my former experiences to assess the solution based on its current merits.
Every time I’ve looked at JIRA, I’ve discovered that to get the JIRA installation to do what I wanted, I would need to hire an expert to configure it. If I’m lucky, I may have enough domain knowledge to manage the system in the future, but the ability to manage the solution ourselves is not guaranteed.
Without a configuration expert, the chances of getting the JIRA features I need are low. Because of this, I have chosen not to select JIRA frequently even though I’ve read and heard many personal recommendations. I know in theory that it can do what I need, but it never seems to be the right tool in practice.
The flip side is that you can go with a solution that’s less enterprise-oriented. These solutions still try to do everything for everyone, but with fewer configuration options. If the solution has the features you need, great. If the features don’t work for you, you either get creative and make the features fit your processes or, sometimes, change your processes to fit the software—which can be a good thing if your processes weren’t good, to begin with. However, it is not so good if your processes were working well.
Have you ever worked on technology systems projects that either failed or were rockier than they should have been?
MIKE; Fortunately, I have worked for companies with highly competent technical staff, so I can’t think of abject failure. However, the dialer project at Enova took much longer than estimated. Then, the needed maintenance ended up being more significant than we expected. This project wasn’t a failure, and the decision didn’t cripple the business, but we made a terrible choice in retrospect.
This question circles back to the build versus buy question. The best thing about the building is that you end up with exactly what you want, but the downside is that it typically takes too long.
How can organizations design business systems to scale?
MIKE: Designing business systems to scale depends on the same activities you undertake in other parts of your business strategy and planning. You need to consider your business systems with a solid understanding of where you are today and where you’re going. You need to have a roadmap that will help you predict your needs one year, two years, three years, and more down the road. Then, you will need to consider some if-then scenarios based on various growth possibilities.
I’ve probably over- and underestimated needs in plenty of cases. It’s common for young companies to build things as fast as possible to get them out there. You might know that the solution will break when you get to 10,000 users, but that will be a delicate problem to have.
However, it’s one thing to decide you will not build the solution to withstand 10,000 users today; it’s quite another thing to decide you will not build the system to ever withstand 10,000 users. If we build a solution that will be impossible to change, an alternative solution will need to be rewritten from scratch. This is a bad approach.
Smaller companies shouldn’t spend resources on building complex solutions for a bigger future. This route can make you miss opportunities by increasing the time to get to market, but you also don’t want to paint yourself into a corner. A balance needs to be reflected in your roadmap.
If you’re buying a solution, consider whether the product and vendor you’re choosing can support your growth. If the vendor cannot support your growth, you need to account for the cost and pain of switching vendors. So, you may end up going with a more expensive but more capable vendor or product that you don’t have to change in two years.
Can you think of an example where you’ve implemented a technology system that contributed to increased profits?
MIKE: I’ll return to the Enova call center dialer example. Our call center used about 500 people. Before the predictive dialer, the call center workers were relatively inefficient because every time they needed to call a customer, they needed to pull up the work item or ticket, then dial the number.
Just having the dialer automatically calls customers improved efficiency. Because it was a predictive dialer and we had a big enough call center, the call center workers spent even less time per call.
Then, it got even better. We could connect agents to the highest-value customers first based on models we built for the predictive dialer. After dialer implementation, we decreased call center costs by 30 percent and increased performance by 20 percent—we almost doubled the call center efficiency.
This sounds like a mixed message because earlier I mentioned that building the dialer was a mistake. Implementing a dialer was an excellent decision, but building it ourselves cost us four to five months on the front end, then a bunch of inefficiencies later. It was still a successful project, but from a strategic decision-making perspective, I think we made the wrong call for that company.
Sphere Software (https://sphereinc.com), is the sponsor and organizer of Techdebates.org and also finds great value in these follow-up discussions with industry experts. Sphere is a technology consulting and solutions company. Everything we do is designed to accelerate your business, remove technical constraints and eliminate staffing bottlenecks.
