Dun & Bradstreet

Frontend modernization, system cohesion, and upstream product clarity in a high-scale enterprise environment
Dun & Bradstreet Launch
Dun & Bradstreet Launch
Dun & Bradstreet Model
Dun & Bradstreet Model
Dun & Bradstreet Campaigns
Dun & Bradstreet Campaigns

Dun & Bradstreet had recently acquired a smaller company (Lattice Engines) and was navigating a complex technical consolidation process across a sprawling set of legacy and modern frontend systems. Teams were fragmented, patterns inconsistent, and new features were being developed without a clear unifying architecture. There was a design system in place, but no one was enforcing its use–or ensuring teams even knew it existed.

As a principal frontend engineer I drove a project focused on closing systemic gaps: improving code quality, encouraging reuse, and aligning new work with long-term maintainability. This was not a top-down replatforming effort. It was a strategic, bottom-up correction of drift, technical inconsistency, and silent inefficiencies.

Architecture consolidation without a rewrite

I began by identifying areas where new frontend work was diverging from design standards or duplicating effort. I wasn't just reviewing code–I was pattern matching across projects, recognizing opportunities to extract reusable components, and flagging architectural decisions that would create friction later. My reviews weren't about nitpicking–they were focused on surfacing risk, reducing entropy, and reinforcing cohesion across autonomous teams.

This required both technical acuity and political tact. These teams weren't junior–they were smart, fast-moving, and overloaded. The problem wasn't skill. It was structure. My job was to help them see how their local choices created global drag.

Embedded upstream to shape the future

I became the primary frontend contributor on the project designed to surface and address these issues more directly as well as an interrelated backlog project with strategic intent: surfacing misaligned work, extracting reusable logic, and identifying common anti-patterns. This wasn't just cleanup–it was active shaping of how the system would scale.

Alongside that, I was invited into upstream product meetings–early planning sessions with product leadership, design leads, and executives. I acted as a frontend strategist, helping frame technical possibilities, constraints, and consequences before a single line of code was written.

This level of involvement wasn't formalized with a title change–but functionally, I was acting as an embedded systems lead: part architect, part translator, part reviewer-of-last-resort.

Outcomes

  • Reduced duplication by flagging opportunities for component extraction during code review
  • Increased conformance to the design system without enforcement mandates
  • Helped teams make technically sound decisions that scaled beyond their immediate context
  • Advised upstream on product and design tradeoffs, improving alignment between intent and implementation
  • Initiated a cross-team practice of surfacing reusable work and reviewing code not just for quality, but for system-level clarity

This role exemplifies what I bring to large, fast-moving orgs: structural awareness, contextual humility, and the ability to align tactical work with strategic outcomes–without slowing teams down or creating top-down bottlenecks.