Defining Digital Transformation in 2021 with Isaac Sacolick

Kevin Montalbo

 Joining us from Sydney. Australia is Toro Cloud CEO and Founder, David Brown. Good morning, David!

David Brown

Good morning, Kevin! How are you?

Kevin Montalbo 

I'm doing great! And Our guest for this episode is a successful CIO who has led digital transformation, product development, innovation, agile management, and data science programs in multiple organizations. He has transformed underperforming businesses by delivering new digital products, investing in strategic technologies, enabling agile practices, outsourcing commodity services and establishing performance metrics. He is also the author of the book "Driving Digital: The Leader’s Guide to Business Transformation Through Technology".

He’s also an industry speaker on many business enabling topics including innovation, enterprise agility, and big data analytics. He also writes a blog, "Social, Agile, and Transformation", that covers topics on CIO technology transformation, agile execution, big data, innovation, and digital marketing. Ladies and gentlemen, joining us all the way from the USA is Mr. Isaac Sacolick.

Hi, Isaac! Welcome to the podcast.

Isaac Sacolick

 Hi, and thanks for having me! Great to be here.

David Brown 

It's our pleasure. Thanks for joining us, Isaac. We're going to dive straight into digital transformation. Obviously, your book "Driving Digital" covers this topic extensively. Many of our listeners would be familiar with this concept of digital transformation as a topic we cover reasonably extensively on this podcast, but I still feel, for many, it is a bit misunderstood.

In your book, "Driving Digital" and in your blog, you've been saying for some time that digital transformation is not simply about migrating to the cloud or deploying CICD pipelines or leveraging big data. You've said that these major initiatives are now just meeting basic expectations. I think some people will be disappointed with that because they're just meeting basic expectations. So, if digital initiatives are not these alone, then what is expected in an organization's complete digital transformation?

Isaac Sacolick

The way you've been serving customers from an experience perspective, the way you've been using data or not using data, the types of operations and workflows that you've been doing... all that is going to get reinvented over the next five years.

It's a great question. And you know, I don't want to turn people off and say that investing in technologies and automating and DevOps and going to the cloud and putting data technologies isn't part of digital transformations. It is, but I want to take everybody up a ladder a little bit and look at what's happening at the business level because of all these digital technologies, because of the state of where customers are going in terms of what they can do, their choices in front of them, what companies are able to do with data and analytics.

It's really taken every single business by storm and the way you've been operating the last five years, the way you've been serving customers from an experience perspective, the way you've been using data or not using data, the types of operations and workflows that you've been doing whether they've been semi-automated or using spreadsheets and emails in between them - all that is going to get reinvented over the next five years.

And guess what? It's probably going to get reinvented again, five years after that. It's just the nature of how fast technology is moving today. When we talk about digital transformation, we're taking things that technology companies have been doing for a long period of time and now we’re saying that mainstream companies have to do these things to be competitive.

That's why digital transformation became such an important word roughly around 2016, 2017 where it started peaking up. But when you really roll back, I got my front seat to digital transformation all the way back in 2000, watching newspapers going from a print world where 85% of their revenue was coming from classified ads on newspapers and then seeing that business model erode significantly from 2001 to this day, right? That's digital transformation.

When you look at what's happening in banking today, where much of the customer interaction used to be in the branch, and then all of a sudden COVID hit and you can't go to your branch anymore. That’s digital transformation. When you look at IoT and the impact it's having on the industrial side, you're putting measurement, not only in the manufacturing process, but also into the actual product that you're building, that's digital transformation.

So, what that's doing is it's not just changing the way we're operating and saying that application and data is so much more important. It's changing the way we're creating products and services, right? They're straddling the boundaries of both physical and digital worlds. We're enabling new ways of customers to interact with us. And that's changing the entire way we go to market - how we sell products, how we market them, how we service them, how we compete for new business.

