Following the record from fieldwork to the board

Mandate

Lead enterprise information systems while preserving qualified engineering and customer decision authority

Outcomes

• Separated visit closure from technical acceptance after reviewing sixty-four records
• Restored distinct identities for fourteen assets affected by repeated serial strings
• Replaced silent offline overwrites with authorised conflict resolution

Decisions in context

The CIO appointment made me responsible for our information estate and its account to directors. I lead twenty-two colleagues through three managers, with ₹6.4 crore operating expense and a separate ₹1.6 crore capital allocation. Company revenue is not my delegated budget. My remit covers applications, infrastructure, support and information controls; technical acceptance remains with qualified owners. The three cases required me to correct assumptions in designs I had supported. I removed an approval mapping, funded identity reconciliation and delayed an offline release. Each decision imposed work on teams beyond IT, so I had to explain the operating burden as well as the software change. I report to Diksha Varqeshi and work with Joseph Melqashi on the boundary between a system record and an engineering decision. I hold no equity or statutory seat and present to the board in my executive capacity.

Reason for the move

Current appointment; considering future information-leadership and first-board opportunities

Mandate

Join applications, infrastructure and field support under a coherent service model

Outcomes

• Brought application and infrastructure support into a shared operating review
• Introduced explicit owners for field-data exceptions
• Expanded release testing to interrupted connectivity and disputed records

Decisions in context

This role widened my responsibility beyond application delivery. I led fifteen colleagues through two managers by departure and managed ₹4.1 crore annual operating expense. Infrastructure and support decisions now affected whether field teams could record work reliably across customer locations. I learned to treat interrupted connectivity as a condition to design for, rather than as an inconvenience users should simply avoid. I brought support incidents and disputed records into release reviews, although our later synchronisation case showed that the approach still needed improvement. The role did not give me authority over engineering methods or customer acceptance. I worked with technical owners to understand those requirements and assigned information-system responsibilities around them. The promotion to CIO followed the need for a clearer enterprise account of investment, information risk and the limits of what our applications represented to management and customers.

Reason for the move

Promoted to enterprise information leadership

Mandate

Develop and maintain service applications with technical process owners

Outcomes

• Documented different meanings of visit completion and acceptance
• Established business ownership for application-state definitions
• Connected field support issues with change and release planning

Decisions in context

Joining an equipment-servicing enterprise changed the questions I asked of an application. I managed nine colleagues and ₹1.8 crore annual application and support expense. Technical colleagues had professional responsibilities that a convenient screen could not absorb. I learned to distinguish the record of a visit from the judgement made about the equipment, and to ask which customer arrangements applied. My team could implement permissions and workflow, but the responsible owners had to define the underlying decisions. I also learned that an apparently tidy migration could separate an event from its physical context. Those lessons were not completed once and for all; later cases exposed assumptions we had still allowed through. The move to head of information systems broadened my remit to infrastructure and field support, requiring me to connect application design with the conditions under which people actually used it.

Reason for the move

Promoted to responsibility for the wider information estate

Mandate

Lead application releases and support coordination with service-process owners

Outcomes

• Used incomplete and disputed jobs in workflow design reviews
• Recorded process-owner decisions before release approval
• Connected support findings with subsequent application changes

Decisions in context

I led seven analysts and developers within ₹76 lakh annual team delivery expense. I coordinated releases with service supervisors and reported to the head of delivery. Commercial pricing and contract commitments remained with management. My main development was learning to test a process against work that did not proceed neatly. A disputed completion, an incorrect identifier or an interrupted update could expose assumptions absent from a demonstration built around a successful visit. I began asking process owners to explain those cases before we agreed the application behaviour. The work also taught me to distinguish a software defect from an unresolved business decision, while recognising that the two could interact. I moved to Qerthuni to take continuing responsibility for an enterprise's applications rather than hand each release back to a customer team and move on to the next delivery assignment.

Reason for the move

Moved into an internal information role in a technical-service enterprise

Mandate

Translate service-team requirements into testable application changes

Outcomes

• Compared screen terminology with the decisions made by service staff
• Recorded examples of incomplete and corrected work for testing
• Supported users while keeping project approvals with the manager

Decisions in context

I joined one month after completing my computing degree. As an individual contributor in a five-person team, I had no budget ownership and estimated assigned work for the project manager's approval. I spent time with service administrators to understand what their terms meant in practice. Complete was particularly revealing: different people used it to describe the end of a visit, a review of the paperwork or a customer's acceptance. My early contribution was to bring those differences back to the team rather than assume one field would serve every purpose. I also supported users when records needed correction and learned why a change history mattered to someone investigating a later question. Promotion to delivery lead gave me responsibility for coordinating other people's work and made me more accountable for the assumptions that moved from a conversation into a released application.

Reason for the move

Promoted to leading application delivery