2020 Best CIO Acceptance Speech (penned in 2010)

For people who do not know me, it must be difficult to comprehend how I became the CIO of this mega multinational conglomerate. It has been an uphill task to move from the server rooms to this boardroom; believe me that technology skills alone were not good enough to make this gradual but sure leap. Looking back, I give credit to a heady concoction of portfolio management experience, stead fast communication, and adoption of agile principles and practices across all the IT divisions that made this happen. And also a lot of good old luck.

When I joined this organization as the VP of Engineering, 10 years back, agile was still in its teens. Many of my fellow managers had heard of rapid release capabilities, but had never seen a company really do it. I knew from my experience in media start-ups that Agile would be mainstream in a few short years; it was just a matter of time. And there are obvious benefits in doing iterative development to incrementally build software products. Besides, Agile with its ‘inspect and adapt’ philosophy chimed well with the PDCA (plan-do-check-act) paradigm of lean operations. However it was hard for me to sell this apparently obvious concept of evolutionary software product development to the bosses.

The idea of “iterating” over a concept was something that only startups were doing. Those ideas somehow did not seem ‘stable’ for an organization as large as ours. In addition, we were tied to licensing large technology stacks and rigorous deployment checklist gates, making it difficult to accommodate frequent releases; we were limited to only two enterprise wide releases in a year keeping in mind the cost of integrating with the legacy systems for each such release. While my bosses understood the proposed benefits of evolutionary software product development, they were not ready or prepared to revolutionize our IT divisions. So I was up against massive organizational dissent when I started advocating change: adoption of Agile’s evolutionary concepts and using open source platforms and tools for product development.

Change is always an alien, still you see it happen! Since I believed so strongly in this vision of evolutionary software product development, I wanted to prove it to those who could fund my vision and allow me to effect change. I started small, with one project in my department. I was able to illustrate moderate success with the pilot; the business sponsor for the project was impressed with the cost control and the discipline involved in building the product iteratively. I got the go-ahead to introduce the change virus in my department, one project at a time. This took me a couple of years, but at the end of the second year I was asked to run another division and made the same changes. These divisions were releasing so frequently and their business counterparts were so involved that other divisions started referring to us as the “Business Technology” group within the next few years. Finally, I tackled the data warehousing and mainframe divisions. A Value Stream Mapping exercise pointed out the areas needing the most attention and we started the multi-year effort of reworking our mainframe.

Back in 2010, the Gartner group wrote an article that strongly impacted the way I thought about team dynamics. I was not the CIO, but thinking like one helped me further transform my teams. This article, “Leading in Times of Transition: The 2010 CIO Agenda”, called out a few key differentiators that CIOs (and managers like myself) should consider as we were moving from a time of recession to recovery. By focusing on the business, not on the needs of IT as a separate entity and by iterating through business solutions, we were positioning our teams and our company to move forward faster than our peers. Over the years, our mindset changed. We began to not just SAY that the needs of our business was the heartbeat of our company, but we began to align our technology solutions around the needs of our business so our actions matched our words. We, IT, began to really value the aspects that businesses value: output, productivity over efficiency, priority driven schedules, demand driving supply, ROI, etc.

Gradually, one success at a time, I found strong support from the upper echelons of business that didn’t well-understand agile but were seeing the output and hearing the excitement from their own peers. These business leaders comprehended the obvious cost benefits of the following concepts that became foundational for our company:

• using open source software to develop and deploy iteratively
• doing more frequent discovery-delivery-discovery cycles to keep in touch with the market
• waiting till the last responsible moment to commit to key decisions
• adopt metrics to foster collaborative team dynamics rather than focusing on individual brilliance

Now, 10 years later, agile is truly mainstream. No development organization, internal or external, speaks of also-doing-agile or agile-in-stealth-mode. agile is the default software development practice across most organizations. In the same way that no one specifically speaks about “Object Oriented Development” or Cloud Computing as separate practices, agile today is not considered alien but an integral part of the software development teams. Over the past 10 years, I’ve seen larger organizations who could not envision a roadmap of change stagnate and often close their doors to their smaller, more “agile” competitors, so I believe that there are invaluable lessons to be learned here.