So, when you put all that together, technology where they’re operating on the front office and they're operating on the back office, that's what transformation is all about. When you put that and you come back down into the technology layer, that means every company is trying to build up skills, process, platform around technologies. We're all trying to build applications out. We all are trying to build APIs out so that they interface with our applications. Well, we know we have to automate more of what we're doing. We're trying to become smarter with data and analytics. And that is the underpinning of the execution of digital transformation strategies. How's that David?

David Brown

 Yeah, that was good. It sounds to me that the focus then should be on the business model change - focusing on the business model, the technologies, the implementation, the tools for implementation. Digital transformation is about how your business model is going to evolve, how you're going to be selling your products and services in the future.

Isaac Sacolick

 I think that's right, but I don't want to leave out technology driven innovation out of the equation. You know, when you say it that way, David, sometimes it leads back to the separation between business and IT where business would go "Oh, this is the direction we need to take the business" and IT was asked to follow and execute around.

So much of what business can do today comes from the innovation and the experimentation that's happening inside IT - around platforms, around POCs that we do, around new ways of doing experiments and in experiences. And that's why things like DevOps and cloud become so important. It's because we want to do lots of experiments. We want to do A/B tests. We want to do tests around our data and see if our hypotheses are right.

So, it really is both a top-down strategy that we're trying to implement, but also a lot of bottom-up feedback that says how we should evolve that strategy based on what we're learning from customers.

David Brown

Yeah. Right. You’ve implemented digital transformation strategies in a number organizations. Do you have any examples of some success stories?

Isaac Sacolick

Yeah. I'm going to share a couple. One company I really enjoyed working with over the last few years is a nonprofit here in the United States called Charity Navigator. I like to describe them as the search engine for charities. And where they started, where their original roots were as an organization was a watchdog. They would actually go and look at the tax forms of charities, which here in the United States, are public information.

And they would find anomalies in terms of their spending, how they were managing their finances and how they're managing their governance that evolved to a rating system around it. When I joined them a few years ago, they had largely a manual process around their ratings. They were rating roughly 10,000 charities at the time. And their goal was to do two things: evolve their ratings so that they could look at greater dimensions beyond just efficiencies and finance and governance. They want to look at how a charity was actually impacting their constituents.

And then the second thing is they knew to expand the amount of donors using their website to find reputable charities. They have to rate a lot more than 10,000 charities. And if you look at what they're doing today, there are 160,000 charities that they're rating just a couple of years later. They have a largely automated process to be able to do this. They're rating on impact dimensions and other dimensions that they've added to their portfolio. And they're still operating as a very lean team based on the platforms and the processes that they put in place. A great story. And StarCIO was able to partner with them and actually implement this.

And then going back to my CIO days, I was a CIO at a company called McGraw-Hill Construction. Today that company has now been separated from McGraw-Hill it's called Dodge Data and Analytics. It's a construction data company and their roots were in publishing construction information so that commercial general contractors could go bid on jobs. So, it’s essentially a database of construction jobs.

Over a two-year period, we invested in their platforms because we knew we had different user personas that we were selling to [them]. Some were small contractors, some were very large contractors. We knew we had those working in general contracting, others working in billing, product manufacturing. And we took one monolithic product set, and we ended up building five products out of, really, a no-SQL database, a data-driven process, three analytics processes using data visualization technologies. And that led to McGraw-Hill being able to successfully market and sell that company which is still growing today. So, two examples there. When I look in the industry, one of my favorite examples to talk about around transformation is really Microsoft.

If you looked at where Microsoft was generating its revenue 10 years ago, it was Windows and Office and it was CDs and it was licensing. And today they're the number two competitor with Azure in terms of cloud marketplaces. We're buying Office365. And you think about the internal transitions that had to happen to make that successful and the numbers of companies in technology that have not been successful transforming their business model like Kodak, as an example. Microsoft is really a very interesting story, and I really encourage everybody to go read Satya’s book around it. It really talks about the internal struggles at Microsoft to change your business model.

David Brown

