From the support call to the investment decision

Mandate

Make field applications, device protection and technology investment dependable in the circumstances of the company's branch network.

Outcomes

• Retained receipt identity through repeat transmissions and separated release completion from 37 unresolved records
• Reduced a daily device package from up to 720 borrower records to at most 42 assigned records
• Released nineteen translated prompts while holding four after task-based testing
• Removed 84 unsupported handsets from field use through an approved ₹16.4 lakh first replacement stage

Decisions in context

I took the CIO role when the company needed a single executive view of applications, infrastructure, security coordination and the technology budget. My four functional heads lead the specialist work, while I establish priorities with the CEO and the executives accountable for customer and financial consequences. The cases here occurred during this appointment. They required us to resist a complete-looking release report, accept a less convenient data-access arrangement and phase expenditure without pretending that deferred cost had disappeared. I attend the board risk committee for relevant items and answer questions about the evidence behind our conclusions. I am not a director. The role has deepened my interest in explaining technology through the choices it gives management, including a clear description of the uncertainty that remains after a control or release has been implemented.

Reason for the move

Current appointment; exploring a first external board contribution with a defined time commitment.

Mandate

Bring infrastructure, suppliers and field support into a coordinated technology service.

Outcomes

• Established a common service record linking branch reports to application or infrastructure ownership
• Introduced device-support evidence into procurement reviews
• Built three managers' responsibility for service decisions beyond the applications team

Decisions in context

The move broadened my responsibility from what an application did to the conditions in which it could be used. A branch problem might arise from a device, a connection, a supplier handover or the software itself. Staff did not benefit when those possibilities became separate queues with no coordinating owner. I worked with the service managers to preserve the user's account while assigning the investigation to the relevant team. Supplier reviews became more specific about the evidence of support, rather than relying on a promise that equipment remained available. The financial scope was a technology operating budget, not authority over the company's lending or collections. I developed managers who could explain the consequence of a service decision to operations colleagues, which prepared the team for the broader CIO structure introduced in January 2022.

Reason for the move

Promoted to CIO as the company created an executive technology remit reporting to the CEO.

Mandate

Translate branch workflows into application requirements that preserve the meaning of customer and account records.

Outcomes

• Documented the distinction between local storage and central acceptance
• Included branch users in testing of messages and task sequences
• Built a review relationship with finance and compliance for changes affecting customer records

Decisions in context

Joining a lender required me to learn which decisions an application could implement and which it could not make. I spent time with finance, credit and branch colleagues before assuming that a familiar software pattern suited the business. A local action might be useful to an officer while still needing central acceptance before another function could rely on it. We documented those distinctions in requirements and used branch rehearsals to expose ambiguous wording. I also learnt to ask about the consequence of a proposed correction, because changing a record could affect the customer beyond the screen under review. The role gave me a financial-services grounding without turning me into a credit specialist. The later promotion recognised the team's ability to connect application work to the broader operating service and maintain productive relationships with the functions responsible for customer treatment.

Reason for the move

Promoted to head of technology operations, adding infrastructure and supplier responsibility.

Mandate

Prepare district-office teams to use and support new administrative applications after installation.

Outcomes

• Replaced demonstration-only sign-off with observed user tasks
• Documented local support ownership before project handover
• Fed recurring user misunderstandings back into the development backlog

Decisions in context

Implementation gave me responsibility for the transition between a project and ordinary work. I supervised colleagues travelling to district offices, planned the sequence of installation and training, and brought user observations back to developers. We could not assume that a successful demonstration meant the office was ready to operate without us. I asked staff to complete representative tasks while we watched, then recorded where a label, a missing reference or an unclear support route stopped them. The team also needed a named local contact and an agreed handover record. I did not control public-service eligibility or the office's administrative decisions; our responsibility was the software service commissioned by the client. I eventually wanted to remain with a system through years of operation, which made the opportunity to join Zeravien's internal technology team a natural next step.

Reason for the move

Moved to an in-house applications role to remain accountable for a service beyond project completion.

Mandate

Reproduce reported application problems and help users distinguish a failed action from missing confirmation.

Outcomes

• Built incident notes that preserved the user's sequence of actions
• Reproduced failures involving interrupted connectivity and power
• Developed the field knowledge that led to an implementation-lead appointment

Decisions in context

I joined soon after completing my computer-science degree and initially expected support to be mainly a technical exercise. The work taught me to listen before diagnosing. A clerk might describe the same incident differently from the system log because the two accounts began at different points in the sequence. I learnt to reconstruct both, including whether the user saw an acknowledgement before power or connectivity failed. I travelled with more experienced colleagues and gradually handled investigations independently. The role did not include a budget or authority over the customer's administrative process. Its value was the discipline of making a problem reproducible without blaming the person who reported it. That experience shaped my interest in implementation, where I could address some misunderstandings before they became recurring support calls after a project team had left.

Reason for the move

Promoted from support into responsibility for implementation teams and handover.