Vipin Gupta spent nearly eight years as CIO at Key Bank before joining Toyota Financial Services in 2018. While he leads all aspects of digital transformation and information technology, as chief innovation and digital officer of TFS he is building a more digitally savvy workforce. Recently I spoke with Gupta about the transformation he has helped to lead, the strategy behind the new architecture, and how he has added digital skills to his team. What follows is an edited version of our interview.\n\nMartha Heller: Can you describe Toyota Financial Services\u2019 digital transformation? \n\nVipin Gupta: The automotive industry has been reshaping into a mobility business, which goes beyond manufacturing and selling cars to providing services to move people and material safely from point A to point B. So, three years ago, we started asking the question, \u201cIf Toyota Financial Services were born today, how would we design it?\u201d \n\nOur answer was to become a mobility-finance-as-a-service platform and grow from captive finance for Toyota and Lexus to providing financial services for other mobility companies. We wanted to offer the same quality services that we deliver to our own brands to other automakers and mobility businesses.\n\nIn April 2020, just seven months after we signed a partnership with Mazda, we launched our first private label business as Mazda Financial Services on a new multitenant mobility finance platform built from the ground up using modern technologies all in the cloud. \n\nHow did you transform the business so quickly?\n\nThe key to our moving so quickly came from turning the transformation logic upside down. Yes, we need to transform the technology to transform our business, but before that, we focused on transforming our behaviors to move more quickly with new digital business practices. Our early focus on behaviors and habits first was the real game changer. \n\nOne key to driving change in behaviors was shifting our operating model from projects to digital product factories. We knew that the traditional time-bound project model was inefficient, with administrative overheads. Product Digital Factories, on the other hand, have a dedicated team, or \u201cfactory,\u201d accountable for continuously improving a product capability.\n\nSecond, we adopted the mindset of building a software product just like we build cars. We applied Toyota\u2019s world class car manufacturing and engineering practices to software engineering. We designed each digital factory with a fixed capacity that delivers software changes on a fixed cadence of every two weeks. By fixing the capacity and output cadence each factory teams were naturally forced to prioritize to deliver what matters most for when it is needed, inspired by just-in-time principle. This helped deliver the highest business value capabilities early, and at lower cost of delivery.\n\nThird, we pulled the company\u2019s top decisionmakers into leadership action teams, which meet regularly, like a scrum, and answer only one question: What is the impediment to a factory\u2019s deliverables? The goal of the leadership action team is to remove that impediment with a belief that when impediments are removed, the empowered factory owners will lead their teams to their goals quickly. This has given us amazing speed.\n\nA significant source of waste in IT comes from the time-to-decision-making inside and outside of IT. The speed of the leader is the speed of the team. The decision-making waste starts at the top of the organization. Once we have clarity of decision at the top, the teams deliver quickly. \n\nHow did you approach the new architecture?\n\nOur first guiding principle was that instead of modernizing existing legacy systems one by one, we would design a completely new architecture all in the cloud, as if we were born today, which freed us from conversations about upgrading systems. \n\nSecond was that our architecture for every system would be a multitenant design tied by a common tenant I.D. across all systems. This would allow us to provide services to customers through a shared infrastructure, while keeping the data separate. That balancing act\u2014sharing infrastructure but not data\u2014means that every system that we introduce to the new ecosystem is designed to be multitenant, which influenced our data models and the design of data supply chain.\n\nThe third principle was not just \u201cAPI first\u201d but \u201cAPI must\u201d for every system to interact with each other, and for external partners to use our services. APIs were not an option, choice, or decision point. API and microservices must be a way of life.\n\nFourth was designing for agile analytics, where the data, regardless of where it resides, will be available to our analytics and data-science teams. We call this a data supply chain, where rather than building a system data interface to push data into the data warehouse, we created an integrated data cloud to continually pull data from our systems. We not only streamlined data flow for analytics, but we also reduced point-to-point system interfaces and liberated our operational systems from the accountability to push the data. \n\nFinally, for customer experience, we went one step beyond omnichannel to \u201con my channel,\u201d which prioritizes the customer point of view in how we design experiences.\n\nThose elements\u2014all in the cloud, multitenant systems, \u201cAPI must,\u201d pull-based data supply chain, and \u201con my channel\u201d experiences\u2014became the guiding principles for every system that we built or bought. This standardized approach allowed us to move quickly in building the new architecture.\n\nWhat advice do you have for other CIOs in designing a new architecture?\n\nOne piece of advice is not to be so focused on the functional requirements of the architecture that you ignore the technology operational elements, like monitoring, detection, and self-healing capabilities. Had I to do it again, we would have thought more about the operational elements of the ecosystem and designed them proactively rather than reactively, as we are doing now.\n\nAlso, a new digital architecture and operating model requires teams to grow new skills. In addition to acquiring talent from the outside in this tight talent market, we focused on developing our existing teams. So, we created the TFS Digital Academy around the idea of \u201clearn, do, teach, do\u201d so that we can all grow our digital competencies together. Our thinking is that teaching is key to learning, and there are no better teachers than our own experts. Whether you are a TFS employee or a consultant, you are getting trained on the same practices. In addition to sharpening our skills, this drove consistency in our behaviors and practices, further reducing waste and increasing speed.\n\nBased on the role you are playing at TFS, how do you see the CIO role evolving?\n\nThe role of the CIO going forward is to be the architect of the future version of the business. The CIOs have a holistic enterprise vantage point to influence the design of not only the platform, but also the organizational model, business model, and process models. Good CIOs transform IT from inside, but great CIOs use design thinking and inclusivity to transform IT by changing what happens outside of IT.