Yeah. Two interesting examples there. The charity and McGraw-Hill. So, the first example was really about enriching the data and automation. You said that [it was] a small team, so they probably wanted automation on the very few thousand or 10,000 charities to 160,000. So, you know, that had to be driven through automation and they introduced a number of other metrics to their data so it was enriching the data. The second example was about in the construction company, about analyzing the data they already had and introducing new digital products out of the data they already had.

Isaac Sacolick

That's largely correct. Yes, very well. Very well done.

David Brown 

That's two good examples of digital transformation, right? And both are related to data: either taking data, enriching it or automating it, the production of that data. The second one is obviously creating new digital products and services out of the data and old processes that our company already has. So, okay. There's a couple of really good success stories. How about some failures? We don't need to mention names - but you know, there's some projects that you can recall failing and perhaps more importantly, some of the reasons that they fail.

Isaac Sacolick 

When you read forty, fifty, or sixty percent of [digital] transformations are failing, it's largely because they don't realise the "people" aspect of that transformation.

Yeah. I gotta tell you, every transformation that I've been a part of has had speed bumps, derailments. I have huge scars on my back from trying to get organizations to think aligned and transformed. So, you know, it's not as black and white as success and failure. Even within McGraw-Hill and Charity Navigators, [there were] certainly a lot of issues that we had to contend with to make those transformations hit success points in their journey. And that's really what we're talking about, hitting success points in a journey.

I do talk a lot about this in chapter seven of this book and my next book is going to have even more examples of things that organizations really have to do when they think about transforming in order to maximize their chances of success. And I'm just going to label a few things here.

The first thing is just getting to the starting gun, right? Just recognizing that what you're doing today and how you're operating, isn't going to be sufficient for you to stay in business five years from now. You'd be surprised how many businesses are really reluctant to get to that starting gate. In fact, there's a great comic going around that saying, you know, "When did your digital transformation start?" "Well, COVID started it." Well, that to me may have started digitization of your business, but it didn't necessarily change your digital models.

And when you look at what's going to happen over the next two years, our buying habits [will] have changed. Our relationship with our customers [will] have changed and there's going to be a lot more of transformation disruption happening because of that. So, first is failure to start. Second thing is the leadership of an organization has to set the ground rules and the ownership, the governance model for a transformation to happen successfully.

So, if you have too many cooks in the kitchen, if you don't have your budget set right, if you don't have an aligned set of goals and objectives at the top level, it's really hard to transform. You know, I think of the many times I had to go back to a CEO and say to them, "Look, we need to change something that we're doing in sales", or "We need to change our way of doing accounting around a function", or "We have to change our budget mindset" because otherwise I'm never going to be successful instrumenting what we're doing that requires a cohesion at the executive level, recognizing that you have to change what you're doing, and it needs some leeway and some mindset shifting at the top level to make that happen. Sometimes we call that "changing the incentives."

I'll share one example at Business Week magazine. We used to sell a hundred thousand dollars print ads, and we went back to our sales group and said, "You have to start selling $10,000, $5,000 display ads with as much veracity and controls around them because we need digital dollars coming in as much as we do print dollars."

Very hard for a sales group to recognize that when they're just not going to get the same commission. So, we have to change our commission structures. I have a great post and a video around this – around the number one reasons digital transformations fail. And I'll share the answer here. Spoiler alert. It's really because to be successful, it is a bottoms-up process change, you know? And you could see this when organizations come up with the mega strategy and they put their CIO, or they put their CTO in charge of it, they come out with a nice deck and say "Here's everything we're going to do in the next five years. We’re going to be this great business. We're going to go compete with this one and that one." and everybody goes back to their day job, right?

Everybody's going back to what they were doing before. And so much of what needs to happen - they call it change management but I call it transformation management. It's really starting with a group of people who are going to be the instrumentors of that transformation, and that needs to grow over time to get more people in the organization involved in part of the process and having a role and understanding what their new job and responsibilities are going to be as the company is transforming. So, that's what bottoms-up transformation is all about. And when you read 40, 50, 60% of transformations are failing, it's largely because they don't realize the people aspect of that transformation.

David Brown

