Reorganizations have a bad reputation, and most of the time they have earned it. People hear the word and brace for the worst: a shuffle of boxes on an org chart that creates uncertainty, breaks relationships, and pretends to solve a problem that nobody named out loud. I have led a few reorgs across payments and lending teams, and I have lived through several more from the inside. The ones that worked and the ones that failed did not differ much in their org charts. They differed in what the leader did during the weeks the change was actually happening.
The reorg itself is not the hard part. Drawing the new structure takes an afternoon. The hard part is the human and operational stretch between announcing the change and the moment the new shape starts producing better outcomes. That stretch is the leader's job, and it is where most of the value is either created or destroyed. This is what I have learned about doing that job well.
Name the problem before you name the structure
Every reorg should begin with a problem statement that you can say in one sentence without using the word reorg. "Our payments and risk teams keep shipping incompatible changes because they report up separate chains and only reconcile at release." "We have three teams owning fragments of the ledger and nobody owns the whole." If you cannot state the problem that crisply, you are not ready to reorganize, because you will not be able to tell later whether it worked.
I insist on this because structure is a tool, not a goal. The org chart is downstream of the problem. When leaders skip the problem statement, they end up reorganizing to express a preference, to reward an ally, or to look decisive in front of the board. Those motives are sometimes real, but they are not problems the team can rally around, and the team can always smell the difference. People will forgive a hard change if they understand the problem it solves. They will resent an easy one if it appears to solve nothing.
The problem statement also disciplines you. Once it is written down, every design decision has to be argued against it. Does moving the data platform group under engineering rather than product actually shorten the path between a risk signal and a code change? If not, you are decorating, not solving. Write the sentence first, and let it veto your own cleverness.
Design for flow of work, not visual tidiness
A tidy org chart and an effective one are different things. The instinct is to group by function because it looks clean: all the engineers here, all the analysts there, a neat tree. But work does not flow along the lines of a clean tree. It flows along the path of a customer outcome or a regulatory obligation, and that path usually cuts across functions. The question that matters is how many handoffs and approvals a unit of value crosses before it reaches a customer, and how many of those crossings happen between people who report to different leaders.
In regulated fintech this is sharper than in most domains, because compliance, risk, and engineering have to operate as one motion rather than as a relay race with a referee in the middle. When I designed a structure around our card issuing program, the version that read well on a slide put all compliance staff in one function and all engineers in another. The version that actually worked embedded compliance partners inside the delivery teams and kept a thin functional spine for standards and career growth. It looked messier. It shipped faster and with fewer findings.
The org chart is a hypothesis about how value should flow. If you cannot trace a customer outcome through the boxes without crossing five reporting lines, you have drawn a picture, not a machine.
Be explicit about what is not changing
During a reorg, people overestimate the scope of the change. They assume their project is cancelled, their manager is leaving, their roadmap is void, their on-call rotation is dissolving. Anxiety fills every gap you leave open, and it fills it with the worst available interpretation. One of the most calming and underrated things a leader can do is publish, in plain language, the list of things that are staying exactly as they are.
I keep a short stability list and I share it at the same moment I share the change. It usually covers things like:
- The current quarter's commitments and their owners remain in place; nothing in flight is being dropped.
- Compensation and titles are not affected by this structural change.
- On-call coverage and incident ownership continue without interruption during the transition.
- Existing one-on-one relationships continue until any manager change is individually confirmed in person.
This list costs nothing to write and it removes a surprising amount of fear. It also forces honesty: if you cannot promise that compensation is unaffected, you need to know that before you announce, because the worst thing you can do is reassure people and then reverse it two weeks later. Every promise on the stability list is a debt you are choosing to take on deliberately.
Communicate two or three times more than feels necessary
The single most common failure mode I see is under-communication driven by the leader's own discomfort. You explain the change once, in a thorough all-hands, and you feel like you have been exhaustive. The team heard maybe a third of it, filtered through their own concerns, and within forty-eight hours the rumor mill has rewritten the rest. What felt to you like repetition would feel to them like the first time they truly understood it.
I plan communication in layers. There is the written announcement that anyone can re-read when their anxiety spikes at eleven at night. There is the live session for questions, where the unscripted answers carry more weight than the prepared ones. There are the small-group and individual conversations where people will say things they would never say in a room of forty. And there is the steady drumbeat of follow-ups in the weeks after, because the questions that matter most often surface only once people have tried to live inside the new structure for a while.
The tone matters as much as the frequency. I try to be specific about what I know, honest about what I do not yet know, and clear about when I will know it. "I don't have the answer to that yet, and I expect to by Friday" is far more trustworthy than a confident improvisation that turns out to be wrong. Trust during a reorg is built almost entirely out of small predictions that come true.
Protect the people whose roles change most
A reorg is never evenly distributed. Most people experience a slightly different reporting line and carry on. A smaller number experience something genuinely hard: a manager who loses their team, a senior engineer whose scope shrinks, a person whose role no longer obviously exists in the new shape. These are the people who deserve the most of your time, and they are precisely the people leaders tend to avoid because the conversations are uncomfortable.
I make a rule for myself that the hardest individual conversations happen before the public announcement, in person where possible, and never by being told the same time as everyone else. Someone losing direct reports should hear it from me directly, framed honestly, with a real conversation about what their path forward looks like. Sometimes that path is a strong individual-contributor track, sometimes it is a different kind of leadership, and sometimes the honest answer is that the new structure does not have a good seat for them and we need to talk about that openly rather than letting them discover it by reading a chart.
How you treat the most affected people during a reorg is watched closely by everyone else, even the people who are barely affected. They are calibrating how the organization behaves under pressure, and whether dignity survives a structural change. If the people who lose something are handled with care and candor, the rest of the team relaxes. If they are handled carelessly, everyone quietly updates their assumptions about how they themselves will be treated when their turn comes.
Keep the lights on while you change the wiring
It is tempting to treat the reorg as a project that pauses normal work, but you do not get that luxury when you are running payment rails or a lending platform. Money still has to move, settlements still have to clear, and an incident at two in the morning does not care that the on-call rotation is mid-reshuffle. One of the leader's jobs is to make sure the operational floor never falls out while the structure above it is being rebuilt.
I treat continuity as a first-class deliverable of the reorg, not an afterthought. Before any reporting line changes, I confirm explicitly who owns each production system, each compliance obligation, and each customer commitment during the transition window, and I write it down where people can see it. Ambiguity about ownership is the thing that turns a routine incident into a serious one, because in the gap between the old structure and the new, everyone assumes someone else has it. The reorg is the moment that gap is widest, so it is the moment to be most explicit.
It also helps to slow the structural change down to the speed the operation can absorb. You can announce the new shape on a single day, but you do not have to migrate every team, tool, and process simultaneously. Sequencing the transitions so that no two critical systems change hands in the same week is unglamorous and it is exactly the kind of judgment that separates a reorg that holds from one that wobbles.
Hold the line against premature second-guessing
Every reorg goes through a trough. A few weeks in, the new structure has all the friction of being new and none of the benefits of being settled, and the early data looks worse than the old way. This is the moment leaders panic and start tinkering, adjusting reporting lines, walking back decisions, adding exceptions. Each adjustment feels responsive, but together they signal that the structure is provisional, and a structure that everyone believes is provisional cannot do its job, because nobody commits to a shape they expect to be revised next month.
I try to decide in advance how long I will let the new structure run before I judge it, and what the judgment will actually be based on. Usually that is a quarter, measured against the original problem statement rather than against the discomfort of the transition. Discomfort is not evidence. People feeling unsettled in week three tells you that change is hard, which you already knew. It does not tell you whether the design was wrong. Separating those two signals is one of the more difficult disciplines of leadership, and it is mostly a matter of refusing to act on the loudest feedback in the noisiest week.
This is not stubbornness. If the structure is genuinely broken in a way the problem statement can detect, you change it. But you owe the team the difference between a real design flaw and the ordinary turbulence of transition, and you should be the calmest person in the room about telling them apart.
Close the loop and declare it done
Reorgs that drift without ever ending are corrosive, because the organization never gets to exhale. At some point the leader has to stand up and say that the transition is complete, the new structure is the structure, and we are now operating rather than reorganizing. That declaration matters psychologically even more than operationally. It tells people they can stop watching the org chart and start investing in their teams again, planting the kind of long-term roots that nobody puts down while they think the ground might move.
When I close a reorg, I go back to the original problem statement and report honestly on whether we moved it. Sometimes the answer is a clear yes, the handoffs are shorter and the findings are down. Sometimes it is partial, and I say so, naming the part that worked and the part that did not. Either way, that retrospective is what makes the next reorg cheaper, because the organization builds a memory that change can be done well and judged honestly rather than imposed and then quietly forgotten.
Conclusion
The leader's job during a reorg is not to draw the best chart. It is to carry the organization across the gap between the old shape and the new one without losing trust, dropping the operation, or abandoning the people the change costs the most. That means naming the real problem, designing for how work actually flows, over-communicating, protecting the most affected, keeping delivery alive, holding the line through the trough, and finally declaring the change complete and judging it against the problem you set out to solve. Do those things and the new structure has a chance to deliver what you hoped. Skip them and you will have a tidier chart and a more tired team, which is the worst trade in leadership.