Building New Enterprise Functions Requires Zero-to-One Operators

Building a new function and scaling an established one are different leadership assignments. Both require management skill, but the first also requires someone who can define the technical foundation, hiring sequence, operating model, and initial delivery path without inheriting a working system.

Many enterprise role descriptions emphasize the steady-state responsibilities of the future organization: team size, budget ownership, delivery metrics, and operating cadence. Those are reasonable requirements once the function exists. They do not necessarily reveal whether a candidate has built the foundation those responsibilities depend on.

The two jobs are not the same job

A manager inheriting an existing team inherits a hiring pipeline, a technical foundation, an onboarding process, and a baseline of institutional knowledge about how work gets done. The job is to improve on what's there: better process, better prioritization, better people in the right seats. This is real, difficult work, and it is a different job from the one that comes before it.

Building a function from zero means there may be no hiring pipeline, technical baseline, onboarding process, or established division of responsibility. The early team has to deliver useful work while building the system that will support later hires. That combination is what makes the assignment different.

What this looked like at RBC

In 2016, RBC's personal online banking and omnichannel front-end function had two engineers and no dedicated organization behind them. Within eight months, that function had twenty people, a hiring and onboarding process built from scratch, and a reusable front-end framework supporting eighteen concurrent digital banking initiatives serving more than 10 million active users.

The eight-month timeline did not happen because hiring sped up while the technical work waited, or because the technical foundation got built first and hiring followed. Both had to happen at the same time, by design, because waiting for one to finish before starting the other would have meant the new hires had nothing functional to join, or the technical foundation got built by a team too small to maintain it. That simultaneity is the actual content of zero-to-one work. It is not "do the manager job, but faster." It is a structurally different kind of execution, where the org chart and the technical architecture are being designed in the same sprint.

This pattern appears when an organization establishes a platform team, accessibility function, AI integration group, or another capability without an existing internal model. The domain changes, but the need to coordinate people, architecture, governance, and delivery remains.

For the full case study on this RBC engagement, see RBC digital banking platform.

Why this distinction matters for hiring, specifically

A Director of Engineering role may reasonably ask for team leadership, budget ownership, and a record of improving delivery metrics. For a new function, the process should also test whether the candidate has built a hiring pipeline and technical foundation simultaneously.

Without that experience, leaders may sequence the work too rigidly: hire the organization before its technical direction is clear, or build the foundation with a team too small to sustain it. A zero-to-one operator knows when those tracks need to advance together.

This is not a claim that managers as a category lack this skill. Plenty of managers have built functions from zero earlier in their careers and carry that capability forward. The point is narrower: the skill is distinct enough that it should be screened for explicitly, the way technical depth or domain expertise already is, rather than assumed to come bundled with general management experience.

What enterprises building something new should actually look for

The useful question is not only, "Have you managed a team of this size?" It is also, "Have you built the team and technical foundation at the same time, with little or nothing to inherit?" The evidence should include the initial decisions, what changed during execution, and what the organization could operate after the build-out.

This is a capability Lab829 brings to organizations building a function that does not yet exist inside their walls: platform teams, AI integration functions, accessibility programs, and other mandates where organizational design and technical architecture must develop together. Review the RBC digital banking case study, explore Technology Leadership, or start a conversation with us.