Interesting. This bottom-up approach is interesting because we talk a lot about, first of all, driving cultural change, which is a top-down approach. So, I'm guessing that things like a vision statement for transformation are still important.

Isaac Sacolick

Yeah, you did a good job reading my blog. I talk a lot about that. You know, I put out the vision statement somewhat quite frankly, reactionary. And I was seeing two things happen when I walked into organizations. First is there were some leaders coming in and saying, "Tell me what the ROI is going to be around something like this", or "Let's talk about the KPIs that we're going to change", or "Let's get some really structured goals around this transformation program."

And I'm like, we haven't even started like working together yet. We don't know the answers to that. We need to start being able to experiment, but we need a way of expressing what it is that we're after. So, I can't tell you the goals yet. I can't tell you the KPIs. I don't know what the ROI is going to be. I can't give you a traditional P&L business case, but I can start putting a group together and start articulating what this thing is going to look like.

And one of the things I like doing with groups is "Let's do a headline test. What does the newspaper article read? What does the headline read in three years when we're successful and how do we craft that message?" So, first is too much detail on trying to craft what the strategy looks like. The other problem I see, and quite frankly, I see this a lot in technology organizations, is when when there's a lack of vision statement, specifically articulated upfront, you get a lot of people working very hard, every sprint, every release, doing the next thing that's on their list. And they sort of get lost– lose sight of the problem statement.

And so I come in and say, "Okay, you're doing this work on master data management", or "You're doing this work on improving the experience around this application. Tell me what problem you're trying to solve? And who's the customer? And what's the value trying to solve for them?" And quite frankly, not enough people in the organization know it. The product manager might know it, the product owner - and I'm using agile terms here - they might know it, but I go talk to the developer, I go talk to a tester. There's somebody in operations who, every two weeks, is responding to an incident. I asked them and they have no clue and it's not their fault. I mean, communication is really hard.

So, the vision statement is really about taking one piece of paper that everybody can see that understands who the customer is on one side and what the strategy is on the other side. And what's the timeframe for that vision. And I have a vision statement that does that. If you are interested in seeing it, you can go to the blog post around it at starcio.com/vision-statement. And you can get to the blog posts that I talk about that one.

David Brown 

Perfect. Excellent. Now this vision statement is obviously important, but you also talk about this equally important bottom-up approach. That is the engagement in those people which are going to actually be implementing the transformation. And you also mentioned the importance of experimentation. So, the experimentation to test and pilot new projects and see if they work and to develop the digital transformation strategy and presumably learn from mistakes and get started.

But you've also talked about in your blog [about] technical debt. Technical debt that can be introduced by these pilot projects, which if they're done around shallow goals, and they're not being driven by a clear vision from the top down – that there's this danger that these projects, this experimentation and pilot projects could be just introducing more technical debt into the organization, which they're gonna have to deal with one day. Can you run us through that a bit in more detail?

Isaac Sacolick

There needs to be some time where you can actually do experimentation for experimentation’s sake.

Yeah. I mean, you're touching on two topics there that I do think intersect. I'm going to talk about innovation and POC and pilots first, and then we'll get to technical debt. I think on that side of it, there are going to be times when you are going to do some innovation, some R and D for R and D’s sake, right? You're going to go exploring a set of platforms because you have no idea whether or not that particular platform has any business value, and you should do those things. You know, if you're investing in machine learning and you don't know what ModelOps is, and you want to go do a POC with a company or with a piece of technology that allows you to do ModelOps, go do that. If you want to go test a low-code platform, go test a low-code platform, right?

So, these are things that are truly important. I think that experimentation for technology sake needs to go into the governance model of any agile team over a period of time, whether it's a release a quarter, however you want to measure a duration. There needs to be some time where you can actually do experimentation for experimentation’s sake.

The question is, when do you start rolling these things up? When do they start saying, "Okay, when does this learning exercise really end?", and I actually talk a little bit about that in the book on chapter six when you're actually doing that level of planning and you don't really know, you're sort of learning your problem statement while you're experimenting with the solution. At the same time, you need to put it together. Some questions you go through that POC, you go through a spike, you get some answers and you go back to your sprint and you say, "Do I want to go do another sprint exercise around this particular problem because I think it's worthy of investing in it? Or maybe I've hit a dead end. This is not an answer I want to get to. I want to go try something else."

