The responsibilities that shaped an information-service career

Mandate

Maintain explainable administration systems and the authority boundaries around long-lived member records

Outcomes

• Retained historical rule-evidence gaps for client-authorised review rather than attach a convenient current version
• Delayed a support workspace until its client-export boundary was corrected and tested
• Broadened statement acceptance and software renewal decisions to include continuing member needs

Decisions in context

The CIO appointment made me responsible for connecting application design, access, supplier arrangements and the service the company continued to owe its clients. I lead 47 colleagues through four heads, with operations expense and capital approved separately. The organisation's 620,000 member records do not represent investment assets under my management or under the company's custody. I report to Rajan Zemquvri and work alongside Nazia Tezqavri on the evidence benefit operations needs. The cases show where I accepted delay, cost and manual review rather than turn a technical result into an unsupported business conclusion. I also revised my own assumption about downloadable statements after user rehearsal. Executive presentations to directors form part of the role, but I have no statutory seat. The next development step is to contribute that experience to collective oversight without becoming a second manager of another company's systems.

Reason for the move

Current role; considering a first outside contribution after preparation and appointment-specific review

Mandate

Coordinate applications, infrastructure, access support and technology suppliers around continuing administration work

Outcomes

• Added infrastructure and supplier responsibilities to the earlier applications remit
• Examined how access and contract definitions affected former-employee service
• Developed the wider systems-and-service perspective required for the CIO appointment

Decisions in context

This appointment expanded the questions I needed to ask beyond whether an application change worked as specified. I led 29 colleagues through three managers under the CIO, coordinating infrastructure and suppliers as well as applications. The service continued across changes in a member's employment status, while software and access arrangements often used simpler categories. I learned to examine those categories before they became operating restrictions. A person no longer employed by a client might still need an authorised statement or enquiry, and a record rarely opened could still matter. The work required benefit operations to explain the task and technology to make the supporting arrangement usable. I did not own the client's fiduciary or benefit decisions. The later CIO role grew from connecting those boundaries with the enterprise's resource and supplier choices, including the costs that a narrow technology measure could leave outside its account.

Reason for the move

Promoted to CIO in February 2021

Mandate

Develop administration applications whose records support authorised client and benefit-operations decisions

Outcomes

• Learned the distinction between administrative calculation and benefit authority
• Connected rule versions and effective periods with the records they supported
• Built the sector understanding needed for a wider information-operations remit

Decisions in context

Joining Qezvuni moved me from general client implementation into a service where the supporting record could remain important long after the original employment event. I led sixteen colleagues through two leads under the head of technology. Benefit operations explained the meaning and limits of the tasks we were supporting. I learned that a calculation, an instruction and an authorised decision were related but distinct parts of the process. The application needed to preserve the evidence required by the responsible people rather than make a convenient field stand for every stage. My budget covered the applications work, not client assets or benefit payments. Moving to Mysuru also required learning a new working environment and developing practical Kannada. The promotion in 2015 followed a broader understanding of how records, access and operating service fit together, rather than a claim that technical familiarity made me a pensions professional.

Reason for the move

Promoted to head of information operations in June 2015

Mandate

Prepare client teams to carry out administrative tasks after application delivery

Outcomes

• Added team leadership and expense responsibility to programming experience
• Used uncoached task rehearsal to expose assumptions hidden by demonstrations
• Learned to distinguish a technically completed release from a workable client process

Decisions in context

The implementation role put me beside the people expected to use the application after our project team had left. Eighteen colleagues worked through two supervisors within a defined delivery expense remit. I reported to the head of client services and coordinated with the developers and client process owners. A demonstration could look smooth because the presenter supplied context at every step. I began asking users to complete a defined task without that explanation, then describe what they believed the system had established. The exercise often revealed a difference between a familiar label and its practical meaning. I learned to make those findings part of the implementation decision rather than dismiss them as a training problem. The move into retirement administration followed an interest in work where that relationship between record, explanation and authorised action remained consequential over a longer period.

Reason for the move

Joined Qezvuni in September 2008 and relocated to Mysuru

Mandate

Implement and test specified changes while preserving the business explanation of service records

Outcomes

• Learned to connect a field value with the event and period it described
• Tested changes under supervision without assuming client decision authority
• Built the practical foundation for later implementation and service leadership

Decisions in context

I joined after completing computer science in June 1995. The first role was supervised programming within a seven-person group, without reporting staff or spending authority. I implemented specified changes and learned to compare the result with the business event the record was meant to describe. A current value could be correct while leaving a colleague unable to explain an earlier statement. That observation made me interested in the history and meaning around data, not only the mechanics of storing it. I could raise a question about the specification, but the client process owner retained the decision about its intended business meaning. The later management appointment added responsibility for people, delivery expense and client readiness. It did not erase the early lesson that a technically plausible output needs an explanation grounded in the work it supports.

Reason for the move

Promoted to client implementation manager in April 2002