The appointments through which I learnt internal technology leadership

Mandate

Make internal working systems dependable while preserving delivery and customer decision authority.

Outcomes

• Held 240 of 960 assignment requests for correction; 205 corrected after six weeks, thirty-five unresolved.
• Introduced a common environment for 126 projects while retaining fifty-four documented exceptions.
• Restricted the next stage of a developer-tool programme after reviewing draft and rework measures together.
• Published ₹1.8 crore unclassified shared costs rather than represent a formula as observed project use.

Decisions in context

I became CIO after the company's growth-capital transaction, while its founder retained a majority. The role brought internal applications and working environments together with technology operations. I established a clearer distinction between my authority over the enabling systems and delivery leaders' authority over customer commitments. Recent decisions have tested that boundary in staffing records, development environments and tool evaluation. I have also had to explain why improved cost attribution is not itself a saving. My board exposure consists of presenting selected investment and operating matters; I do not hold a director seat. The next phase of my work concerns better evidence behind shared services and a more disciplined connection between pilot results and operating decisions. I remain accountable for continuing service alongside those changes, with the people and budget figures stated here describing my current scope rather than every year since appointment.

Reason for the move

Current position; interested in a future remit with clear operating sponsorship and an appropriately assessed external contribution.

Mandate

Support a larger distributed workforce with clear account ownership and service responsibility.

Outcomes

• Assigned business sponsors to temporary overseas-office access arrangements.
• Separated common internal support from client-specific environment obligations.
• Established a review route for exceptions instead of leaving them in individual support queues.

Decisions in context

My operations appointment exposed the limits of treating every delivery centre as a copy of the headquarters. Overseas client offices needed support at different hours and sometimes worked under restrictions that the internal team had not negotiated. I asked for the responsibility behind an exception before deciding whether it could be removed. I also required a named sponsor and review point so that justified variation did not become forgotten variation. The role developed my ability to explain support cost without implying that the cheapest configuration was necessarily permissible. I reported to the COO and coordinated with delivery and commercial leaders; I did not acquire their customer authority. The growth-capital transaction came at the end of this period, and the succeeding CIO appointment expanded my internal scope. I do not describe the earlier years as an investor-controlled transformation or claim results from that later ownership change.

Reason for the move

Appointed CIO to bring enterprise applications and technology operations under a broader internal remit.

Mandate

Connect people, project and finance records without concealing differences in their meaning.

Outcomes

• Documented the responsibilities behind shared project identifiers.
• Introduced joint review of mismatched people and project records.
• Required departmental agreement before presenting an interface as a completed integration.

Decisions in context

At this stage the enterprise had outgrown the informal agreements that once connected its people and project systems. Departments could use the same identifier while meaning different things by its status or start date. My team initially approached these problems as interface work. I learnt to bring the operating owners together before asking engineers to transfer the records more efficiently. That sometimes slowed a release, but it prevented the new interface from giving an unresolved disagreement the appearance of consistency. My remit covered enterprise applications and their service, not the finance policy or staffing judgement represented in them. I worked with those owners to make the boundaries visible and to establish a route for exceptions. The subsequent move into operations broadened my understanding of what happened after an application was released, including the support and access conditions that could determine whether colleagues could use it effectively.

Reason for the move

Moved into technology operations to take responsibility for the wider working environment.

Mandate

Provide reliable internal people and project administration as the delivery workforce expanded.

Outcomes

• Distinguished requested project changes from approved changes in internal records.
• Established named departmental contacts for unresolved application decisions.
• Improved release handovers so support colleagues could identify the authority behind a change.

Decisions in context

I joined the company to manage the applications its own colleagues used, rather than move into a client engagement role. It was my first substantial people-management responsibility, and I had to learn how to organise work through four direct reports instead of personally solving each issue. Urgent requests often arrived with a customer deadline attached, even when the internal action still required a separate approval. I learnt to respect that urgency without assuming it supplied the missing authority. Departmental contacts became essential because the application team could explain a technical choice but could not decide every people or project question. I also became more deliberate about release handovers: a support colleague needed to understand why a record changed, not only that a deployment had succeeded. The promotion in January 2008 followed the widening application estate and gave me a larger budget and clearer enterprise responsibility.

Reason for the move

Promoted to lead enterprise applications as the company's operating scale increased.

Mandate

Maintain dependable internal deployment and desktop setup records.

Outcomes

• Made deployment records easier for support colleagues to trace.
• Documented repeatable desktop setup steps for new joiners.
• Escalated unexplained configuration differences instead of silently normalising them.

Decisions in context

I entered this role immediately after completing my computing degree in June 1993. The work taught me that internal service depends on records which can seem unimportant beside the software being developed for a customer. A missing version reference or an unexplained setup difference could leave a colleague unable to resume work. I had no direct reports or personal budget and worked under the internal systems manager, learning from the people who received the support calls after a change. My contribution was to make the records and setup steps more dependable, not to claim ownership of the company's commercial performance. I also learnt to preserve an unexplained difference long enough for someone to assess it rather than remove it merely to make systems look consistent. After seven years I wanted responsibility for organising a team and its priorities, which led to the internal applications appointment at Rujantra.

Reason for the move

Accepted a management appointment with a larger internal applications team.