What happened

Reuters published an investigation on 26 August 2026 into Meta’s Project OT restructuring plans. The company confirmed that scenario exercises had considered substantial reductions in some teams, alongside redeployments and other changes. That was not a plan to dismiss 60% of its entire workforce.

The report also described an uneven productivity picture. Internal posts reviewed by Reuters showed code changes rising much faster than changes delivering new or improved features to users. Meta had cancelled planning for a second restructuring wave, although Reuters could not establish exactly what prompted the change.

These findings warrant careful attribution. They are not a controlled experiment proving that AI caused every reported difficulty.

Why it matters

The management issue is the distance between activity and useful work. More code, presentations, messages or proposals can be valuable, but none is automatically an improvement for a customer or colleague.

A team introducing AI should decide what a completed outcome means before measuring how quickly it produces intermediate material. For software, that could include a useful feature operating reliably. For marketing, it could be an approved campaign reaching the right audience with accurate claims. For service, it could be a resolved customer problem.

I would place the production measure beside the acceptance measure. How much material was generated? How much was used? How much required correction? What changed for the intended recipient?

That comparison makes hidden work easier to discuss. It also protects teams from being rewarded for volume while someone else absorbs the consequences.

The bigger shift

AI can change the distribution of work within a process. Drafting may become faster while verification becomes the constraint. A manager who cuts review capacity because generation improved may remove the very capability needed to make the new process reliable.

Before changing team structures, map the full sequence. Identify who detects errors, supplies missing context and deals with exceptions. Ask those people to help design the trial and record the work that the usual dashboard misses.

Use a balanced set of measures: accepted output, quality, elapsed time, rework and total operating effort. Add a relevant customer outcome where possible. Avoid combining them into a single score so quickly that a deterioration becomes invisible.

A project should also have a stopping condition for unacceptable errors or an unmanageable review burden. These are practical elements of AI strategy, not obstacles to adopting useful technology.

My take

I would be cautious about making permanent organisational commitments from a short burst of impressive output.

Run the proposed process through representative demand, including awkward cases. Ask reviewers how much work has moved to them. Check whether the people responsible for exceptions have enough time and authority to handle them.

If the numbers show more activity but little improvement in accepted outcomes, investigate the workflow before asking the team to generate even more. The constraint may be unclear requirements, poor source information or insufficient review.

The useful ambition is better work reaching its intended recipient with less wasted effort. A production dashboard can help explain how that happens. It cannot replace the judgement about whether the business is actually better off.