From investigating faults to explaining technology dependence

Mandate

Make technology decisions answerable to the service context and professional authority they support

Outcomes

• Supported clinical reconciliation of six duplicate entries within an eighty-four-visit outreach review
• Redesigned notifications after thirty-one shared-phone concerns in a ninety-six-account preference review
• Revoked seven ownerless accounts from eighteen reviewed vendor accounts
• Repeated a seven-dataset recovery exercise successfully after correcting two missing attachment references

Decisions in context

The CIO role requires me to explain technology choices across a regional service business, not only to deliver a system within an IT department. I lead nineteen colleagues through three managers and report to Temjen Nerzovar. Clinical director Rehana Veshmali retains professional authority through qualified teams. I have learned to make several boundaries explicit: transmission versus reconciliation, message delivery versus appropriate communication, a supplier contract versus current access sponsorship, and application availability versus usable recovery. These distinctions affect spending and sequencing as well as language. Our recent cases include ₹36 lakh for outreach synchronisation, ₹22 lakh for notification design, ₹18 lakh for access review and ₹49 lakh for recovery work. They are separate projects within the stated remit, not a claim that all company results arose from IT. I present technology matters to directors by invitation without holding a board seat or committee vote.

Reason for the move

Current role; assessing a first external board contribution alongside continuing executive responsibilities

Mandate

Connect centre administration with outreach records while preserving clinical ownership

Outcomes

• Established clearer routes for reviewing records arriving from outreach
• Developed team leads able to discuss system exceptions with clinical and service owners
• Separated technical transmission checks from decisions about the meaning of disputed entries

Decisions in context

I joined Fervali because the role placed the relationship between systems and professional work at its centre. The company had two centres and 160 employees at entry, with ₹31 crore revenue in FY 2018. I led eleven IT colleagues through two team leads, reporting to the chief operating officer. Scheduled outreach introduced a different rhythm from a permanent centre: connectivity could be interrupted, records could arrive later and the person able to interpret an entry might not be beside the technician handling it. I worked on making those handoffs visible rather than assuming a successful transfer completed every responsibility. I also learned to lead through team leads who could ask useful questions of service owners without presenting themselves as clinical decision makers. The later CIO appointment extended this approach into spending priorities, supplier relationships and the account presented to the board.

Reason for the move

Promoted to CIO as the centre network and technology remit expanded

Mandate

Develop a small IT function with clear supplier, access and continuity responsibilities

Outcomes

• Introduced named internal responsibility for recurring supplier tasks
• Brought service owners into continuity discussions
• Developed support colleagues into more independent problem owners

Decisions in context

My promotion followed the completion of a part-time information-management diploma, but the practical transition was learning to lead a function rather than solve every issue myself. Vorsheli had three centres and 150 employees. I managed seven colleagues and ₹1.1 crore annual IT operating expense, with ₹32 lakh approved capital expenditure. Supplier relationships became more prominent in my work. I learned that buying support did not transfer every responsibility for deciding when access was appropriate or what a recovered service should provide. The company needed internal owners who understood the reason for a supplier's work and could review it as circumstances changed. I also brought service colleagues into continuity conversations so that technical priorities reflected the tasks they needed to resume. Fervali later offered a chance to apply these lessons across centre and outreach settings in a more specialised service business.

Reason for the move

Joined Fervali to work across a wider regional clinical-support systems remit

Mandate

Support administrative systems and clarify ownership of record discrepancies

Outcomes

• Built working relationships across reception, accounts and clinical teams
• Documented responsibility for resolving disputed administrative entries
• Completed a part-time postgraduate diploma in November 2013

Decisions in context

Moving into a care-service company changed the questions I asked about a system error. I supported two outpatient centres with two colleagues and a ₹24 lakh annual allocation, reporting to the operations manager. The company employed ninety people at entry and recorded ₹12 crore revenue in FY 2009. A mismatch could arise from administration, a changed circumstance or a professional decision that the technical record did not explain. I learned not to treat every inconsistent field as permission for IT to choose the answer. Instead, I helped identify who understood the event and could authorise the correction. I completed a part-time postgraduate diploma at Arelvi Information Institute in November 2013 while remaining employed. The combination of study and daily service work prepared me for management, particularly the need to establish ownership and useful evidence rather than rely on personal familiarity with every case.

Reason for the move

Promoted to IT manager

Mandate

Investigate user-reported faults and support administrative applications under technical supervision

Outcomes

• Learned to reconstruct the user's task before changing code
• Documented reproducible faults for review by the development lead
• Developed an interest in the operational meaning of application results

Decisions in context

I joined Pernathi in July 2005, two months after completing my computing degree. The business had thirty-four employees and a six-person support group in which I worked without independent budget or hiring authority. We supported administrative software for regional service businesses. A user's description of a fault was often the beginning of an investigation rather than a complete specification of the problem. I learned to reconstruct the task, record the sequence and ask the development lead to review a proposed change. Sometimes the application behaved as written while the result did not serve the user's actual purpose. That distinction interested me more as my experience grew. I wanted to understand the operating context that surrounded the software, so I moved to Vorsheli rather than remain exclusively within a supplier's development and support environment.

Reason for the move

Moved into a service organisation to understand systems from the operating side