Lean Startup author Eric Ries discusses what CIOs and other IT leaders can learn from entrepreneurial companies.
So it's the complete reversal of the old model, which should be called "playing Caesar," where someone pitches you an idea and you give it the thumbs up or the thumbs down based on analysis. But in entrepreneurship, that's insane, because we're going to fail many times on the way to success. The kind of decision we need to make is not "go or kill," but rather "pivot or persevere." And so that is the kind of process we are trying to teach managers to create for their innovation teams.
InformationWeek: The CIO has teams of analysts, engineers, programmers, and so on. Eighty percent of what they're doing is maintenance and operations and 20%, if that, is innovation. Innovation and agility are what these organizations really, really need. But the larger the enterprise is, the more process it has and the less agility it has. So what can large enterprises and CIOs do to encourage that agility and to turn that innovation proportion at least a little bit around?
Ries: Well, I believe that process does not have to equal lethargy. I actually believe that process is just a synonym for discipline. And we can use that discipline to go slow or to go fast, depending if we use the right processes or not. Many of the tradeoffs that managers are being forced to make now aligned with the old saying "time, quality, money--pick two." But those are not laws of nature. They are artifacts of the specific processes we used to use, and when I was taught software engineering, I was taught the waterfall methodology like everybody else, and I was taught it as the manufacturing metaphor of software development, like the software goes from department to department on a virtual assembly line.
Imagine how pissed off I was when I found out they don't even use that process in manufacturing anymore. So why do we copy it to fit IT? It's crazy. The manufacturing people can't believe that we still operate that way.
Now, to do a transformation of an organization, and this is something that the Lean movement learned a few years ago, you can't test on the whole thing at once. You have to pilot the new way of working and build up those muscles team by team. So the good news about making this transformation, especially when you want to do it with innovation, is it's actually very cheap. The greatest innovation is actually very inexpensive because you cannot successfully deploy large amounts of money toward innovation at the beginning. You don't actually have the muscles to be able to carry that kind of load, and if you put a ton of money into it, you wind up with these overfunded startups that do ridiculous things. They have not developed the discipline to spend the money well.
So when I work with big companies, what we always do is create a single, small, cross-functional team to start. And when I say cross-functional, I mean representatives from every department that the team's going to need to interact with.
One of the keys is that asking for permission is death. So we want teams that can operate autonomously and don't have to ask permission for anything. So I often see the mistake of you having only engineers but no operations people. Well, guess what. The engineers want to deploy the application, but then operations says, "What the hell is this thing? I'm not deploying it." But if you have an operations person, you know you're going to do the deployment yourself. And that's the beginning of creating what we call the sandbox.
In one company we had this old legacy infrastructure, so changing the website took months because you had to go through this whole deployment process and QA and this whole thing. It just was really antique and we said "OK, how about if we take one page from the site and remove it from the legacy system and put in on a new Ruby On Rails deployment. We will do the work as the innovation team to make the Web design exactly the same so the customers won't know this. We will make the HTML look exactly like the old system, but it will be running in the cloud. So that's it, that's one page. And then the team is like "all right, we can do that."
But now we've got one page in the cloud. So we didn't transition our whole 3-million-line program to the cloud. We transitioned one page. So then once we were in the cloud, we could start running experiments, do the analytics, and then once we had those wins, we said, "Hey, could we take a second page, and a third page?" and they slowly moved work into this experimental sandbox. And if you think about what's happening from an organizational point of view, not only were we making the company money, and doing innovative work that is valuable, we're also training these five people in the innovation team in this new way of working, with the hope that one day they'll become the leaders of five more innovation teams. So we're creating that muscle mass to do this bigger and bigger and bigger--we're building up a bigger sandbox. We're building up the skill set and mindset necessary to work in this new way, which I think, in the long run, could really transform whole organizations. But that's still in the future.
Jonathan Feldman is a contributing editor for InformationWeek and director of IT services for a rapidly growing city in North Carolina. Write to him at firstname.lastname@example.org or at @_jfeldman.
At this year's InformationWeek 500 Conference C-level execs will gather to discuss how they're rewriting the old IT rulebook and accelerating business execution. At the St. Regis Monarch Beach, Dana Point, Calif., Sept. 9-11.