As Justworks expanded from a single core product into a multi-product platform — PEO, Payroll, and International — our product capabilities grew significantly.
At the same time, the product experience began to reflect that growth. With multiple entry points into Justworks, customers moving between products encountered different interfaces, workflows, and mental models of how the platform worked. Internally, teams had historically been organized around these same boundaries, which made it easier to move quickly within a product, but harder to deliver a cohesive experience across them.
That’s where One Justworks (1J) came in. It was a program that spanned nearly every function with one job: unify the platform into a single, consistent experience.
1J was as much a test of how we operated as it was a product initiative. As we launched the program, our Technology organization was simultaneously shifting toward a more integrated, functional model, moving away from product-aligned silos and toward a structure that required deeper cross-team collaboration.
The visible work was building a unified platform. The deeper work was learning how to operate as one organization ourselves.
This Wasn’t a Typical Program
Most programs start with a clearly defined destination. You align on scope, map the path, and execute against it.
We had a vision — a unified platform and a consistent experience. Design had translated it into an experience model: a north star view of the information architecture and experiential layers of what the new platform could become. How it would actually come to life, though, wasn’t fully defined upfront. It couldn’t be.
The reality was that the right experience would emerge through the work. Teams had to define the experience of their domain and figure out how to start moving toward the north star. How we would get there depended heavily on the teams themselves.
This work was happening across a large organization. We had roughly 350 people across engineering, product, and design, organized into mission teams: multiple small pods of about five people, each owning a specific part of the experience.
Understanding a single product area was no longer enough. Teams needed to understand how their work connected across the entire platform, and how decisions in one area impacted the broader experience.
In that context, program management took on a different role. Our job wasn’t to define every step. It was to create the conditions for teams to navigate that complexity together.
Creating Alignment Through Education
One of the biggest shifts we made was moving away from execution-heavy program management.
Traditionally, program success is measured by delivery: are teams hitting deadlines; are milestones on track?
In this program, those weren’t the most important signals. The real challenge was whether teams actually understood the problem.
Where are teams in their understanding of the problem?
Do they see the full system, or just their part of it?
Are they making tradeoffs with the broader experience in mind?
Rather than positioning program management as the driver of answers, we worked closely with functional leaders across Product, Engineering, and Design to define direction and bring that thinking into the organization.
Our role became creating forums where teams could engage with the work more deeply, bringing education into those forums instead of just status updates, identifying and coaching through unexpected complexity, and helping teams understand sequencing and tradeoffs, not just timelines.
We shifted conversations from “Why didn’t this hit the deadline?” to “What makes this harder than we expected, and how do we work through that?”
We also recognized that this wasn’t the only work teams were doing. Unification had to exist alongside existing roadmaps and priorities. Part of our role was protecting the space for meaningful progress without rigid execution patterns.
Over time, alignment didn’t come from tighter control. It came from shared understanding.
Operationalizing the Work
Once alignment was in place, the challenge shifted to execution.
We had multiple mission teams working across different product domains, all contributing to a shared outcome, with overlapping dependencies and competing priorities.
The instinct in a program of this shape is to centralize — to pull coordination into program management, stand up a weekly decision forum, route everything through a shared tracker. We made a different call. We wanted teams to coordinate directly with each other, with program management as connective tissue rather than a clearinghouse.
In practice, that meant defining ownership before work began and being specific about it. Mission teams owned their experiences end-to-end — the full customer path through their part of the product, not just the features within it. Functional leaders across Product, Engineering, and Design set direction within their disciplines and stayed accountable for their people. Program management sat between the two, translating the shared outcome into a running view of dependencies, sequencing, and progress.
The release strategy was where this structure got tested most directly. We released incrementally, and that was a deliberate choice. Holding releases until everything was unified would have slowed mission teams, delayed the new experiences we wanted in front of customers, and deferred the learning we needed to inform what came next.
So we moved — knowing that each release could temporarily add to the fragmentation we were working to undo.
That made the pace hard. Mission teams had to ensure their work was well tested inside a system that was still in motion. Our go-to-market and customer-facing teams had to carry a shifting product story to customers with enough context to keep the experience coherent. Support teams, in particular, had to stay fluent in a product they had long known well, even as it actively changed underneath them.
Sustaining that pace required coordination that didn’t bottleneck in any one place.
The same principle shaped how we handled dependencies. Our job was to make them legible, not to manage them. Who was waiting on whom, what would unblock them, what would break if sequencing changed. Once teams had that picture, they resolved most dependencies directly with each other. When escalation was needed, it was specific: a tradeoff that warranted leadership attention, not a backlog of routine coordination.
What the structure gave us was durability. A way of working that could sustain that pace of change without depending on any one person being in the middle of every decision.
The hardest part: letting go
As the program gained momentum, a different challenge emerged.
Early on, program management was deeply embedded. We drove alignment, facilitated decisions, and helped teams navigate ambiguity. That kind of involvement creates momentum, but it isn’t sustainable, and it was never the goal.
The signals that teams were ready to operate more independently arrived quietly. They weren’t announcements. They were meetings that ran themselves. Decisions that used to route through program management were now getting made inside teams. Tensions that would have escalated a few months earlier were getting resolved by the people closest to the work.
When we saw those signals, we stepped back. That sounds simple. It isn’t.
There is a pull to stay involved when stakes feel high, when a team is navigating something new, or when a familiar forum exists that you could easily keep running. The real work of this stage was recognizing that continued involvement, even when it felt productive, was holding teams back from developing their own muscle.
So we stepped out, deliberately. We also started to wind down some of the core program forums. About six months in, we stopped running a weekly standup that had been central early on. Teams had clear roadmap ownership by then, and the new product development lifecycle supported coordination on its own.
The work no longer needed a separate program cadence. It could move through the same systems as the rest of the organization.
What replaced that involvement was context. We invested more in shared language, artifacts, and operating norms, so that the decisions teams made on their own were informed by the same holistic picture that program management had always held. Our role shifted from coordinator to curator of information, sequencing, and the strategic frame teams used to interpret their work.
The goal of the program was never to stay in the middle of every decision. It was to build the structures, context, and trust that let teams move forward without us.
What Actually Changed
By the later stages of the program, the most meaningful changes weren’t just in what we shipped, but in how teams worked — a shift in instinct.
Teams thought in terms of end-to-end customer workflows rather than isolated features. They looked for gaps between systems instead of optimizing within their own. They navigated cross-product tradeoffs more naturally, with less translation from program management.
They operated with a shared understanding of the platform — the natural result of how the work was structured, not something anyone had to enforce.
Tangible improvements in the customer experience followed: faster task completion, increased engagement across workspaces, and more consistency in how customers interacted with the product.
What made these outcomes durable was the behavioral shift underneath them.
Carrying This Forward
This wasn’t a clean or linear process. A few lessons stayed with us.
What we most underestimated was the cost of behavior change. Aligning on a new way of working takes significantly longer than aligning on a roadmap, and if you pace a program as though teams will absorb the new patterns as they go, you’ll feel that cost throughout.
The hardest balance to strike is between clarity and flexibility. There are moments where more structure accelerates progress, and moments where it slows you down. Knowing which is which in real time is difficult. If there’s one learning we’d offer, it’s this: err toward adding structure slightly earlier than feels necessary. Introducing it after ambiguity has already produced confusion or competing approaches costs more than introducing it early and relaxing it later. You can, and should, adjust that structure as the program and the teams evolve.
If you’re leading a program with ambitions bigger than delivery, here’s what we’d tell you before you start:
Design for how teams operate, not just what they deliver. The way teams work is often the limiting factor. A plan that doesn’t account for it will stall before it finishes.
Principles scale. Prescriptions break. In environments with significant ambiguity, a clear set of principles gives teams a framework for decisions you can’t anticipate. Detailed instructions fall apart the moment context shifts.
Make centralized coordination unnecessary over time. Early involvement creates momentum. Stepping back, deliberately and with clear replacement structures, is what lets that momentum sustain.
Measure the capacity you leave behind. What gets shipped matters. What lives on in how teams work matters more.
For program leaders, that last one is the hardest standard and the more meaningful one. The success that ships on your watch is visible. The success that keeps working after you step back is earned through intentional, disciplined choices: building systems instead of dependencies, transferring context instead of holding it, and stepping out of decisions you could easily stay in.
The platform known as One Justworks was built by Engineering, Product, and Design. The One Justworks that rewired how we operate together — the one we were quietly building all along — is what will carry this work forward across the entire company.
That’s what designing a program to outlive you really means.
Do you want to build products that help entrepreneurs and small businesses grow with confidence? We’re hiring across our Technology teams. Come build with us! Check out our Careers page.
