From reproducing the event to owning its service consequence

Mandate

Make the continuing conditions of digital retail service visible in technology decisions

Outcomes

• Funded keyboard-journey repairs with unresolved tasks retained in acceptance
• Established a device-support transition with installed and pending groups separately reported
• Connected technical limitations with operating responsibility in executive proposals

Decisions in context

The CIO remit brings together service operations and change, with twenty-four colleagues through three leaders. I distinguish ₹4.1 crore annual operating expense from ₹1.2 crore approved change authority because the continuing service and a particular improvement create different commitments. The keyboard programme required commercial and accessibility participation, while the device transition required security, procurement and shop preparation. I report to the CEO and work with the COO rather than assume that a technology budget gives me authority over every service policy. Invited presentations to directors concern the evidence and choices behind those commitments; I do not hold a statutory seat. The role has made me more deliberate about reporting what remains unfinished after a visible milestone. Installed equipment, a completed task review and a released application each need a clear meaning before they become a statement about the whole service.

Reason for the move

Current appointment; considering a consumer CIO mandate and a prepared first outside contribution

Mandate

Coordinate retail applications and support around a dependable operating service

Outcomes

• Held a release after synthetic retries created duplicate order records
• Acknowledged the limited test scope previously endorsed
• Brought transaction meaning and exception handling into joint acceptance

Decisions in context

I led seventeen colleagues through two managers and worked within ₹2.8 crore annual operating expense. The appointment widened my responsibility beyond individual applications to the way the retailer depended on them. In 2019 the retry rehearsal exposed a weakness in a release review I had supported. I had to explain why a successful demonstration and a planned date were insufficient reasons to proceed with the affected flow. The repair needed more than an engineering change: operations had to understand an uncertain result, and finance had to agree how the order account would be reconciled. That experience prepared me for CIO leadership by making acceptance a business responsibility with technical evidence, rather than an engineering milestone that other functions were expected to trust. It also established that I would revisit my own sponsorship when a later test changed the meaning of the result.

Reason for the move

Appointed CIO with enterprise information and service-investment responsibility

Mandate

Connect shop applications with the operating decisions they were intended to support

Outcomes

• Followed application changes beyond technical release into shop use
• Included operating colleagues in acceptance discussions
• Separated ticket closure from completion of the underlying service work

Decisions in context

Moving inside Tervqani gave me continuing responsibility for the effect of an application change. Ten colleagues worked within ₹1.6 crore annual expense, and the shop teams could show us what happened after a ticket had been closed. I learned that the support account and the user's account could both be accurate while describing different stages. A technical repair might leave reconciliation or customer explanation unfinished. I began asking operating managers to help define the intended result before we chose the implementation. The appointment did not give me authority to rewrite commercial policy or approve every investment. It gave me the opportunity to make technology advice more useful by connecting it to the work around the screen. That practical understanding became important when I later had to challenge a release whose ordinary demonstration appeared successful.

Reason for the move

Promoted to lead systems across the growing retail network

Mandate

Make investigation and technical handover usable by the client decision-maker

Outcomes

• Improved the distinction between observed behaviour and inferred cause
• Prepared unresolved service states for client review
• Helped junior analysts challenge an early diagnosis with reproducible evidence

Decisions in context

I supervised six analysts within ₹72 lakh annual delivery expense. Our clients retained release approval and commercial policy, while my team needed to provide an investigation they could actually use. The role showed me how a senior person's preferred explanation could narrow the questions asked by everyone else. I encouraged colleagues to preserve the observed sequence and to say when the evidence did not yet establish a cause. A useful handover also needed a practical next step, not only a technically accurate description of the failure. I wanted the client to understand what could be tried safely and what required further review. The move to Tervqani followed from that interest: I wanted to remain accountable for the service after the advice had been delivered and the support engagement formally closed.

Reason for the move

Joined a retailer to own application outcomes beyond external support delivery

Mandate

Reproduce reported application behaviour and preserve evidence for authorised reviewers

Outcomes

• Learned to distinguish a missing response from a failed underlying action
• Prepared reproducible accounts of reported behaviour
• Kept deployment and commercial decisions with the client and senior engineers

Decisions in context

I joined after completing computer-science studies in 1994 and worked within a five-person support group. My tasks involved reproducing what users reported, examining the available records and preparing an account for a senior engineer. I did not decide when a client should deploy a change or spend money on a replacement. The work made me careful with apparently simple descriptions such as failed, complete or missing. A user might see no response even though an action had been recorded, and an engineer needed the sequence rather than an assumed conclusion. I learned to ask what the person had done, what they had seen and which part of the evidence remained unavailable. That discipline was modest in scope but important later, when I carried responsibility for decisions whose consequences extended beyond the application team.

Reason for the move

Promoted to supervise client support delivery