From the repaired screen to the resumed task

I completed my computer-science degree in May 1997 and joined Paruleni Systems Services in Mangaluru that June. The company supported business applications for regional organisations. I worked on incident reproduction, data checks and supervised software fixes. My first understanding of service quality came from watching a user try the task again after a technical repair. A screen could open while an attachment remained unavailable or a status field no longer meant what the user expected. I learnt to ask for a demonstration of the work, rather than accept the absence of an error message as the end of the incident.

In April 2003 I moved to Voluneri Vehicle Finance as an applications analyst. The lender had ten branches and a small internal systems team. I supported loan-administration applications and worked with finance and servicing colleagues on change requests. My responsibility was technical analysis and implementation under review, not deciding a borrower's terms. The move helped me understand why the same field could matter differently to two functions. A date useful for processing might not be the date finance needed for reporting. I began recording the business owner of a definition alongside its technical implementation.

I became service-delivery manager in April 2009. Eight colleagues reported to me, and I coordinated the work of external application and infrastructure providers. The role changed my relationship with incidents. I could no longer solve every issue myself, and a supplier's successful repair did not always restore the entire service. I introduced reviews that followed a task through its dependencies, including documents, permissions and the colleague authorised to complete it. This gave the team a more useful basis for discussing recovery and exposed gaps in our own instructions as well as weaknesses in supplier arrangements. We also recorded who could accept the restored service, because a technical team should not quietly make that business decision on everybody else's behalf.

In April 2015 I took the technology-operations role. The branch network was growing, and several applications depended on contracts negotiated at different times. I worked with the business owners to identify which services relied on historical records and which providers could actually return those records in a usable form. We did not replace every system. Some arrangements were extended while we clarified exports or trained internal support. I learnt to distinguish a dislike of an ageing application from a sound reason to change it, especially when a replacement would introduce new dependencies before the old ones were understood.

I became CIO in April 2021 and now lead twenty-one technology colleagues. I report to chief executive Anand Teruvani and work closely with chief financial officer Rebecca Selnadri. Our current annual technology envelope separates ₹12 crore of operating expense from ₹4 crore of capital expenditure. The company's ₹970 crore loan portfolio provides scale but is not a budget or credit authority delegated to me. I present technology matters to the board risk committee when invited. I do not sit on that committee and have never held a statutory director appointment.

Three recent decisions show the questions I bring to this role. A recovery exercise restarted the application but left some servicing tasks incomplete because documents were unavailable. A supplier exit offered data tables without the attachments needed to explain historical work. A reporting proposal promised a new platform before managers had agreed the definitions behind their most important decisions. Each case required technical work, but the decisive conversation concerned ownership and evidence. We funded repairs and verification, accepted additional time where necessary and kept a record of what the chosen scope did not solve.

My own development has involved becoming less impressed by a comprehensive project list. Earlier, I could describe every technical activity and still leave a business leader unsure which decision had become safer or more practical. I now ask colleagues to state the task that a change must enable and the person who can judge whether it works. That does not reduce engineering to a simple demonstration; performance, security and maintainability still need specialist examination. It gives those examinations a business context. I want my next role to preserve that connection as the organisation grows, with enough authority to challenge an attractive proposal and enough humility to recognise when my own preferred solution is adding complexity the business does not need.

Open to Board appointments · Executive opportunities

Languages / English · Kannada · Konkani