How to Split a 1,000-Engineer Division and Hand Over Control

By spring 2023, Alexander’s direct reports had roughly doubled from ten to twenty. The expanded remit also brought more business counterparts, separate roadmaps, and units operating on different timescales. Keeping up with one-on-ones and priority discussions meant constantly switching context. The latest problem would get his attention, while it became harder to tell where a team genuinely needed support.

Alexander had already moved mobile and API product teams into business streams responsible for areas such as lending and debit products, leaving common components with platform teams. In 2023 he faced a similar design problem across several larger units. Each unit needed a coherent set of responsibilities so it could make most decisions internally and work with its neighbors through clearer interfaces.

The five units covered client interfaces, acquisition and marketing, social platforms, the digital ecosystem, and product analytics and A/B testing. The last unit was small. It brought together tooling for instrumenting products, formulating and testing hypotheses, and interpreting the results of experiments.

The boundary between client interfaces and the digital ecosystem shows the reasoning behind the split. The first unit looked after shared web and mobile components, technical debt, performance, and reliability. The second looked after customer experiences that crossed product lines, including the home screen, profiles, authentication, authorization, and major interface updates. As scenarios such as children’s accounts and acting on another person’s behalf emerged, multiple products had a stake in how shared access rules worked.

The two units set priorities differently. Many products wanted space on the home screen. The digital ecosystem team had to weigh those requests against what customers came to do and balance promotions, notifications, and core journeys. Its business lead set those priorities directly. The same lead depended on the platform for reliable service and timely components, while the platform roadmap drew on the needs of several teams and longer-term engineering work.

All five leaders came from within the company. Some already worked in the division, and two moved from other areas. Working with a candidate gave Alexander evidence about how they handled difficult projects, made decisions independently, and reached agreement when teams had conflicting interests.

He looked for technical depth, the ability to work with difficult counterparts, and a fit with the assignment. A mature, regulated product calls for someone who can keep work predictable and meet commitments. A unit formed by merging teams needs someone who can explain changing responsibilities and help people learn to work together.

There was a separate question about whether the move could happen. How did the future business counterpart and team view the candidate? Did the role fit the candidate’s career plans? Who would take over their existing commitments? Keeping critical decisions tied to one person can make a promotion harder because the organization already depends on them in their current job.

By autumn 2023, the CTOs had been chosen. A strategy session gave them a chance to discuss their new boundaries and plans for 2024. The next phase concerned teams and existing commitments. Each new CTO met business counterparts, reviewed ongoing work, and brought observations to one-on-ones with Alexander.

In larger meetings, Alexander let the new CTO lead the discussion. If things were on track, he could listen and talk through details privately afterward. That gave the incoming lead room to reach agreements directly and earn credibility with team managers and senior engineers. Learning how the work ran before proposing manageable improvements gave those relationships time to develop.

Progress became visible when a CTO could explain who owned what, identify and rank problems, defend a proposal, and reach an agreement with the business without Alexander in the room. When someone suggested an approach he would not have chosen himself, he asked what evidence or observations led to it.

The one-on-ones gradually shifted toward exceptions. A new regulatory requirement, for instance, changed a project deadline. The options included moving people, reducing scope, or buying an existing component. Alexander recalls that the team secured funding for a component and made the deadline, then replaced it with an in-house solution later.

He also stepped in when a CTO asked for help, when a conflict escalated, or when new context could change a decision. Verbal agreements with some outside units sometimes led to different actions than expected. Alexander started keeping a record of agreements with those units so he could refer back to what each side had committed to.

By the end of 2024, the new CTOs had taken over the budgets, hiring, and approvals Alexander could delegate. Their units worked with considerable autonomy. Reliability, security, shared budgets, and alignment on goals and performance reviews still called for coordination. Alexander remained accountable for the overall result and took part when a decision needed information or authority from several sides.

In his assessment, the handover worked because the business gained technical leaders who could run their areas independently. A company-wide redesign in 2025 changed the structure again. His assessment concerns what the CTOs could take on by the end of this handover.