Doug has seen Bruce Springsteen for the 47th time. At 73 years old, this man stood for almost 3 hours straight and played. We all hope by 73 we can stand for that period of time!
Jess’s basketball team is out of the running, she’s now paying attention to baseball season. Opening Day has taken place, and Doug got to watch the documentary on Nolan Ryan on his plane ride back from a presentation last week.
Needless to say it’s been a busy week in between recording. And none of these topics are what we’re focusing on today. In fact we’re talking about how to create your ideal tech stack.
[Blog] The Ideal Tech Stack For Mid-Market Companies Serious About Smart Growth
[RevOps Show] Strategic or Tactical - The 5 Levels of RevOps
As a reminder when we look at the tech stack, we want to hire technology, not buy it.
When we talk about hiring technology, what does that mean?
Doug is a huge fan of the jobs-to-be-done theory. You need to have a very clear job description before you hire technology because tech companies are pretty good at sales and enticing you. When you think about buying something, you better be prepared. Otherwise, it’s like going to the grocery store hungry.
Another way to think about it is through a hiring lens. If someone is a great person, but you don’t have a need for that role, you’re not going to hire them, right? We should do the same thing with technology.
Why is creating a job description for technology important?
The danger of buying technology and not hiring it is the company doesn’t do anything different. A good job description sets the basis for how you’re going to consider tech. Without it, technology that is bought but fails doesn’t get judged as hard as when requirements are considered. You can create a requirements document for this.
What’s wrong with 98% of tech requirement documents?
What they document are the requirements of the technology. They don’t have the business process to drive the need. This document should be a business process requirements document. It should be written in the form of what are user stories and scenarios for using a piece of tech.
The other area where a requirements document helps is when things change. You’re able to understand where things have changed and whether the tech you’re utilizing is still the right technology.
How do you avoid the tech debt trap?
Let’s take a step back and discuss something that gets lost in translation around this topic. We tend to think that tech and tech debt is the same thing as tech in tech. The second tech stands for technology. The first tech stands for technical. Tech debt is technical debt which means tech debt is far more than the technology. It’s the people, processes, systems, tools, technology, etc.
What is the biggest cause of tech debt?
We solve for the acute pain. We end up treating a lot of symptoms, but we don’t get to the core problem.
How do we avoid tech debt?
You have to think about the holistic system.
Can you address every piece of tech debt?
Now. There are times where you have to make a decision which will likely lead to some tech debt. We call those times a trade-off.
How frequently should your tech stack be reviewed?
This is variant. It depends on the size of your tech stack and the size of velocity. Doug would say that you probably want to review your core platform elements every three years. There are elements that you’ll want to review on an annual basis. In some cases you might review segments every quarter if you have a large tech stack.
When you take a piece of technology out of your tech stack, you’re making a change. The other thing is if your environment shifts materially, then it resets everyone’s review cycle.
What do you do when you’re reviewing your tech stack? How do you review?
The first question you should be asking is what did you hire this tech for in the first place?
Is it still relevant?
What you have to watch out for is tech sprawl. This looks like 300 people using 14 different tools to do the same thing in different places. You don’t know why your tech isn’t working. This is all by design and isn’t an accident.
Some questions to answer:
The most powerful question you can ask: Where can we find one tool to replace three applications?
Your right tech stack is going to be a core stack. Your core platform applications, your primary apps, these all should be strong and robust. Then you get into your secondary and complimentary levels that are going to be very point-based solutions. That’s where you need something exceptional.
Jess is a firm believe that if everything is a priority, nothing is. Once you’ve done your review, how do you triage what to do?
Some questions to consider here:
This is why the strategic RevOps roadmap is so important and why we talk about the three zones of execution. There’s always a prioritization schema and what strategy is all about.
Jess’s Takeaways:
Follow Jess, Doug & Imagine on socials for updates on the show or other insights:
Doug Davidoff: Twitter - @dougdavidoff | LinkedIn
Jess Cardenas: Twitter - @JessDCardenas | LinkedIn
Imagine Business Development: Twitter - @DemandCreator | LinkedIn
Subscribe to the show on Spotify & Apple Podcasts
Check out Let's Play RevOps on Twitch for more commentary on this topic
Listen to Episode 54: How Important are People in a RevOps World?