So, I think when you put in, "I got to do some experimentation, I got to do some innovation. It's gonna help me answer some questions. I'm doing it very transparently in my agile process. It's not some skunkwork, it's not something that's running for three months without an end to it." That's very healthy innovation from my perspective, because everybody's aware of where you're starting from and you're trying to get to a problem’s solution at the same time.

Number one; If you look at investing in technology and you look at why you're putting a developer to solve a problem, or why you're putting an engineer to solve a problem, and I can draw a straight line from that problem into a couple of categories, one of those categories might help the business, move something forward. I'm doing something for a customer. I'm doing something for an end user. I could see the business impact from what I'm doing. And sometimes I'm doing something to solve a technology problem. Okay?

When I see an average company, non-technology company investing code to solve a technology problem, I'm going to take a step back and say, "Why are we building this? There's probably somebody who has solved this before in a platform, in a library in GIT somewhere with a methodology that I can go borrow and leverage in my environment."

And so when companies decide, "I got to go build this myself, I got to go build a custom CMS today" as an example, "Because I think what we're doing is so unique that I'm going to go do this." Those are the kinds of things that lead to technical debt. Because, now if it makes it into production, I have to support it, right? And "support it" means deal with all the things that somebody who's doing this professionally is probably going to build into their environment because they have multiple customers using it. So, that's one thing that leads to technical debt.

Let me tie it into POCs for you as well. The second thing that happens is when you build something without defining the constraints of what you built, right? So I built a POC. The customer loves it. Let's get it out into production tomorrow. Well, that might be okay. I might want it out in production, but I need to put a disclaimer, "Hey, this thing was designed for a hundred users". "This thing was designed for a database that shouldn't grow more than 10 gigabytes in the database".

And I'm going to put that directly in my vision statement before I even start coding. This is the box I'm going to live in that I'm building toward that we're all aligned to, because if we start growing outside of that box, I need to go back and reinvest in it. Okay? So, that's another reason.

The third thing I see happening is there's just organizations that think that agile and development and engineering is always about adding new capabilities, not necessarily maintaining them enough. I have a blog post out there about how to get product owners to sign up and prioritize technical debt. And I have a very simple formula for this. Thirty percent of your backlog - whether it's measured at a release level or quarterly level, you get to decide - but 30% should really be used to address technical debt.

How do I come up with 30%? I go back to the old days of software licensing. I pay 20% to my software vendor for ongoing maintenance. Most organizations are not software vendors and are not as efficient as software vendors. So, I asked for 30% and it's just that simple. And I'll get lucky if I get 15.

David Brown 

Fair enough. You've previously written about killing silos and then it being crucial to driving digital transformation within an organization. So, what does it mean by operating in silos within an organization?

Isaac Sacolick

Yeah, I'll share with you two examples that I see very often. Example number one is failure of an organization to set reasonable priorities that are aligned to a reasonable set of objectives. So, when I come into a company and there's 300 people in IT and they have 50 priorities, I'm like, "Really? Is that going to work?" Okay? Now let's say they whittled it down to 10. Sounds reasonable. I have 10 priorities, I'm going to have teams of 30 people. Well, I call that 10 silos until I understand how they are all aligned. So, I always tell organizations the same thing that we expect of our teams. They go to a backlog, they have a number one priority. They have a number two priority, number three priority. And then they cut off the list and say, "I commit. And that's, as far as I can do this sprint."

I do the same thing with executives, right? Let's figure out what the number one priority is. And let's resource it to make sure that we're a hundred percent successful before we get into the next one. And before you know it, you're going to run out of steam when you do that methodology, but you're also going to drive more success around it.

