Interim Chief Technology Officer — Payment Switch Resilience

The mandate

Three peak-hour switch interruptions in one quarter exposed shared failure modes in routing, database capacity and release rollback, leading to the CTO's departure. Services have been restored, but incident actions are fragmented and the festive transaction peak arrives before normal succession can conclude.

The interim must start inside two weeks for a nine-month period covering peak readiness, architecture remediation and two independent resilience exercises. Permanent recruitment begins once the first load test clears; an extension may cover up to six weeks of successor notice.

The assignment ends after the switch sustains agreed peak headroom, change-failure and recovery measures for ninety days, both region-loss exercises pass, severe incident actions close, and the permanent CTO accepts the architecture risk ledger. Temporary over-provisioning alone does not meet the exit test.

The interim may freeze releases, choose remediation sequencing, invoke supplier remedies and move ₹18 crore inside the approved reliability portfolio. A platform rewrite, new cloud region, supplier exit over ₹40 crore, material SLA change and permanent vice-president appointments require Technology Committee or board approval.

New consumer features, merchant pricing and replacement of the analytics warehouse are not included. The role will improve the transaction path and its operational dependencies without turning into a general product transformation.

Why this seat is open

The outage pattern undermined trust in technical readiness statements made by the former leadership. Existing engineering heads own competing components implicated in the failures. A neutral interim CTO can arbitrate architecture and release trade-offs before the highest-volume period.

What you will own

• Establish a single failure model linking routing, data, network, dependency and operational conditions across all three outages.
• Decide the minimum resilience backlog and terminate reliability work that does not reduce a measured failure mode.
• Set peak-load acceptance thresholds for latency, error, queue growth, failover and recovery without manual masking.
• Approve or stop every material release through the peak window using tested rollback and capacity evidence.
• Exercise complete region loss and payment-network degradation with reconciled transaction outcomes and timed decision logs.
• Enforce critical supplier actions through service credits, technical acceptance gates and documented exit alternatives.
• Transfer architecture decisions, reliability measures, open defects, vendor exposures and the next two peak plans to the successor.

Candidate qualifications

• Led CTO, engineering or technology operations for a high-throughput payments, banking or transaction platform.
• Recovered repeated production outages involving distributed systems, databases, networks and external rails.
• Personally governed peak-readiness and release-stop decisions at sustained high transaction volumes.
• Built SRE measures that connected engineering changes to customer settlement and reconciliation outcomes.
• Directed several hundred engineers across product, platform and operations with material budget control.
• Can explain complex resilience trade-offs to boards, regulators and commercial executives without hiding uncertainty.

Non-negotiables

• Available in Bengaluru within fourteen days and present through peak and exercise weekends.
• No active relationship with the switch vendor, cloud provider or primary network supplier.
• Will permit independent risk validation of resilience evidence.
• Must have held live production authority, not only architecture or programme oversight.

1. 49 words maximum. Confirm your earliest Bengaluru start and peak-period availability.
2. 49 words maximum. Describe a repeated transaction outage you eliminated and the shared failure mode you found.
3. 49 words maximum. What evidence would make you cancel a release one hour before deployment?