In the volatile energy market, in-house development helps this CIO control his firm's destiny.
When Ambit Energy launched in 2006, CIO and co-founder John Burke was faced with the task of supporting the IT needs of a start-up that had aggressive growth plans in an extremely competitive deregulated energy market. But instead of turning to software vendors and outside consultants to help build out Ambit’s IT infrastructure, Burke decided to do everything in-house. It’s an approach that he says has helped Ambit’s 55-person IT organization more efficiently enable and support the company’s frenetic growth. At a time when many companies are outsourcing IT operations to cut costs, Burke insists that keeping Ambit’s IT entirely in-house has yielded far better ROI.
John Burke
Title: CIO
Organization: Ambit Energy
Most interesting thing people don’t know about you: I was a musician until the age of 25.
Life’s ambition: Awesome systems!
Philosophy in a nutshell: No one gives it to you — you have to work for it.
Ask me to do anything but: Physical labor. I’d rather think.
Best book you’ve read recently: Good to Great, by Jim Collins
What does Ambit do as a player in the deregulated energy market? Ambit is an energy provider largely to residential customers. We really own and manage the customer. We sell the customer, and they enroll through our systems. We then receive meter reads through the regulated transmission distribution providers every month through EDI and other electronic means. We then rate it, generate a bill, print it, mail it out, and then we expect the customer to pay. If the customer doesn’t pay on time, there are oversight committees in the states we operate in that govern [when] you can go in and turn the electricity off. So, in a worst-case scenario, we accidentally turn off someone’s power or we bill them incorrectly, and it can become a very spicy issue. So we’ve had to focus a lot of energy upfront on making sure that our systems are really rock-solid so that those sorts of issues don’t happen.
What drove your decision to do all of your software development in-house? We started the company in 2006, and I was intending on just going out and licensing a system. I had no interest in building one. [But] there weren’t really a lot of players in the deregulated energy space. I finally settled on one. My first request was for a simple rating methodology, and the vendor told me it would take two weeks to define it and two months to build. And I just about had a heart attack. So I grabbed two contractors, and we started writing software. We wrote the rating engine first, then designed the data models. Because of the lessons I learned from my previous experience in telecom, I put a hard regimen in place from the beginning about how we develop and design. We measure twice and cut once.
Now that it’s all built out, wouldn’t it be easier to have someone else manage it? Our systems are better than anything we can buy, period. If you go look in the industry at what we are doing relative to what other people are doing, no one has got what we have. As a matter of fact, we’ve had companies come to us asking us to license our [back-office system]. So we consider it a competitive advantage. I don’t know anyone out there that even comes close to what we can do for rate of return.
You moved from a waterfall software development methodology to one based on agile processes. Why? With the waterfall methodology, what we would do is write these really robust specs initially and then work with the business to refine them. Then we would go and write software for a couple of months. And when you got to the end, the business owners would look at what’s coming out of the door and say, “Wait a minute. Since the last time we talked, we really rethought some of this, and now we want you to do this instead of that.” It creates this animosity where IT blames business because they didn’t know all the specs upfront, and the business blames IT because the meeting wasn’t organized well, etc. If you are lucky, you have a visionary genius who defines everything upfront, and then you are safe.
So, how does it work with agile? With agile, we are using scrum, where you do these sprints, which are these one-to-two-week runs. At the beginning, the business prioritizes what they want to see. Then you do a sprint, and everyone looks at it after two weeks. During that time, the business may reprioritize what they want. They may come up with new definitions. But all the work that was completed during that time is value-add toward the end [product]. There is a psychological impact when the business is empowered and more involved in the development process and they are giving real feedback. And then there’s the same psychological process with the IT guys. They feel they have a closer connection with the business. They are able to show them things quicker and give the business more immediate feedback.
What would your advice be to companies that want to implement agile but don’t have the advantage you did of being at a start-up? I was lucky. I have the ability to actually implement great ideas, and that is a real blessing. I’ve had previous roles where I’ve gone in as a virtual CIO at organizations and tried to change them, and it is incredibly hard to do.
I don’t think you should look at it at a textbook level, however. You should take a moment to try to change your thinking. It was a change for me. I like doing what works, and I had a lot of success with waterfall. So I had to really open my mind and listen. You have to live in the unknown for a while and get your head around what these guys are talking about. And, of course, as with any situation, don’t listen to the marketing. Don’t swallow the buzzwords. Try to look at what the underlying principles are. You may not be able to adopt all aspects of it because of the organization, but you are going to have some control over some aspects.