The other way I see silos is when I talk about, for example, data technologies or agile, or even DevOps - early stages, when you walk into an organization and you drop those words, people are learning what they meant. And I remember doing agile 15 years ago and explaining stand-ups and why a retrospective and why two week sprints were advantageous. Most people were learning that from the ground up and starting to instrument.

When you walk in today, people come in and some have done safe, and some have done less and some have done DAD. We talk about data technologies. Some are strong proponents, everything should be in SQL. Some were successful doing NoSQL. So, everybody comes together and they have their own digital lens in terms of how to operate. And so that creates its own set of silos. And a lot of what we do at StarCIO is really bring people together and say, "Alright, we know you've had success with A, B and C in your PaaS. We know you have an understanding of a methodology or a technology. What makes sense for this organization?" And so we spend a lot of time trying to get out of silos, thinking around how to operate and saying, "Let's get to one set of operating models for a set of use cases." And that's really about killing silos.

David Brown 

We're currently living through this revolution, this digital revolution at the moment, and people like yourself are writing about it and giving people practical roadmaps to work their way through it. I want you to put on your futurist hat now though, because presumably like the industrial revolution, most organizations at some point in time will have undergone a process of digital transformation.

They'll become agile organizations, they'll have innovated their business process and their business model. They'll be delivering value to customers through digital products and services at speed. So, how long do you think this process is going to take, this digital revolution process is going to take and where would it end up? Where's it going?

Isaac Sacolick

Well, let's leave the word "digital transformation" just for a second. And maybe talk about how much evolution our different companies are going to have because of the nature of technology, because of the nature of data and other factors as well. And so if you roll back the past, where we’ve done investing in technology after the PC revolution or after the internet revolution or after the mobile revolution, and now maybe you want to call it the cloud or the microservices, or the low-code, or some revolution of technology that we're in today.

And then maybe in 20 years, we're going to be talking about generalized AI or conversive AI. So, you know, we're still in an evolution where our business models are going to continue to change because our technology and our ability to work with larger datasets, our ability to connect the physical and digital worlds is still evolving.

And if you want to ask me where this is going, how far can I stretch my imagination? We still have huge problems around our environment. We still have a huge problem around a pandemic right now that could repeat itself in another decade with a different issue. So, we still have lots of runway of major issues that we do not have technology solutions for. We have a couple of people out there that are now pushing our boundaries to get to Mars, and you know, they're going to stretch that limit of human capability.

And then we're going to be starting to evolve our ability to run our businesses so that maybe in a hundred years we're running global technologies or planetary technologies. And you ask me, where's our imagination really going with this? Honestly, I think Star Trek. I do, I think Star Trek. I mean, we had printers, we have 3D printers. We're now beyond burger, right? Where does this go next? I don't know. You know, I think we're going to be evolving for a long time.

David Brown

I've just finished "Star Trek: Discovery", what an awesome series and the technology they showcase is awesome as well. That's a great analogy. Isaac, I was reading your reviews, "Driving Digital" on Amazon, and the recurring theme is that you cut through the BS straightaway in your book and get to practical execution strategies. I think that's very clear from today's podcast is there's some really practical advice there. Thank you so much for joining us today on the podcast.

Isaac Sacolick 

Well, thanks for having me. It was a great conversation. Great questions. I loved having you and thanks, everybody, for listening.

David Brown

And where can our listeners follow you and learn more about what you do?

Isaac Sacolick

Easy ways. Find me on Twitter. If you asked me a question on Twitter, I always answer it. It's "NYIke", N-Y-I-K-E on Twitter. You can go to my blog. I have over 500 posts on my blog covering 15 years of digital transformation, agile, DevOps - that's Blogs.starcio, S-T-A-R-C-I-O.com. And then look for my YouTube channel. I put out a YouTube video every two weeks. It's called "Five Minutes with N-Y-Ike", and it's usually answering a question like "What’s a good KPI for agile?" or "What should a tech lead do in agile?" and I’m always answering questions around that so just three of the avenues where you can find me.

David Brown 

Good stuff. Thank you, Isaac!

Isaac Sacolick 

Thank you!