Too many companies arrive at their company tech stack design unintentionally. They paste their software together with manual spreadsheets and clunky middleware. How does this happen? It starts with a lack of intentionally in the stack design.
Whether you are considering opening a LLC or 45 years into a family business, it’s never too late to intentionally design your tech stack to produce better results for your business. But you might be asking “what exactly is tech stack design? Tech stack design is the intentional creation and integration of the various software that run a business.
In this article, you will learn how to conduct an effective current state evaluation for both new and established companies, how to match software to your processes and use appropriate selection criteria to ensure favorable outcomes.
Current State Evaluation for New Companies
The most important consideration for new companies is to drive revenue so that the company can exist long into the future. Process optimization is a joke. Don’t even think about optimizing a process until that process is built and tested many times over. Once a startup company hired me to analyze their tech stack. They spend so much time and money on the evaluation that I eventually fired myself.
Go make money.
Pick software quickly and according to set criteria whenever possible. Build a trusted network of software suppliers who dispense advice for free or nearly free. Anyone who takes a bet on your company when your resources are scant will be a good partner when money starts flowing into the coffer.
At the birth of the United States, George Washington famously warned against entangling alliances. That holds true for new companies. Experiment with different software to figure out what makes sense for your business. But don’t hem yourself into multi-year agreements. Stay fluid. Stay nimble.
Current State Evaluation for Established Companies
Companies that are fortunate enough to have some processes in place and strong revenue should think more about tech stack design. This usually includes a high-level assessment and detailed mapping of processes.
High-Level Assessment
What subscriptions are you currently paying for? Do you really need them? How many manual spreadsheets supplement your ERP? There’s likely a line item or two on the profit and loss ledger that reveals the software cost. But don’t stop there. Evaluation of manual processes also requires your attention. If you pay $500 a month for a payroll system and there’s an additional ten hours of supplemental spreadsheeting, your all-in cost is likely in the four-digit range.
Further, inflate that cost when considering the sagging morale that accompanies rote, non-value-added work. Employee well-being is not always easy to put a number on, so go with your gut feel here. Is the employee complaining about the rote entry truly inconvenienced or dare we say – lazy?
Mapping of Processes
In another life, I was Six Sigma Certified. The methodology provided a good framework to evaluate a current process and present the optimization possibilities. However, it always felt silly when we performed a detailed analysis on a terrible process.
Sometimes, a broken process doesn’t require a painstaking review. It is simply broken. For those processes, simply code them as red and move on.
Processes that don’t immediately spell doom and destruction require a deeper analysis. Map those processes and determine if they might benefit from either being reoriented or augmented by better software.
What are the criteria for knowing if a process will benefit from better software? A simple coding schema works well.
Red – Process Is Badly Broken
Yellow – Process Could Likely Be Optimized
Green – Process Works Well
Yellow and red processes require a deeper workflow examination. In some cases, this may warrant a manual workaround. It may involve building or implementing a new software entirely. And in some cases, the process requires complete reorientation. Each of these options requires careful examination.
Optimize the Tech Stack Design
With a strong understanding of the tech stack’s current state, its time to take a clear-eyed approach to three potential solutions. These solutions include the manual workaround, software to support the process, and software to supplant the process.
The Manual Workaround
Manual workarounds exist because the chief software cannot handle the associated nuances. As an example, one company had an ERP that could not provide disposition status once an item entered the quality warehouse. Instead of integrating a new ERP, users input the required information into a manual spreadsheet. This approach, while admittedly sub-optimal, made the most sense for the company.
Manual workarounds should be the last result as it introduces additional work outside of the main data captures and fields. Too often, manual processes are introduced in one department without a proper appreciation for their effects on other departments. In many cases, introducing new software to support the process offers the best option.
Supporting Process with Software
A process should only be supported with software if the process itself is not broken. It is a poor decision to support a completely broken process (CODE RED!) with software. But if the human element of the process provides good value, support it with good software.
Recall the example of the quality worksheet workaround. Perhaps an off-the-shelf software exists that performs a similar function and keeps data inside the system. A return on investment calculation provides a good decision-making basis.
Using Software to Supplant the Process
Choosing software over an established process makes sense for organizations whenever the software provides a solution with little or no inertia. The no-inertia scenario requires no change in user behavior and thus, no implementation resistance. In practice, most software requires a bit of inertia and change in user behavior.
Good employees typically put up some resistance to a newly introduced software. They rightfully want to understand its purpose and value. As such, proper adoption requires executive sponsors to spend a bit of time validating the return of the investment to ensure an honest conversation.
Take the case of an engineer who must assign time to a job. The result of time assignment allows for job costing and utilization reports. Yet, time entry frustrates many engineers. Ensuring adoption necessitates a demonstration of its value to those saddled with the task.
The Selection Criteria
Determining when to use a manual process, support the process, or supplant a process is rarely easy. Rightsizing the tech stack design process helps. For instance, an ERP that serves as the company’s brain requires a great deal of foresight. If there’s little need for cross-discipline use or API integration – then allow individual managers or employees to make the selection.
An Early Lesson in Tech Stack Design
As one of my earliest consulting gigs, I participated in an exhaustive two-week ERP selection process. Committees were formed for each individual discipline – from Finance to Project Management and Sales.
Each committee mapped their five most important processes. Over a period of several months they created their five most important business flows and then simulated the results with the proposed ERP system. The final selection criteria involved a presentation by each team on their various scenarios and results from each simulation.
It was easily the best ERP selection process I’ve been involved in. And no doubt, one of the most initially expensive endeavors. Yet, the upfront work and trust associated with making employees part of the selection committee has and will pay off for years to come.
Remembering the Big Picture
Organizations never succeed because of their tech stack design. They do so because of their products and their people. But effective tech stack design empowers employees, increases efficiency, and explores morale. All of these elements equal a healthly and profitable organization.
Should you ever need help in this process, please reach out. Wishing you and your team happy tech stack design!