There are 2 versions of every tech stack: the long list of apps you have, and the short list of the ones you actually use. See how to find more efficiency.
There are two versions of every tech stack: the long list of tools and platforms you have, and the short list of the ones you actually use. As tech stacks expand and workforces change, the number of moribund apps in a company’s ecosystem (those with low adoption or without clear owners) may start to go unnoticed, becoming budget drains and security risks. Even yearly budgeting processes may not fix the problem, with line items remaining for too many seats on largely unused apps. Case in point: I once worked for a company that gave me a seat license to a design software I didn’t know—and never learned—how to use, simply because it was part of the standard marketing toolkit.
This isn’t to say you shouldn’t bring new apps into your stack! In fact, when considering new apps, you’ll likely gain a better understanding of which apps in your current setup are underused and where you might need some investment.
Let’s take a look at how to do a holistic evaluation of your tech stack, how to understand what’s on everyone’s short and long lists, and how to fill the gaps.
How to evaluate your existing tech stack
You might think that the place to start is by looking at your budget. It’s not. By examining your budget first, large line items might shock you into pulling the plug on a widely used app. It also doesn’t account for any free apps your team might be using (or that might not still be in use, but that still have access to your data via SSO).
1. The best way to begin your evaluation is… asking your team!
There’s a reason your doctor does (or should) ask you to list your medications each time. They might have old prescriptions in their system that could negatively affect recommending a new approach, and they want to understand what, exactly, you’re taking. To cut down on data fatigue, you can have them fill out a form pre-loaded with existing tools you know they have access to, ask them to check off the items they use, and add in other items you might not have captured.
You should also break down your intake form by asking people to rate how often they use each product (options: never, 1-2 times per month, almost every week, a few times per week, every day) for the fullest understanding of their long and shortlists.
Pro tip: Make sure you emphasize that this isn’t a “gotcha” exercise. People might not be willing to say they don’t use a product they’re supposed to.
2. Get your IT team involved
If you use an SSO method like Google that allows people to log in to apps without going through a native account setup, your IT team should have visibility into exactly which apps they are, and how frequently they’re accessed. Not only does it give you a fuller understanding of usage, but it might also help you identify any potential security risks.
3. Look at in-product usage data
If a product has usage data, pull it! If you can’t find a dashboard, ask the Support team if you can get a copy. After all, data is objective, while personal reporting is subjective.
4. Look at the budget
Now it’s time to evaluate your budget. With all of your team’s self-reported, SSO, and in-product usage data in hand, you can a) match it against line items and b) decide whether that line item is money well spent. But even that’s a bit trickier than it might seem at first.
If you’re spending $30/seat/month on a product 10 out of 100 employees use, you might be inclined to eliminate the spend automatically. But here’s what you should really consider:
Why did we buy this product in the first place?
Who owns it internally?
Did we buy too many seats? (aka do the people who use it use it a lot?)
Do we simply need to retrain users on the value?
Here’s a handy decision chart:
What to consider when purchasing a new tool or platform
Now that you understand what your team is really using, you should consider where gaps might be. If, for example, you have an included wiki as part of a larger bundle, but no one uses it—even after retraining—you might want to consider adding a new knowledge-sharing platform.
When many vendors offer similar features, how can you determine whether you’re making an efficient investment and not simply adding an app for the sake of adding an app? Always ask a vendor what their daily and monthly adoption metrics look likeafter the initial rollout.
Why does this matter? With any new app, there’s going to be a period of excitement where your team buys into its usefulness. However, after that initial hype, you might start to see declining use (until it’s simply another one of those tools you have to run through your keep/cut decision chart). By finding out the average long-term daily and monthly adoption, you’ll be able to understand whether other companies have seen a real return on investment—and have metrics against which to judge your own company’s success.
Efficiency is an ongoing exercise
Finally, you know this: refining your tech stack is not a one-and-done exercise. What works for your team now may not work for them in the future due to growth, contraction, industry conditions, or changes in strategy.
That said, it’s impractical to run through this kind of process every month! So do it only after a compelling event (like those listed above), and at the beginning of your yearly budgeting cycle.
There are two versions of every tech stack: the long list of tools and platforms you have, and the short list of the ones you actually use. As tech stacks expand and workforces change, the number of moribund apps in a company’s ecosystem (those with low adoption or without clear owners) may start to go unnoticed, becoming budget drains and security risks. Even yearly budgeting processes may not fix the problem, with line items remaining for too many seats on largely unused apps. Case in point: I once worked for a company that gave me a seat license to a design software I didn’t know—and never learned—how to use, simply because it was part of the standard marketing toolkit.
This isn’t to say you shouldn’t bring new apps into your stack! In fact, when considering new apps, you’ll likely gain a better understanding of which apps in your current setup are underused and where you might need some investment.
Let’s take a look at how to do a holistic evaluation of your tech stack, how to understand what’s on everyone’s short and long lists, and how to fill the gaps.
How to evaluate your existing tech stack
You might think that the place to start is by looking at your budget. It’s not. By examining your budget first, large line items might shock you into pulling the plug on a widely used app. It also doesn’t account for any free apps your team might be using (or that might not still be in use, but that still have access to your data via SSO).
1. The best way to begin your evaluation is… asking your team!
There’s a reason your doctor does (or should) ask you to list your medications each time. They might have old prescriptions in their system that could negatively affect recommending a new approach, and they want to understand what, exactly, you’re taking. To cut down on data fatigue, you can have them fill out a form pre-loaded with existing tools you know they have access to, ask them to check off the items they use, and add in other items you might not have captured.
You should also break down your intake form by asking people to rate how often they use each product (options: never, 1-2 times per month, almost every week, a few times per week, every day) for the fullest understanding of their long and shortlists.
Pro tip: Make sure you emphasize that this isn’t a “gotcha” exercise. People might not be willing to say they don’t use a product they’re supposed to.
2. Get your IT team involved
If you use an SSO method like Google that allows people to log in to apps without going through a native account setup, your IT team should have visibility into exactly which apps they are, and how frequently they’re accessed. Not only does it give you a fuller understanding of usage, but it might also help you identify any potential security risks.
3. Look at in-product usage data
If a product has usage data, pull it! If you can’t find a dashboard, ask the Support team if you can get a copy. After all, data is objective, while personal reporting is subjective.
4. Look at the budget
Now it’s time to evaluate your budget. With all of your team’s self-reported, SSO, and in-product usage data in hand, you can a) match it against line items and b) decide whether that line item is money well spent. But even that’s a bit trickier than it might seem at first.
If you’re spending $30/seat/month on a product 10 out of 100 employees use, you might be inclined to eliminate the spend automatically. But here’s what you should really consider:
Why did we buy this product in the first place?
Who owns it internally?
Did we buy too many seats? (aka do the people who use it use it a lot?)
Do we simply need to retrain users on the value?
Here’s a handy decision chart:
What to consider when purchasing a new tool or platform
Now that you understand what your team is really using, you should consider where gaps might be. If, for example, you have an included wiki as part of a larger bundle, but no one uses it—even after retraining—you might want to consider adding a new knowledge-sharing platform.
When many vendors offer similar features, how can you determine whether you’re making an efficient investment and not simply adding an app for the sake of adding an app? Always ask a vendor what their daily and monthly adoption metrics look likeafter the initial rollout.
Why does this matter? With any new app, there’s going to be a period of excitement where your team buys into its usefulness. However, after that initial hype, you might start to see declining use (until it’s simply another one of those tools you have to run through your keep/cut decision chart). By finding out the average long-term daily and monthly adoption, you’ll be able to understand whether other companies have seen a real return on investment—and have metrics against which to judge your own company’s success.
Efficiency is an ongoing exercise
Finally, you know this: refining your tech stack is not a one-and-done exercise. What works for your team now may not work for them in the future due to growth, contraction, industry conditions, or changes in strategy.
That said, it’s impractical to run through this kind of process every month! So do it only after a compelling event (like those listed above), and at the beginning of your yearly budgeting cycle.