From six customer sites to a regional bank's technology mandate

Mandate

Connect technology strategy, delivery and service operation to explicit banking responsibilities and evidence.

Outcomes

• Compared application restart at forty-two minutes with full accounting of 12,000 test instructions after two hours and forty-six minutes.
• Funded CNY6.4m of recovery improvements; a later equivalent exercise completed in seventy-eight minutes.
• Deferred seven of twenty-seven change requests, approving CNY88m of initiatives and CNY4m contingency.
• Retained three late milestones alongside eleven completed milestones in the first-half portfolio report.

Decisions in context

I became CIO after seven years coordinating technology delivery across the bank. The appointment extended my responsibility to the connection between strategy, ongoing service and the change portfolio. I report to the CEO and present relevant matters to directors, without holding a board seat. My team now includes 164 employees, while eighty contracted specialists remain a separately described resource. I have used recovery exercises, conversion reviews and supplier demonstrations to make dependencies more visible. Those decisions have sometimes required extra expenditure or delayed features, and I retain those consequences in the account. The 2026 portfolio fits the authorised financial envelope but still contains unfinished milestones. I regard that distinction as part of credible executive reporting. An external appointment would need a separate assessment of conflicts, employer consent and the time available alongside this continuing responsibility.

Reason for the move

Current appointment; exploring a compatible external board contribution without leaving the executive remit.

Mandate

Organise delivery commitments around shared specialist capacity and business acceptance evidence.

Outcomes

• Established one dependency review across eighteen active initiatives.
• Introduced named business acceptance owners for all eighteen initiatives.
• Replanned five releases when the same specialist team appeared on conflicting schedules.

Decisions in context

The delivery role required me to negotiate across sponsors whose individual requests were often sensible but collectively exceeded available capacity. I led 110 employees through five direct reports and reported to the CIO. At appointment, the bank operated thirty-four branches and had approximately 1,850 employees; its later scale should not be read back into this period. I introduced a common dependency review for eighteen initiatives and asked sponsors to identify the people authorised to accept the business result. Five releases needed replanning because their schedules relied on the same specialists. That was an uncomfortable finding, but it was more useful before release commitments hardened further. I learnt to describe a delivery plan as a set of competing responsibilities rather than a list of independent dates. The work prepared me to connect investment choices with service operation in the subsequent CIO appointment.

Reason for the move

Promoted to CIO after leading delivery planning and business acceptance across the enterprise portfolio.

Mandate

Improve service support, infrastructure operation and recovery preparation with banking operations.

Outcomes

• Established shared recovery exercises for six important banking services.
• Added a service-owner decision record to each of the six exercise reports.
• Consolidated four separate support escalation lists into one maintained operating register.

Decisions in context

My operations appointment placed the continuing service beside the application work I already knew. I led sixty-six employees and was accountable for the operating budget under the head of technology. The bank then had twenty-one branches and 920 employees, with activity concentrated in Zhejiang. We established recovery exercises around six banking services and recorded the service owner's decisions alongside technical events. That change exposed questions that an infrastructure-only account had not addressed. I also consolidated four escalation lists so colleagues could find the current authority during an interruption. The work was practical and sometimes repetitive; its value depended on keeping the record current when people and systems changed. I learnt that recovery preparation requires an operating agreement, not just a technical procedure. The next appointment carried those lessons into the planning and acceptance of new services.

Reason for the move

Moved into technology delivery leadership as the bank's change portfolio expanded.

Mandate

Organise application support and releases around the branch activities they enabled.

Outcomes

• Created a common release record for twelve branches.
• Assigned business interpretation owners to twenty-four recurring instruction categories.
• Introduced a weekly review of unresolved application exceptions with branch operations.

Decisions in context

I joined the bank from a software supplier because I wanted responsibility for what happened after a support ticket closed. Thirty-two colleagues worked through five direct reports, and I reported to the head of technology. The bank's twelve-branch network was much smaller than today's operation. We created a shared release record and examined twenty-four recurring categories of instruction with business specialists. The exercise taught me that a technical field name could conceal an important difference in interpretation. I did not approve banking products or customer-control decisions; I organised the application work needed to implement the decisions of the responsible functions. Weekly exception discussions gave branch colleagues a way to explain recurring workarounds before another release repeated them. Progress depended as much on listening to those colleagues as on changing software. That experience supported my later move into service operations.

Reason for the move

Promoted to lead IT operations after developing the relationship between application support and branch procedures.

Mandate

Investigate application incidents and document the state of interrupted processing for customer operators.

Outcomes

• Maintained incident records for an assigned group of six customer sites.
• Documented eleven recurring interrupted-run scenarios for supervisor review.
• Helped introduce a shift-handover record across the eight-person support team.

Decisions in context

I began professional work three months after completing my computing degree. As an individual contributor, I investigated incidents and explained findings to a supervisor before changes were authorised. The eight-person team supported business applications around Hangzhou. My assigned group covered six customer sites, and I recorded eleven recurring scenarios in which a failed run left the operator uncertain about earlier processing. These were support responsibilities, not management achievements on the scale of my later appointments. They taught me to preserve evidence and ask what the person using the application still needed to establish. I helped develop a shift-handover record so the next colleague could follow an incident without restarting the investigation. Moving to Lanshu in July 1998 gave me a longer relationship with the operating consequences of application decisions and my first substantial team leadership responsibility.

Reason for the move

Joined a customer institution to follow application decisions through their continuing operating consequences.

Career interval

June 1991 graduation was followed by a normal three-month transition before my first appointment in September.