Is every company really a software company?

You've heard it many times: These days, every company is a software company. But is that really true? And if it is, what does that mean to companies that aren't traditionally in the software business? In an interview with The Enterprisers Project, John Burke, CIO of fast-growing direct selling energy company Ambit Energy, shares his views. 

The Enterprisers Project (TEP): A lot of people say "every company is a software company." What does that actually mean?

John Burke: Over the past 10 years, companies are starting to realize they need to act like software companies given the competitive advantage of their IT systems within their business markets. The easiest example is comparing Amazon (which clearly acts like a software company) with any of the traditional brick-and-mortar retailers who are scrambling to strengthen their IT presence – Walmart, Target, etc.

Not all organizations need near cutting-edge IT to differentiate themselves, but for those that do, "acting like a software company" is critical. The days of outsourcing such essential functions to an IT consulting service firm are in the past. In order to cut down the communication hurdles and confusion, business units need to work directly, and in real-time, with IT development units.

TEP: Is Ambit Energy a "software company?"

Burke: At Ambit, we have always considered ourselves a data processing company (which sells retail electricity and natural gas). This means we place a premium, culturally, on accurate data and data management. However, over the past five years, Ambit has started acting more like a software company after we created dedicated software teams for each critical business unit.

Suddenly, each business unit was managing a team of developers under an agile development methodology. At Ambit, this was a very empowering moment. Business leaders were able to get what they wanted quickly, and they moved closer to the decision-making around technology delivery and functionality. Rather than asking for some software functionality from the IT team then waiting, business leaders began requesting functionality and then helped the IT team grapple with the issues and tradeoffs that go with many aspects of software development. This is what makes Ambit a software development company at its heart.

TEP: In your recent CIO article, you mention needing IT employees to make the change in mindset from gatekeeping to facilitating. Can you tell us a bit more about this? 

Burke: Software delivery often happens in stages – definition, collaboration, design, development, unit testing, integration testing, end user acceptance testing, etc. People responsible for each stage in software development can behave in one of two ways when they see an issue with the software: One, stop progress and demand a fix; or two, stop progress and help determine a way to address it.

At Ambit, we successfully transitioned from behavior number one to behavior number two through mentoring and management. People don't change overnight. Positive behavior must be encouraged and trust must be built. People need to know that it's okay to speak out and reach out. Our software delivery system tracks essential decisions by individuals at each stage of development – therefore, there is no hiding. We can tell if someone stopped the project and then waited or stopped the project and facilitated getting the problem resolved.

TEP: What advice would you offer other CIOs about making a change like this one? 

Burke: You need a champion for change within the ranks who has a solid, trusting reputation amongst the team. Get buy-in from the team in some sense at the outset. You will need to reference it when the going gets tough.

Run blocks for your team. Put yourself between them and resistance, and coach your team to carry on regardless of possible negative feedback. 

Start small – don't convert your entire delivery process. In Ambit's case, we started with the team that was closest to the new delivery process and helped them across the line. Once that happens, market the success of your first team. Make it "cool," both for the business and IT team, to be like that team. Let the leaders for that first team get up at meetings and talk about their success, then applaud them in front of their peers. Champion the smallest wins.

TEP: Are there pitfalls to avoid?

Burke: The biggest pitfall to avoid is lack of communication or follow-up. As a leader, it's critical for you to reinforce the new mindset as often as possible. Change like this won't happen effectively with you on the sidelines.

In addition, a leader needs to clearly know the processes people follow in software development. You can't speak from a platitude when you ask them to change. Understand how they currently do things and what you're asking of them. This knowledge will lend you credibility and leverage when you reinforce the change in the face of resistance.