A developer's questions, an expanding engineering remit

Mandate

Make the bank's software estate understandable, changeable and supportable across generations of engineering ownership.

Outcomes

• Moved seventy of seventy-two examined consumers to compatibility with a new response while retaining two older contracts
• Established traceable build accounts for thirty-four of thirty-six reviewed release artefacts
• Resolved sixty of seventy-two synthetic calculation disagreements, leaving twelve explicitly held
• Confined the tested consequence of a dependency stall to three directly dependent services rather than fourteen

Decisions in context

I report to Leona Wexmere and lead the engineering and maintenance responsibilities within the CTO remit. My authority is USD62 million for 2026; the bank's assets, loans and deposits describe the enterprise rather than a balance sheet I manage. I have concentrated on software boundaries that can become invisible in a programme summary: older consumers, incomplete build histories, calculation conventions and shared execution resources. Martin Orvell and the operating organisation retain their banking responsibilities. I want them to receive an engineering account that explains both demonstrated progress and unresolved decisions. Since July 2023 I have also served as a non-executive director of Averlisle Learning. That separately authorised adult-learning appointment has twelve annual days allocated and is concurrent with this executive role. It does not confer a bank board seat. Any additional external commitment would be examined alongside both responsibilities before I agreed to it.

Reason for the move

Current executive role; open to a carefully assessed additional governance contribution.

Concurrent appointment

Concurrent non-executive directorship of Averlisle Learning from July 2023, separately authorised and allocated twelve annual days; no bank director appointment.

Mandate

Connect application delivery, shared architecture and continuing maintenance in one accountable engineering portfolio.

Outcomes

• Brought twenty-four application services into a common engineering ownership inventory
• Introduced joint change reviews across five application and platform teams
• Established dated support decisions for six legacy components rather than treating retirement as an assumed saving

Decisions in context

The director role connected delivery programmes with the engineering obligations they left behind. I reported to the CTO and led a team that reached 112 employees through five direct reports. My final-year authority was USD39 million. I asked application and platform leaders to describe the continuing owner of a component, the assumptions made at its interfaces and the conditions required before it could be retired. That work was less visible than a new feature but affected whether the bank could change the service after the original team moved on. The twenty-four-service ownership inventory helped us find questions that belonged in an investment discussion rather than a later support escalation. I learnt to challenge a retirement saving when the underlying dependency had not been examined. The CTO appointment offered the opportunity to apply that discipline across the wider engineering portfolio, with a clearer obligation to explain the economics as well as the design.

Reason for the move

Promoted to CTO with bank-wide engineering and maintenance authority.

Mandate

Develop shared technical services that application teams could adopt with an intelligible support and change contract.

Outcomes

• Documented receiving-team responsibilities for fourteen shared components
• Established quarterly dependency reviews involving four engineering leads
• Separated support for three specialist build routes from the common platform account

Decisions in context

Platform engineering changed my perspective on the receiving team. A component that was elegant inside its own boundary could be difficult to use if its contract, support route or change assumptions were unclear. I reported to the engineering director and led sixty-one employees through four reports by the final year. The USD17 million authority covered my remit, while the bank's revenue, assets and branch count describe its wider scale at that date. I worked with application owners on fourteen shared components so they could understand what the platform supplied and what responsibility remained with them. Three specialist build routes stayed separately supported instead of being counted as if the common service already met their requirements. That experience shaped my later view of adoption: a shared platform should earn use through a service that fits the work. The director role followed because the same questions needed to connect application choices and continuing architecture decisions.

Reason for the move

Promoted to engineering director to combine application delivery and platform responsibilities.

Mandate

Lead application maintenance and development while connecting technical changes to their intended banking behaviour.

Outcomes

• Introduced reproducible maintenance examples across eight application modules
• Assigned a named engineering owner to each of three recurring release routes
• Built a six-person peer-review rotation within the twenty-four-person team

Decisions in context

I joined Talverin in January 2000 after developing commercial applications at Delvarion Software. Banking required me to understand the intended business behaviour before treating a calculation difference or an interface failure as a purely technical problem. I reported to the head of applications and gradually took responsibility for twenty-four engineers through three direct reports. My final-year authority was USD4.6 million. I encouraged reproducible examples because they let an operating owner examine a proposed interpretation without relying on an engineer's verbal assurance. The eight-module maintenance work also helped newer colleagues understand why an accepted behaviour existed. I did not have authority over credit decisions, deposit terms or the bank's balance sheet. The move into platform engineering came from recognising how often an application problem began at a shared boundary. I wanted responsibility for improving those common services rather than asking individual teams to rediscover their conditions repeatedly.

Reason for the move

Accepted the platform engineering remit to address dependencies shared across application teams.

Mandate

Develop and maintain business applications with reproducible explanations of their behaviour.

Outcomes

• Maintained four application modules within a nine-person development team
• Documented reproducible examples for twelve recurring support questions
• Participated in two client handovers with the continuing maintenance team

Decisions in context

I joined Delvarion in June 1992, immediately after completing my computing degree at Renswick College in May. I was a developer within a nine-person team, reporting to the development manager without direct reports or spending authority. My work on four application modules taught me to investigate the intended rule behind a reported problem before recommending a cleaner implementation. An inherited boundary condition was particularly instructive: the code existed, but the explanation for its behaviour had not travelled with it. I began retaining examples that another maintainer could reproduce and discuss with the appropriate business owner. The company's 240 employees and USD32 million revenue refer to 1999 employer scale, not resources under my authority. I left for Talverin because the management opportunity combined engineering with responsibility for colleagues and continuing service. I wanted to help a team leave behind a better explanation than the one I had sometimes inherited.

Reason for the move

Joined regional banking as an engineering manager to add people and continuing-service responsibility.