From reproducing a fault to questioning the specification

Mandate

Preserve the transaction states and decision rights on which auction and yard administration depend.

Outcomes

• Separated forty-two bidder changes into thirty-one same-entity contact requests and eleven entity-change proposals.
• Supported a commercial pause and next-day reoffer of forty-eight lots after a twenty-seven-minute interruption.
• Kept five seller bank-detail requests held while nineteen progressed through the appropriate confirmation route.
• Distinguished nineteen held records from fifty-five files entering policy review.

Decisions in context

As CIO I lead four IT leads and their teams while working with Maya and Arun on the systems used by our auction agency. The annual expense includes change programmes rather than adding them as a second budget. My recent decisions concern the relationships that remain important when a field or system state changes: the original bidder, the commercial pause, the authorised settlement detail and the reason a record must be retained. I want those relationships to be understandable to operating owners without requiring them to infer the business position from technical logs. The role does not give me authority over seller funds, vehicle certification or title. It gives me responsibility for making the agreed decisions usable in the system and for stating honestly when the evidence is incomplete. That boundary has become central to my contribution to enterprise discussions.

Reason for the move

Current executive remit; exploring an initial company-board contribution alongside it.

Mandate

Develop the systems supporting published catalogues and the agency's operating relationships.

Outcomes

• Led nineteen colleagues within ₹4.1 crore annual expense.
• Accepted responsibility for a design that overwrote thirty-nine published lot descriptions.
• Supported twenty-seven evidenced reconstructions and retained twelve unrecoverable editions as explicit gaps.
• Delivered a ₹42 lakh repair while commercial owners reoffered nine lots and withdrew three.

Decisions in context

The director title described my functional executive role; it did not include a statutory company directorship. I became responsible for a larger team and for the design choices affecting published auction material. The 2019 catalogue error was a defining event. I had approved keeping the latest inspection in place of the earlier published description, then had to explain why twelve previous editions could not be recovered. The response required technical repair and a separate commercial decision about the affected lots. I learned to preserve uncertainty instead of treating a complete-looking record as the main objective. I also learned that a design can work exactly as specified while the specification misunderstands the transaction it supports. That experience influenced the CIO remit I later accepted, particularly the need to bring commercial owners into decisions before apparently simple updates become routine.

Reason for the move

Appointed CIO with broader enterprise systems responsibility.

Mandate

Connect application support with the operating responsibilities of an auction agency.

Outcomes

• Led eleven colleagues within ₹1.9 crore annual expense.
• Distinguished agency revenue from the value of transactions passing through the platform.
• Worked with operating owners to define the business meaning of records and application changes.

Decisions in context

Moving from a systems-service firm into an auction agency required me to learn a different business model. The value of a vehicle offered through our service was not the agency's revenue, and maintaining a description did not make us the certifier of its condition. I reported to the operations director and managed eleven colleagues supporting the applications used by regional teams. The work brought me closer to the decisions behind records: who supplied a fact, who could amend it and which participant or commercial process depended on it. I wanted the team to understand those relationships before proposing a technical simplification. My authority remained the IT function within the stated expense scope. The role prepared me for broader responsibility by showing how application choices could change the apparent meaning of a transaction even when no one intended to alter the underlying commercial arrangement.

Reason for the move

Promoted to functional IT director as the organisation and systems remit expanded.

Mandate

Translate operating requirements into application changes with clear business ownership.

Outcomes

• Managed six colleagues within ₹56 lakh annual expense.
• Worked with business owners to distinguish a technical update from the decision it represented.
• Carried user questions into design discussions instead of closing them solely as service incidents.

Decisions in context

The applications lead role moved my work from reproducing faults toward shaping changes with the people who would use them. I led six colleagues and reported to the applications services director. A requirement often arrived as a request to add or edit a field, but its useful meaning depended on an operating decision. I learned to ask who supplied the value, who could approve a change and what earlier activity would still need to be understood afterwards. The team had to make those questions practical rather than turn every small improvement into a lengthy abstract debate. I became interested in working within one enterprise, where I could follow the consequences beyond implementation. That interest led to Nerqavzi and a role closer to the daily commercial and administrative work supported by the applications.

Reason for the move

Joined an auction agency to take responsibility for systems within one operating enterprise.

Mandate

Reproduce reported application behaviour and help the responsible owner understand the user's problem.

Outcomes

• Joined in July 1996 after completing the computing degree that May.
• Prepared incident records and reproduced reported behaviour under a service manager.
• Escalated business questions beyond support authority rather than infer a commercial answer.

Decisions in context

I began by listening carefully to what a user was trying to do and comparing it with the behaviour of the application. The work was practical and supervised. I had no budget or authority to decide a customer's commercial arrangements, but I could make the sequence clearer for the people responsible. Sometimes a reported fault was a genuine system failure; sometimes the application was doing what the specification required while the user needed a different decision. Learning to preserve that distinction helped me avoid offering a technical answer to a question the business had not settled. I prepared records, reproduced behaviour and followed the issue to the appropriate owner. The role established a habit I still value: explain what the evidence supports, keep the unresolved question visible and resist making the record appear complete before the actual problem has been understood.

Reason for the move

Promoted into application leadership with a small delivery team.