How to Evaluate Your Tech Stack Like a Restaurateur
4/20/2020 Lauren Jacenty
No matter your industry, your role, or your personal affinity for technology, the discussion of whether or not you’re using the right tools will come up.
The introduction of the microcomputer for workplaces in the 1970s began the need for companies to evaluate the usefulness of emerging technologies. This has only been exacerbated by the exponential expansion enabled by the proliferation of the Internet.
In 2019, there were over 7,400 companies pushing marketing technologies alone [source]. A quick Google search of project management software pulls up a plethora of articles and industry reviews, all with different pros and cons for the 100+ options available.
With so much available, it’s no wonder marketers share a tendency to blame the tool and a readiness to move onto “something better.”
When a complaint or capabilities concern comes up, many companies are choosing to reevaluate the software in place rather than look at other complicit factors. And that’s not to point fingers at anyone evaluating new tech. The software space is oversaturated and sales teams are vying to get in front of decision makers; usually armed with a kill sheet to talk down the technology you’re currently using.
So what’s the solution?
Try on a different perspective
When faced with an internal complaint regarding any tech stack you’re currently using, it’s better to start with an internal audit. Just like most employers require self evaluations before your supervisor reviews, this audit helps to establish whether you’re meeting base criteria and following best practices.
Think of evaluating a platform like you would, say, a restaurateur would evaluate their business. Many components go into creating an experience that patrons will enjoy and want to repeat. One bad night shouldn’t lead to closing the place down. One bad line cook shouldn’t ruin your chef’s reputation, especially if everything else is running well.
Here are four steps to help you evaluate your current tech stack like a restaurateur:
How much experience is in the kitchen?
Meaning: How long have you been using the technology in question?
If you have been using the system in question for less than a year, most likely your problem isn’t with the software. You don’t graduate culinary school with a perfect knowledge of palates and complicated dishes. It takes time and experience to build your skill set. The same is applied to your team using the technology. They need to build-up a level of comfort after you’ve set key expectations (more to come on this).
A recipe isn’t mastered the first time you make it. Most chefs will tell you it takes years to perfect a dish. The same applies to your platform.
Who is the master chef?
Meaning: Who is your SME?
If your response to the above question is “I don’t know” then you have identified the crux of your “platform” problem. During implementation, a project lead or project owner is identified. This person is not always the SME (subject matter expert), although frequently they are assumed to be.
A true technology owner is an individual who is designated as the know-it-all of the software. They have a deep understanding of the tool and can answer all basic and most capabilities-related questions. For the questions they cannot answer, they know where to find them.
This person should be treated like the Head Chef of your restaurant. They know the menu and how to execute the recipes, so they are consulted if there is a concern. Without this point person, you’re left with a bunch of line cooks making things on a whim.
Are cooks following recipes or just winging it?
Meaning: Are processes established and followed?
Imagine you’re adding a brand new dish to your menu and you have two options for your line workers: use a cookbook or fumble around the kitchen looking for ingredients and rely on their senses to figure out the flavor. There are those who prefer to figure things out for themselves, but when you’re looking for consistency, guidelines are a must.
The same goes for technology in the workplace. You cannot expect a team to understand and use a tool without process documents. You also cannot claim a tool is ineffective if your team doesn’t know what is expected of them within the platform. Instructions and training set up both your colleagues and the software for success.
Expecting adoption without process is like asking your team to prepare a soufflé without guidance; you’ll just end up with a soggy bowl of egg mixture that no one wants to eat.
One bad review shouldn’t ruin a restaurant
Meaning: It’s okay to inventory complaints, but consider the source and frequency.
At the end of the day, you may be doing everything right and still not seeing the success you expected. You’ve given it time, designated an SME, and have processes in place, yet frustrations are still arising. At this point, you should take inventory of what the pain points are and whether or not they can be addressed. This should be a physical document, much like a pros and cons list.
The goal of your audit is to be as objective as possible. Address each criticism, but also take into account the source and frequency of the complaint. You’re not going to shudder your restaurant simply because one critic gave you a bad review during your first week. Yet, if 10 critics offer poor reviews of the same dish, you probably want to take a look.
Once you’ve composed your audit, look at your cons list and see if there are solutions to the problems. If a chief complaint is that the tool is too complex to use, look at your process documents to see if they can be simplified, or if there is additional training available for the users who need it.
Either way, once you have your audit complete, you should be able to make an objective decision on your path forward. If the capabilities truly do not align with your needs, then it is time to start evaluating your other options.
Lauren Jacenty is a Training Architect for Sales Enablement at RRD.