Post overview: We discuss what it means to be in a state of tech readiness, then provide a solid example of a spreadsheet you can use to track the usefulness & 'readiness' of your current tech stack.
read·i·ness
the state of being fully prepared for something. "your muscles tense in readiness for action" [from dictionary.com]
The concept of readiness is prevalent in business, its the 'potential energy' of the business world. Effectively, IF big opportunities come your way, ARE you prepared and ready to adapt to them? What if your vision and strategy actually start to work? How terrifying, right?
Enter 'tech readiness', the concept that your investments and vision for the internal guts of your business, your tech stack, is an essential piece of being ready for great (or terrible) things.
Here are a few things to consider when you think through on this concept as it relates to the software you choose:
Current vs. future state: Before you can truly empower readiness, you need to abolish the idea of your business as a static entity, and understand that your business is always in a constant state of change, and your systems, software, people and process will be reflecting that in many ways. You are always in implementation! Considering your 'current' state is great, but focusing on your future state, what decisions and strategic moves you are most likely to make in the next 2-3 years, will really help you invest in systems that help you grow and be ready for anything. So for example, when you buy new software, don't think of what you need now, think of what you most likely will need in 2-3 years, and work backwards. Its harder and messier but it will truly help you realize a greater potential, because if you buy for today, you implement for yesterday.View development lifecycles as a potential asset: Things are changing extremely fast, and you will never keep up on your own. Unless you are an exceptional software developer who can manage it all and run your business, you are gonna need some help. Enter in your software vendors and partners, whom you will be investing in with no guarantee of any kind of return! Seek insight into their sales pipeline and growth, their leadership and culture, and their software development lifecycle or SDLC. Often times they will refer to their roadmap of potential features, which is what they 'think' they want to do in the future, but to truly understand and assess their SDLC, it makes more sense to review their recent software upgrades and releases, including the following:
-
- Frequency of releases: How often do they do software releases (vs. just bug fixes), and what is the scope of these releases typically? Are they willing to share these past releases with you?
- Innovation of releases: Are their releases over the past 2-3 years game changers, or incremental? What are you tying yourself to if you invest in their SDLC as an asset (or liability!).
- Bugs in releases: Do their bugs get fixed (all software will have bugs!), do they have an early adopter program for live testing with customers? Are their releases mostly bug fixes?
Think of overall usage not exact fit: Regardless of the tech you are considering, newness is less critical than usefulness. And yes, unless you find that perfect software that does EVERYTHING for your business, you will likely have overlap between systems, and potentially quite a bit of it. Its actually useful to have more than one tool in the tool box, but what is critical is that for any given software solutions you use, you and your team know A) what the deep functionality of the software is currently and B) what you truly need to do that would create success. Identify the clear business case and make sure that what you are buying isn't highlighting a bunch of 'nice to have' functions but not truly addressing your root business needs.
How will you know when you are in a state of 'tech readiness'?
The amazing thing is that you can track this, like anything else! Regardless of where your current state is, create a working collection of feedback from clients and employees about core software, and keep it as a log over time. Use this to keep yourself sane, as some problems aren't manageable by tech and just require reminders to folks that its a manageable problem (which you can demonstrate if you track it), but it will also help illustrate problems as they arise and aid in solutions. Here is a simple template you can use to track this type of item:
Tracking simple information like this can really help define what the true software issues are, report on them in aggregate (if 1% of customers have login issues vs. 30% as an example!), and highlight where positive change and solutions are being made. It also fosters a sense that the culture of the organization is focused on making improvements over time to core customer and employee challenges related to software.
Here is a simple example that shows how the process can work.
