A finance leader at a mid-sized healthtech company is preparing for a re-org this year. The financial target is familiar. The difference is the order in which the decisions are being made.
In previous restructures, leadership set the financial target, reviewed the org structure, and looked for roles to reduce or consolidate. This year, the company is starting with the work itself.
The team is looking at the workflows the business will need over the next few years and asking how those workflows should operate differently. That includes where AI can take on part of the work and where older processes still carry handoffs or coordination that may no longer be necessary. Only after that does leadership turn to the capabilities the future work requires and whether those capabilities already exist inside the company.
Starting with the work creates more options than starting with headcount. A process may no longer need to run in its current form. Some tasks may move to AI while others still require human judgment. The organization may still become smaller, but the structure follows the redesign rather than determining it.
A recent McKinsey article, The Operating Model Advantage, describes a similar sequence. In its survey, companies that attributed at least 5 percent of EBIT to AI were three times more likely to be pursuing broad operating-model redesign, and twice as likely to redesign workflows before selecting technology. These are correlations, not proof of cause. Still, the companies seeing more from AI were changing how the work is organized, not only which tools they bought.
McKinsey's recommended order is specific: redesign the workflow first, build the talent model second, choose the technology third.
Many companies have approached AI in the opposite direction. They introduce a tool into an existing role and look for tasks it can make faster. Productivity may improve while the surrounding process stays largely intact. The same approvals remain and the same work continues to move between teams.
AI's effect on coordination reaches further than its effect on individual tasks. It can change how information is assembled and where decisions are made, which changes how teams need to work together. The harder part is separating unnecessary friction from legitimate control. In regulated environments, some review steps exist for good reasons, and in a healthtech company a fair number of them do. Redesign means understanding which is which rather than treating every handoff as waste.
Capability becomes just as important once the workflow changes. A future-state design only works if the company knows whether it has the skills to run it. Titles are not enough. A role that looks simple to eliminate may hold knowledge that is difficult to replace, while someone in a changing role may already have capabilities that are more valuable elsewhere.
That is one reason capability data matters more during a re-org than it does in a static org chart. The goal is not a perfect inventory of employee skills. It is to answer practical questions about what the future work requires, where those capabilities already exist, and what may be lost if the structure changes.
There is also a retention issue. Re-orgs create uncertainty, and the people with the most options are often the easiest to lose. If they also hold important capabilities, protecting that capability has to be part of the redesign rather than something addressed after the structure is announced.
Five places to start
- Pick a high-value workflow, not a department. Choose an area where changing how the work gets done could have a meaningful financial or operational effect. Starting with one workflow keeps the redesign contained enough to understand and significant enough to matter.
- Take the workflow apart into tasks. Document how the work actually runs before making decisions about roles. Break the workflow into its component tasks and mark where decisions happen. In McKinsey's survey, roughly 79 percent of organizations skipped this step, though the article reports workflow redesign as the factor most strongly correlated with enterprise EBIT impact. The output is a map of how the work runs, which is usually different from how it is assumed to run.
- Decide what should move to AI and what should stay with a person. Evaluate the work task by task rather than labeling an entire job automatable. Determine where AI can perform the work, where it can assist, and where a person still needs to own the outcome. Then redesign the workflow around that division instead of adding AI to the process that already exists.
- Build the roles after the work. Once the future workflow is clear, identify the capabilities needed to run it. Then compare those requirements with what people can actually do rather than relying on titles alone. That surfaces both redeployment opportunities and capabilities that would be risky to lose, and it only works if the view of people's capabilities is current.
- Redesign the coordination around the work. Look at how information reaches decision-makers and why work moves between teams the way it does today. Where a handoff exists because information used to be slow, AI may let you remove it. Where it exists because someone must be accountable or a rule requires a review, it should stay. Telling those two apart is the work of turning a work redesign into an org redesign.
Re-orgs will still have financial targets and headcount constraints. What changes is that those constraints do not have to be the first design decision.
A company can first work out how its important work should operate, then identify the capabilities that work requires, and design the organization around it. AI is a practical reason to revisit workflows built around older constraints. For an organization already planning significant change, taking the work apart before rebuilding the organization is a reasonable place to begin.
