vege - Fotolia
Startups can learn a thing or two from enterprise CIOs -- and vice versa. That point was made apparent during SearchCIO's recent interview with Ken Accardi, a CIO-turned-CEO who has lived in both the startup and the enterprise worlds.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
As the CIO of GE Medical Systems (now GE Healthcare), Accardi learned that well-defined processes are not only powerful but necessary for a healthy enterprise. At smaller companies like ViryaNet, a productivity software provider for the mobile workforce now owned by Verisae, and Tele Atlas, a digital mapping company now owned by TomTom, he learned that the Agile software development process can be applied to all manner of things -- even a change management strategy.
Accardi has since gone on to earn his MBA and is the CEO of two companies of his own -- Ankota and Triple Aim Technologies, startups he hopes will redefine the healthcare delivery system for the elderly. There, he's mashing together lessons learned from his days at GE with his experience at smaller companies. He shared some of those insights on process management and on building an Agile change management strategy with SearchCIO. This interview has been edited for brevity.
You worked at GE for 14 years -- and as CIO for GE Medical Systems for four of those years. How did you make your way into that position?
Ken Accardi: I started on the product development team in X-ray, where I was responsible globally for developing software inside the X-ray machines. We did a project that will sound old hat for today, but it was pretty revolutionary for the time, where we figured out how to remotely diagnose problems in our X-ray machines through the Internet. Based on the success of the project, I was essentially recruited in GE to come in and lead up information technology for the service division.
You left GE for ViryaNet, where you were vice president of business solutions, and then Tele Atlas, where you were vice president of process engineering. How did the experiences of big enterprise versus small company differ for you?
Accardi: One of the first things I noticed is that when you're in a big company like GE, you're very focused on processes, and when you're at a startup company, everything is relationships and word of mouth. The other side of the coin, which I really enjoyed, is that when you're in a big company like GE, you're in a job to do that role, whereas when you're in a small company, you're involved in sales, marketing and lots of other aspects of the business. I enjoyed the broadening experience.
Why was the concept of process management such a valuable thing to learn?
Accardi: If you go back to [William Edmunds] Deming, he says, in a nutshell, that if you put a good person in a bad process, the process is going to win every time. That's what his research proves. … When you're dealing with the smallest of startups, success depends on relationships between people, but if you really want companies to scale, you need to have strong processes in place so that people can fall into and understand their job, come up to speed and perform. Having come out of GE with a good understanding of how to hire and evaluate talent, how to focus on cycles like order to remittance or order to cash, and the background I had in learning Six Sigma and Lean Six Sigma and how to take steps out of processes in order to make them faster and more efficient and less error-prone -- those are really fantastic skills that I've been able to take into smaller companies to accelerate their growth and their maturity.
Is that perspective lacking at smaller companies and startups -- the importance of process?
Accardi: Definitely. There are great books like Geoffrey Moore's Crossing the Chasm that talk about various phases of startups -- what you have to focus on and what processes you have to build. So there's a lot of good history that talks to the fact that you can start a company with people who are maniacally focused and passionate about their idea or their device or whatever it is. But to actually run a company and make it scale to hundreds of millions of dollars requires that a big team of people work together, and that's all about processes.
Agile and managing change
When you were at GE, you focused on keeping internal technology up and running. But at smaller companies and definitely at your startups, you're focused on building products for the company's customer base. Does the difference in perspective change your approach?
Accardi: I've always had the opinion that whether you're designing for internal or external use, it should all be focused around the success of the business and it should be customer-centric. The biggest thing that's changed since my time at GE to now is that now everything is Agile development, and I would encourage people to use Agile development, whether they're building for customers externally or internally. That's the biggest revolution -- changing the focus on how requirements are managed, products are developed, reprioritized and evaluated on an ongoing basis.
What is the hardest part of introducing Agile to employees?
Accardi: The hardest part is, generally, more senior people in companies come from the waterfall world. So there is still a tendency to be in this mode where people want to commit the dates for projects based on lack of knowledge. History has shown time and again that these are flawed methodologies for things like software development, content development and marketing. If you're building hardware, you need waterfall because of the cycle times of tooling, but when you're talking about software, it's been proven that by focusing on bite-sized pieces, you get something done.
The biggest, most important part [of Agile] is consistently re-evaluating your requirements base. In my experience with Agile, when you start a project with 100 requirements, there's a very good chance that by the time the product is finished, you threw away 30 or 35 of those requirements and added another 35 or 40 new ones. Had you done it with waterfall, you would have built those first 100 requirements and spent six months or a year on what might turn out to be a swing and miss, and you just can't afford to do that to the business.
We often hear about the importance of change management and, yet, how difficult it can be. Based on your experiences at GE versus smaller companies, do you have any advice for CIOs on how they can build a successful change management strategy?
Accardi: Most people think of Agile as a way to build software, but I think it's a great way to view change management as well. There's that old expression: How do I eat an elephant? The answer is: One bite at a time. When there is resistance to change, it's effective to say, 'Let's try to do one or two things well, do them for a month, and then get back in the room after we've done it and see what we've learned and where we can go from there.'
I'm a big zealot on Agile. It's easy to do Agile in a small company, but there are some great case studies at bigger companies like EMC or Spotify, which has been doubling [in size] every year, and how they've made Agile grow in their worlds. I think there are a lot of proof points out there that Agile is a way to drive change management as well.
Do you evaluate how comfortable someone is with Agile before you offer them a job?
Accardi: It's great to bring people young in their careers into well-functioning Agile teams. It's a great way for them to get engaged right away, learn teamwork, and learn how to produce in that type of environment. If I were in a larger company and trying to make improvements on a leadership team, I would look for people who embrace -- it wouldn't have to be Agile specifically -- the ideas of continuous process improvement and short cycles as opposed to people who build a Gantt chart with 7,000 lines in it.
Additional insight from the startup handbook:
Tips on how to fund IT projects
Out-of-the-box ways to find good talent
Advice on how to inject entrepreneurial thinking into the IT department