The CIO mindset is often heavily focused on data and software . But keeping a close eye on other factors that play a key role in IT management, such as physical infrastructure and external economic forces, is crucial to the job as well. While computer science training is key, CIOs also benefit from utilizing the guiding principles of engineering such as redundancy, durability and scalability.
Amit Chadha is intimately familiar with how these two perspectives overlap and complement each other. He serves as CEO and managing director of L&T Technology Services, a company that offers engineering research and development (ER&D) services. Trained as an electrical engineer, he has deployed those skills in a range of management and leadership roles. Chadha served as a pivotal advocate during LTTS’s 2016 IPO. The India-based company is now a powerful player in ER&D and boasts some 1,500 patents — many focused on AI applications.
Here, he speaks with InformationWeek contributor Richard Pallardy about how CIOs can deploy engineering principles to make their organizations more functional and resilient.
Engineers often design for long-term durability and scalability. Software development can prioritize speed and iteration. How can CIOs reconcile these conflicting philosophies to make their IT ecosystems more sustainable?
Amit Chadha: Having something long-lasting doesn’t mean that you need to do it slowly. The design intent should be to have it last a long period. The way you design it could be iterative. It could be fast or slow. It could be a buildup. It could be a Waterfall model. It could be an Agile model.
In the new world of AI, with everything getting done in an automated manner, I believe that there’s a lot more that can be achieved with similar resources that we had years ago. Ten or 15 years ago, you would need a lot more servers to get the same throughput or output. I’ve seen CIOs as well as CTOs focusing on the speed as well as the longevity of what they launch.
So achieving speed and longevity has become more feasible in software development, thanks to AI and automation. Do you see these principles also driving physical systems like robotics and transportation? Do CIOs need to be thinking about these advancements when planning for these areas?
Chadha: You’ve got to start thinking about physical AI. You’ve got to start thinking about agentic AI. It will come onto the shop floor fairly quickly. We are seeing a resurgence of industrialization and manufacturing in the U.S. We don’t have enough qualified people. I believe that if we can leverage systems and automation for that, it will go a long way ahead in terms of achieving our ambitions and dreams.
There is a fair degree of training that will need to be provided to the workforce to be able to work these systems. But these are highly autonomous and fairly perceptive systems. [CIOs] should start thinking about digital employees. That’s what we’re doing within LTTS. There is a fair bit of code generation, code testing, use case testing and end user testing that can be done in an automated manner. AI and automation allow you to execute a lot more than you could do otherwise because of either the non-feasibility of compute power or storage, or even the cross-functional leverage that you have today. A lot of systems are built to be standalone. Then you try to put a wrapper around it, and you bridge them in. [We need to] start thinking about multi-point connectivity and exchange of data and actions, so it can become an integrated lot. I believe that AI provides us with the ability to do it. I would ask CIOs to actively think about all of this as they look at the future.
Do you think there are dangers to some CIOs prioritizing software scalability without considering the physical infrastructure that it depends on?
Chadha: Hardware has reached a certain level, and software is catching up. If you look at the kind of investments that the hyperscalers are making on building up AI compute capacity, I think that hardware and software will continue to grow hand in hand. But when you look at software, there’s a definite need to look at the compute power.
We have clients who are working on edge AI. A lot of your decision-making gets done on the edge — it does not need to come back on Wi-Fi or back to the cloud. There’s a micro LLM [large language model] that can make those decisions right there on the edge, so there are different parts of new hardware available that can support the functionality needed. I would look at any functionality as a hardware plus software issue, and not just as a software issue.
Computer science often relies on abstraction to simplify complexity, but engineers have to deal with the realities of very physical constraints. What risks do you think CIOs face when they rely too heavily on abstraction when they’re making decisions?
Chadha: You start with your basic data. The moment you start to build it out and start putting all the assumptions in is when you start to face the problem of abstraction. A lot of these models are based on what you know today. But the market is changing. The compute power is changing. What’s available from third parties is changing. There are times when you make quick decisions because in your mind, it’s a plug-and-play. But the reality could be different — the computer is not available, the data is not available, or the systems are not available. The people that are working the system may not be equipped to handle it. You actually have to walk through it before you make a decision.
Engineers often design systems with failure in mind, creating redundancies and fail-safes. Do you think CIOs should embrace some of that mindset in order to prepare for failure?
Chadha: Absolutely. And they do! I started my life in a data center. I can vouch for it. We made sure that there was a lot of redundancy baked into the solutions. The one place where engineers and CIOs differ is that the CIO thinks hardware is available — it’s the software that makes things tick. An engineer looks at the hardware and the software, because you are working in areas where the hardware may not be readily available. It’s a question of what’s available at that point in time.
