How I lead

What I believe

I believe that a well-run operations organization should be deliberately boring. Too many organizations celebrate heroics, firefighting, and the people who repeatedly save the day. I see those as potential indicators of systemic failure, not operational excellence.

The real measure of operational maturity is how reliably the organization functions without extraordinary intervention. If the same people are constantly saving production, we haven't built resilience. We've built dependencies.

My job as a leader is to make those heroics unnecessary through clear ownership, disciplined change management, meaningful problem management, and accountability for eliminating recurring failures.

My measure of success isn't how well the team fights fires. It's how many fires we've made unnecessary.

One team from two silos

When I joined TMX Group, IT Operations was one team in name but split in practice: ComOps for CDS and Site2 Ops for the rest of TMX, with a single manager and one team lead for each.

After the CDS Post Trade Modernization moved the platform from mainframe to open systems, I amalgamated the two groups into one monitoring and major incident team, and the whole team began cross-training in incident management practice.

Moving incident leadership from one person to a team

Before I arrived, my director had been the only incident manager, handling every incident lead role and every executive update. When I joined, we split that work between us, with the aim of the team taking it on.

After the amalgamation, a third team lead was appointed to lead incident management. The leads already ran day-to-day operations for the team; incident management and incident communications were new responsibilities for them. From June 2026 the leads began handling incident communications, with support from my director and me, and they were covering them during business hours by the end. They also shadowed me on the incident lead role, which I still held, including the after-hours on-call. The plan was for the team to take over incident management fully in January 2027.

I stayed accountable for escalations and executive communications, and for developing the leads toward broader incident responsibility.

Teaching the team how the business works

I started a Lunch and Learn series so the team could learn about the departments they work with during incidents. It ran every four to six weeks, in person, and each session was presented by the technical people who ran that department, including TMX Datalinx, Network Operations and CDS Observability.

Communicating during an incident

I served as Incident Lead for P1 and P2 incidents across TMX, excluding Trayport, coordinating recovery, escalations and executive updates.

I designed and documented one incident process for every TMX business and subsidiary, including Trayport, across all severity levels. I also led the integration of ServiceNow Major Incident Management so that every incident gets its own Chat space and Meet bridge automatically.

My executive updates were concise and focused on business impact, not technical noise. They covered what was affected, the scope of the impact, what we knew, what we didn't know, actions underway, and when the next update could be expected.

Distribution included executive leadership, affected business stakeholders, and the appropriate operational and technology leadership teams. The cadence was driven by incident severity, business impact, and established communication requirements, with material developments communicated immediately.

What I refused to include was speculation presented as fact, unverified root causes, or restoration estimates that the technical teams couldn't substantiate. I'd rather tell an executive we don't have a defensible ETA than provide false confidence.

After the incident

Restoring service wasn't the end of the incident for me. The post-incident review was about understanding not only what failed, but why our existing controls didn't prevent it or contain the impact.

I focused on reconstructing the timeline, challenging assumptions, examining detection and escalation effectiveness, and identifying contributing factors beyond the immediate technical failure.

The important part was turning findings into accountable corrective actions, with ownership and follow-through through problem management and continual service improvement.

The objective wasn't to produce a polished RCA document. It was to reduce the probability or impact of recurrence. A review that doesn't result in measurable improvements is largely an administrative exercise.

Budget, vendors and people at BMO

At BMO I led 9 employees and 10 contract resources and managed an operating budget of about CAD $1.6M.

I negotiated and managed the TCS and HCL after-hours staff-augmentation contracts, with five resources per supplier under fixed-price and time-and-materials terms. I ran the renewals, resource counts, SLA and KPI reviews and performance escalations.

When a vendor wasn't performing, I focused on evidence and accountability rather than simply escalating frustration. I wanted to establish whether the issue was a missed service commitment, repeated operational failures, poor incident response, or a breakdown in ownership.

My approach was to engage the vendor's operational leadership first, establish clear expectations and corrective actions, and escalate through their management structure when performance didn't improve. Where necessary, I'd involve our internal leadership to address the broader service risk.

I don't believe outsourcing transfers accountability. The vendor may deliver the service, but we're still accountable for the business outcome.

Change and control

At TMX I raised the bar on production change: technical documentation, implementation evidence, complete procedures and accountable authorization.

At BMO I held change approval authority within my scope and owned the attestations for change approvals, operational readiness, access, segregation of duties, and vulnerability and patch controls.

When I held change approval authority at BMO, I treated approval as an operational risk decision, not an administrative formality. If a change lacked sufficient implementation evidence, a credible rollback plan, appropriate testing, or a clear understanding of production impact, I wasn't prepared to approve it simply to meet a deadline.

My position was that urgency doesn't compensate for missing evidence. The change owner needed to address the gaps before I would authorize production implementation. I've pushed back when operational or change decisions were being driven by urgency rather than demonstrated readiness, because business pressure doesn't eliminate production risk.

Where I would start in a new mandate

I'd want to understand where the organization's perception of operational health differs from reality.

In my experience, the greatest operational risks aren't necessarily the ones appearing on dashboards or risk registers. They're the conditions everyone has learned to live with: recurring incidents, undocumented dependencies, manual workarounds, unresolved problems, and critical knowledge concentrated in a handful of individuals.

I'd be particularly interested in what the people closest to production know that leadership doesn't.

My view is that operational leadership starts with understanding where the organization is more fragile than it believes itself to be. Until you understand that gap, it's difficult to make defensible decisions about priorities, investment, or transformation.