Fred Lackey

Two Engagements. One Company. Six Years.

Travelers Insurance is not a startup. It is one of the largest property casualty insurers in the United States — a company where software sits beneath billions of dollars in underwriting decisions, claims processing, and risk assessment. Working inside an organization at that scale means operating in an environment where every architectural choice carries institutional weight, and where a tool that proves itself in one corner of the enterprise can spread to every other corner without anyone asking permission.

The six-year engagement with Travelers unfolded in two distinct phases: first as an outside consultant embedded in the Customer Value Stream, then as a direct hire brought in to lead the company’s BSI Construction business segment engineering organization. The two phases were related but structurally different — and the most interesting story spans the transition between them.

The First Act

The first engagement began in 2018 as a consultant embedded in Travelers’ Customer Value Stream organization. The environment was a mixed-generation technology stack — PCF (Pivotal Cloud Foundry) for deployment, Jenkins and IBM UrbanCode Deploy for CI/CD, legacy AngularJS frontends alongside newer React applications, and a data layer that reached from SQL Server and DB2 all the way back to IBM mainframes.

The initial scope included a migration effort, moving AngularJS applications to React, and feature development on the BIFNOL application — a Business Insurance First Notice of Loss system built in ReactJS. The work was technically routine for an engineer at this level: the environment was complex, but the task of moving a well-understood frontend framework to a better one is a known problem with known solutions.

What was not routine was what happened next.

BIFNOL — Business Insurance First Notice of Loss

BIFNOL was a claims intake application for commercial insurance customers reporting first notice of a loss event. The system connected ReactJS on the frontend to a backend data layer spanning SQL Server, DB2, and IBM mainframe records — the layered reality of enterprise systems that were built in multiple decades and never fully consolidated. The work involved understanding that full data topology, not just the green-field React layer on top of it.

The Proxy That Went Everywhere

Within the consulting engagement, a need emerged that no existing Travelers tooling addressed cleanly: a lightweight, configurable messaging proxy that could sit between services and handle translation, routing, and protocol bridging without requiring each team to solve the same integration problem independently.

The proxy was built in Node.js with Express and Redis. It was not designed to become an enterprise standard. It was designed to solve a specific problem for a specific team. The architecture was clean, the performance was strong, and the abstraction was general enough that other teams could adopt it without modification.

That is what happened. The proxy spread laterally across the Travelers engineering organization, adopted by team after team as they encountered the same integration challenges it had been built to address. By the time the consulting engagement transitioned into a direct hire, the proxy was no longer one team’s tool — it was enterprise infrastructure.

This is the kind of outcome that distinguishes solutions built on genuine architectural thinking from solutions built to satisfy a ticket. The proxy worked because its design was rooted in understanding the problem space at an enterprise scale, even when the immediate scope was a single team. It was built to last.

Director of Engineering — BSI Construction

The return in 2022 was a different kind of engagement. As a direct hire into the BSI Construction segment, the role expanded from individual technical contributor to leading six engineering teams simultaneously — three onshore, three offshore — within a SAFe Agile delivery framework. The mandate was not just to build software but to build the organization that builds software.

BSI Construction is Travelers’ commercial construction insurance business segment. The systems that support it handle underwriting decisions, policy management, and risk assessment for a specialized and technically demanding insurance category. The engineering teams responsible for those systems needed leadership, architectural direction, and a flagship platform to anchor the segment’s modernization strategy.

Managing six teams across time zones and organizational layers requires a different discipline than managing one. The technical work does not stop — architectural decisions still need to be made and reviewed — but it becomes embedded in a broader practice of team health, stakeholder alignment, delivery rhythm, and cross-team dependency management. The role demanded both.

Underwriting Canvas

Underwriting Canvas was the flagship product of the BSI Construction engineering organization — the platform that underwriters used to evaluate, structure, and bind commercial construction insurance policies. Building it right meant designing a modern, cloud-native application on top of a data model that spanned decades of commercial insurance history.

The platform included several supporting applications alongside the core Underwriting Canvas: an AFST (Agent Financial Summary Tool) for financial modeling within the underwriting workflow, an Electronic File Cabinet for policy document management, and a Globalization Pipeline that managed content localization across market-facing surfaces. Each was built as a discrete service within the same platform ecosystem rather than as a standalone system, ensuring that the underwriting workflow remained coherent end to end.

From PCF to AWS

The infrastructure inherited in Phase 2 was Pivotal Cloud Foundry — an enterprise PaaS that had served the Travelers engineering organization through the previous decade but was increasingly difficult to justify against the capabilities and economics of native AWS. The migration was not a flag-day cutover. It was a phased, hybrid-state transition that required the BSI Construction systems to operate across both environments simultaneously for an extended period.

Moving from PCF to AWS required re-thinking deployment pipelines, secrets management, networking topology, and monitoring strategy. Terraform provided the infrastructure-as-code layer that made the migration tractable: every resource definition was versioned, reviewable, and repeatable, eliminating the configuration drift that had accumulated in the PCF era.

The hybrid migration period was intentionally managed rather than rushed. Teams continued shipping product features throughout the transition. The migration was treated as infrastructure work that ran in parallel with product delivery rather than as a prerequisite that blocked it. That decision — to migrate while still delivering — required strong cross-team coordination and a shared understanding of which systems were in which state at any given moment.

Six Years, Two Eras

The technology environment at Travelers evolved significantly across the six-year engagement — partly driven by industry-wide trends and partly by deliberate modernization decisions made within the BSI Construction segment. The two phases had meaningfully different stacks.

Stack & Craft