Adopting the Transformation Modality
Transcript
>> Hello and welcome, it is an absolute pleasure to be presenting at The CTO Advisor Virtual Conference sponsored by our friends at Cohesity. I am going to be talking about adopting a transformation modality. So this is really a topic of how do we turn our organizations, our businesses, our teams into teams and organizations that can rapidly adopt new technology if and when it fits our business and continue to do this as things evolve. My name is Joe Onisick and my background is 25 years experience working with some excellent and amazing transformational technologies.
25 years ago, I was a Novell networks administrator and Lotus Domino administrator and one of the more interesting things I was able to do in a digital transformation world, in true digital transformation world was convert analog medical transcription systems where doctors would call on phone lines and dictate onto spinning tape recording their voice into digital systems where those phone lines plugged into digital cards on the back of servers and translated that analog voice into digital voice for storage and playback for the purpose of medical transcriptions.
It was a huge change in the healthcare field and it was amazing to me to see in that early stage of my career just how transformational technology could be to the businesses and systems we had in place. From there I took a little break. I burned out in 2000. I decided to slow the pace down so I joined the United States Marines, traveled the world repairing and fixing laser guidance, laser systems, laser guidance and missile guidance systems. And then came back out into technology.
Since coming back out into the world of cloud and data center and all the things we do today, I've become known for goats. I can't tell you why, but LinkedIn says it so it must be true. When I spoke with Keith, The CTO Advisor about this session, he jokingly told me he was looking forward to finding out what modality meant. So I wanted to make sure that I took care of Keith and told him what modality means. I also needed to figure it out myself.
Modality is the fact, state or quality of being modal. So it's a tendency to conform to a general pattern. So if we look at that and we look at what I mean by a transformational modality, a transformational modality is the fact, state, or quality of being technologically positioned and organizationally ready to adopt new technology at the pace of the business. And so this is a really interesting thing to me, 'cause there's a lot being said in that wordy definition I just gave you.
I need to be technologically ready to adopt new technology and new processes. I need to be organizationally ready to adopt it. My people need to be ready and I need to be able to do this at the pace of the business. So again it becomes very individualized to how each of our businesses operate. One business's pace will be different from the next and one industry's pace requirement will be different from the next. As we look at this, what it really enables for me, embracing a transformation modality enables me to take a mindset of being able to fail fast.
And many of us may have heard the fail fast term. In the IT world, the little bubble of Silicon Valley this gets thrown around a lot. It's my favorite excuse from startup founders and venture capitalists for why they completely miss the mark of all that money they funded to go do x or y. When they completely fail at that, they're going to fail fast, keep whatever remaining money is available and pivot. But when I look at fail fast, it's really about getting rid of that fear of failure and looking a step further at what I should be afraid of rather than being afraid of failure, I need to be afraid of stagnation.
I need to be afraid of staying the same. I need to be afraid of sticking my head in the sand. So fail fast is about being able to adopt new things quickly, try them out, discard the things that don't work, and keep the things that do. That's fail fast to me and for me, it's something I apply to everything I do. Sure, there's a lot of failures, but they're small, they're recoverable, and they allow me to iterate much more quickly. The under current driving the need for a transformation modality is the technology adoption curve.
A curve that describes the five phases of technology adoption. From the innovators willing to grab the latest and greatest and try it out instantaneously back to the laggards. And we all sit somewhere on this technology adoption curve both as individuals and as organizations. But what we don't typically realize is that we might sit in different buckets of this curve with different technologies all simultaneously. I might be willing to adopt x, y, and z as an innovator here, but a, b, and c, I'm going to be a laggard over there.
So this drive of technology adoption as technology changes more and more rapidly is what pushes the need to be able to do this quickly and efficiently with every new technology that becomes applicable to our business. The easiest way to see how this adoption curve works is by looking over a time historically at the buzzwords that have floated through our hype cycle of market texture within the technology industry. I've got a few buzzwords listed here, but my best example here is BYOD. Bring Your Own Device.
Seven to 10 years ago, we went out and sold solutions for BYOD. We built architectures to support BYOD so that organizations could look at having their teams utilize the phone they wanted to access enterprise systems, the laptop they wanted to access enterprise systems, to do it from wherever they wanted to connect. And those BYOD solutions at the peak of their hype cycle took off so much that the term disappeared. We don't talk about BYOD anymore. The reason we don't talk about it is because it's simply the new normal.
We all expect to be able to use an Android or an iPhone device to connect to our email. We all expect to be able to use our choice of Mac or Windows laptop in most realms. So BYOD disappeared because it simply became reality. And that's one of two ways buzzwords disappeared. Buzzwords either disappear because they take off like BYOD and become the new normal or they disappear when they fail. There are a few exceptions. Buzzwords like VDI that pop up with every year being the year of VDI, but those are few and far between.
So this is what drives the need for new adoption modalities. This is what drives the need for a transformation modality. As we look at this, what we'll see and hear very often is that it's as much about the people and process as it is about the technology. And that's absolutely true, but the important thing to know is not just understand, it's just as much about people as it is technology. It's how to utilize the people and the process, tie them together to the technology to drive success.
Simply understanding the people are as important as the technology deployment is great. You're already one step ahead. But what do you do with those people and those processes and what do those processes look like over time? Again, we have to look at these processes from the fact that we're going to continuously need to drive new technologies and adopt new technologies into our businesses. Transformation is not going to be measured successfully as a one-time thing. It's going to be measured in how you can adopt it over time.
In order to do this, we need to move away from Legacy adoption thinking. We need to move away from the idea of linear processes like the ones shown here where there's a start line and a finish line where we forget about it and move on. No longer can we go through a discussion of formalization, a series of validation through maybe proof of concepts, then deploy it, monitor it, and forget about it. Because everything's shifting too quickly. Because there won't be a finish line for a single transformation and this needs to become a process that's constantly flowing within your organization.
Things need to be changed, adapted as we move forward. These linear processes with defined start and finish are longer the way we look at it. You can't simply take a CIE and CIO initiative to DevOps all the things and go get done with it. There's a process that will maintain a very iterative state as you get through these big picture transformations whether they be hardware focused, software focused, cloud focused, or organizationally focused. So at Continuum, what we we look at is what we call the Continuum Modality.
Within this process, we center everything we do, six steps of adopting a new technology around a center axle of adaptation. We need to be able to shift as things change and we need to be able to understand that depending on where we are or how things are working in the environment, we might come into this six step process on step three and exit on step five because of the speed of the situation we're in, but we should always be looking at following this modality or this methodology and the six big picture steps which we'll cover in a little more detail as we continue forward.
The reason adaptation is critical is summed up here very well by Donald Rumsfeld. Donald Rumsfeld talked about the things we know. We know the knowns. I have known knowns. I have some unknowns. I have known unknowns meaning I know that I don't know about this, that, or the other thing. I don't know anything about plumbing. It's a known unknown. But the things that force us to adapt and the things that force us to be ready to adapt and change fluidly are the unknown unknowns.
The things that I have no idea about, but when they come up will blindside me because they were fully unknown up front. So being able to adapt is what prevents us from being halted in this process as those unknown unknowns show themselves. So looking at that, taking that adaptation wheel in the center and looking at step one at the top. Step one is identify. We need to be looking at new technologies, understanding what's coming down the pike. As we look at this, we need to see what types of technologies might be applicable to us.
We need to know what our appetite for new technologies are. There are customers around the world that are very willing to adopt the latest and greatest as soon as it's there. There are customers around the world that will not touch technology until everyone else they know has it. Neither one of those is right or wrong, you just have to understand where you as a technologist and your organization sit, where you know where you sit within this lifecycle of adoption. That way you can monitor the technologies that are getting close to where you'd be willing to absorb them into your business.
You need to know what technologies would apply and where the gaps are in your business or the places that could use a transformation or an advantage, and then ultimately at the bottom of this and what you'll hear me repeat with every one of these steps is you need to know who owns it. Who owns technology identification for your team? If nobody is assigned the responsibility then it's simply something that isn't getting done. A lack of ownership is a lack of execution. So is there one person in your organization that's in charge of identification or are there several people in your organization in charge of identification for their aspect of the business or their aspect of the technology step?
Is it a combination of the two where a CIO or a CTO brings in a series of things that should be looked at and decimates them down amongst different vertical stacks within the IT stack. All of those are appropriate methodologies as long as at the end of the day, we all know where we sit and who's responsible. Identification flows very naturally into validation. The beauty of doing the identification process correctly is that you're going to funnel things down into validation and what I mean by that is some things are going to trickle out.
As I'm in the identification process, there will be things, technologies, and shifts that are so avant garde, so cutting edge, or so new that my organization has no interest in 'em. So they don't get to the validation stage. There are going to be things that are totally inapplicable to my industry or my organization and so they don't get to the validation stage. And there are going to be technologies that I find so ridiculous or so off the wall that we don't even bring them into a vetting stage at validation.
But for the things that get to validation, we need a defined process for how we do this. How do we test these solutions? How do we vet them out to ensure that they could work for my organization? How do I verify that the technology, products, solutions, software or hardware has the integrations I need it to, to work with the rest of my IT systems and to fit into my longer term goal for how I deliver technology. And then what tools do I use to do this?
Am I good with just a great demo? Do I need to go into a proof of concept or a proof of value, POC, or POV? If so, have I actually analyzed the functional costs of my team engaging in proof of values or proof of concepts? Even if my vendor team or the sales team working with me does the proof of concept or proof of value free of charge, there's a cost to having my team engage with them to go through that process.
There's a cost in time, and money, and salary. There are things that aren't getting done. So do I want to do that every time? Do I want to do that at all? Or can I circumvent the need for proof of value, proof of concept by working with a close set of trusted advisors and trusted vendors that do the validation for me on the back end? Again, no right or wrong answer. This is going to be very much an organization by organization decision but it needs to be a decision.
It can't just be a set of assumptions. And then finally, who owns this? Who owns the process for validation? Who owns ensuring that technology is properly validated? And then we look at step three. And step three, is often ignored and you will ignore this at your own peril. Education is critical to technology adoption and growth. We ignore it because it's a cost. We ignore it because it doesn't directly affect the bottom line or immediately show results in the mission we're driving within our organizations, but education on the product is critical and it's one of the more important focuses that I take with my customers.
Before I can properly architect a solution, in conjunction with my customer's architects, they need to have a baseline knowledge that matches my knowledge of the product or solution. In some cases, they come to table with it and I don't have to do anything on that piece. But in some cases, I have to bring them up to the level of understanding on this particular solution that I have so that we can properly communicate in architect. As they deploy it, as they move forward with it, education continues to play a role.
We have to ensure that our teams are properly able to utilize the technology, to grasp what it can do and understand how to operate it and troubleshoot it. So education comes in very critically to any successful adoption and every adoption is going to have to adapt to the level of education required for your team on that technology in that instance. What this boils down to for you is again, ensuring that somebody owns this process. Who's in charge of ensuring that every team member has the level of education they need to drive the technology transformation you're driving?
One recommendation I have here is not to rely on the administrative and engineering technical staff to tell the business when they need education. Depending on your company's culture, depending on those individual's feelings and their individual personalities, they might not be comfortable expressing a knowledge gap because they may feel as though that makes them look like they're not good enough for their job. So it needs to be made available. It needs to be made okay and it needs to be part of the work time and the work funding.
You shouldn't expect your teams to spend their own personal time educating themselves. You should be able to provide the right time so that they can do it, because it's going to benefit your business on the back end. That moves us into step four and step four is where I get the most questions. Joe, why do you incorporate purchase and planning together? Aren't they very different steps? Yes and no, they have a very natural tie together especially as we're looking at rapid successful technology adoption.
I group purchase and plan together in step four because they tie very well in hand to hand. There is a level of planning for any given solution technology or transformational rollout that must occur before a purchase. I'm going to need to know how many widgets to buy, or many licenses to procure, or which type of license. And so that involves a level of planning. But after the purchase there tends to be a series of time gaps. Things like procurement processes, shipping from the vendors and lead times from the vendors, how long my team will take to actually be ready to install it, or when my change window might be available to get the installation done which means that after the purchase decision is made, I have down time that if I properly utilize for planning becomes active time.
So purchase and plan to me tie very hand in hand because I can use them together to maximize the efficiency and agility with which I can deploy a transformational adoption. I want to do exactly as much planning is required to make the purchase correctly and then do the rest of my planning while I'm waiting for the deployment phase. That can be architectural design, high-level design, low-level design, you name it. A lot of these things can be done efficiently post-purchase while you're waiting for that right time to begin stage five.
When you're looking at the purchase and plan phase, some questions to keep top of mind. What are my timelines? That helps dictate where that stake in the sand sits between purchase and plan. What is the architecture and design? Again, much of this might happen prior or post-purchase. Which teams will be involved? Most technology transformations are going to involve multiple teams. I need to know who they are and then with that, I'm going to need to arm myself with who's responsible.
From a purchasing perspective, and a planning perspective, which individual owns it? Step five is where the rubber hits the road. With step five we're now in the deploy and test. Deploy and test again are typically ideas that might have been two stages in older methodologies or Legacy systems. But they cannot be in today's environment. We have to be able to test and iterate as we're deploying wherever possible. It speeds up the deployment, but it also ensures the better results, less risk at the back end.
It doesn't matter if this is a software deployment or a hardware deployment. It doesn't matter if there's organizational process changes or no organizational process changes. Being able to test and iterate within the deployment cycle provides that agility you need and aligns very much to the principles of Agile and DevOps that are very prevalent in our industry today. As we deploy and test, it's important to know what is success, what does success look like to us, what are my known knowns, what are my known unknowns, define those, because once I know this is my known knowns and this is my known unknowns, I now know where that gap of unknown unknowns could exist that I will have to adapt in real-time to as they come up.
And then finally, deploy and test. Owners must be assigned. Make sure that components, individual pieces are always assigned to an individual owner. There may be multiple owners, but there's clear swim lanes for what they own. And then last, this step, step six, socialize is most often ignored. In fact, socialization in any way, shape, or form doesn't truly exist in most any Legacy adoption methodology and socialization is so critical to true success and true product adoption. When we look at socialization, socialization is taking that deployed and tested solution that deployed and tested architecture, that digital transformation that you've just worked so hard to create and ensuring the teams that will benefit from it are aware that it exists.
Ensuring that they're aware of who owns it, who supports it, how to use it, where the documentation is and who to call when something goes wrong. This is what drives their usage which drives your adoption which drives success. Many of us that have been in technology long enough have seen products installed, deployed and then die on the vine. Things like collaboration tools, and wikis, anything in that realm. The reason they die on the vine is not that the technology was bad, it's that they never hit critical adoption mass internally.
So it didn't matter if the technology was good. If you're unable to get teams to use it and incorporate it into their day job, the technology never lives up to the value that it was defined as. So when we look at the socialization phase, when we look at this piece, there's a few aspects that you want to understand, a few aspects that you want to drive into your culture. The first easiest and cheapest is identifying champions. Within most organizations, there's a few people that are excited about the new technology, that want to talk about it, that want to help drive it.
When we look at those people, support them, arm them, engage them, and authorize them to go out and help with that. We all are social animals and as social animals seeing someone else excited about it will help drive our own excitement. So if you're launching a new collaboration platform or you're deploying that new tool for communication amongst your teams, get those few people that are very excited about it out there. Give them the tools, give them the platform to help bring their peers along.
Champions are critical to success. They act as the lighthouse that guides in the other ships. The next thing you want to look at is things like miniature lunch and learns where you'll take the HR group and show them exactly what it's going to do for them and then take the finance group or the sales group or whatever groups your company operates with and socialize into them, showing them how to use it, what it means to their job specifically, and then where to find documentation and support.
Socializing any deployment of technology or technology solutions will help drive the success and adoption that is critical in today's world. So looking at this and looking at what we do with these adoption and transformation modalities, we need to remember that this is not a start line and a finish line, that these modalities will be constant and ongoing within our environment and that for most of us, we will have more than one transformation going on at any given time. Depending on how our organizations operate, these may all be centralized through the IT team, but they also might be distributed with some existing in IT and some out at the lines of business.
Neither is right or wrong depending on your organization as long as we understand that transformations are constant and can be run simultaneously. Digital transformation is not a start and finish project, it's a continual journey as the technology underneath us evolves. So taking a look at that constant evolution and what we drive from it by adopting a transformation modality, we're creating an iterative process that while it continually spins within our organization, it drives a separate wheel of innovation and that innovation wheel is driving revenue.
It's helping to complete the mission. It's driving customer satisfaction and employee satisfaction. It's increasing sales and the buzz around our business. It's increasing our marketing and our ability to get out to market within our customer base. That innovation wheel is driving what our business needs and it's being spun by the back end of these transformational modalities. This is what we need to drive into our business and technology cultures to be able to rapidly adapt and rapidly shift as the world around us changes.
As we take this and we look at the timelines and the roadmap for true transformation and adoption of transformation modalities. It may seem daunting at first. How do I change my entire organization, my processes, my people and my models to marry something that can spin so fluidly and so consistently? The answer is we don't do it all at once. This is not the flip of a light switch that pops on and now you're a transformation modality. If you're a brand new business starting up next week, you can start with this modality, but for the rest of us, this is a path, this is a journey.
The way we suggest taking this journey is to look at a six to 12 month project. One of the larger transformation projects that is already on your radar, that is already on your horizon, but something that can be completed and finalized in a maximum of six to 12 months. You use that technology transformation as the anchor point for driving this new and innovative change. Within the process of deploying that transformation, you build in these processes for repetition. You learn what worked within your organization and adapt the things that didn't, dropping the things that made no sense for you.
And at the end of that six to 12 month transformation, you've got the baseline of your organization's individualized transformation modality. From there, you continue to tweak it with other processes and adapt it to your organization's style, to your processes, to your people. Because at the end of the day, this doesn't have to work for me, this has to work for you and your organization. Looking at this and looking at why this is so critical to me, this quote sums up everything about why we have to be able to address this and address it quickly.
This is a quote that I apply to everything in my personal and professional life. " Technology moves too fast, business moves too fast for us to stay static. If we're not willing to innovate, if we're not willing to speed up our processes, somebody else will move past us and displace us. And that is not what we're trying to do. So embrace change, teach your organizations how to embrace change and watch your businesses, your organizations, your teams and your career thrive. I very much appreciate you joining me for this session.
A big shout out and a big thanks to Keith, to Mrs. CTO, and all of the people that went together, came together to make this conference happen. Thank you from everyone on my team and the extended team here at Continuum. We're here to help you. Please reach out. com or find me on Twitter @joeonisick. Thank you very much and have an excellent day. (swooshing) (modern sounds)
