The Efficiency Multiplier

Put yourself in that engineer’s chair. You’re expected to keep shipping while teaching newcomers how the system works. If every change needs your judgment, you can get faster at answering questions and still remain the person everyone waits for. The staffing proposal has to explain how that changes.

The work that disappears

Consider a proposed shared document editor. Two people can edit the same sentence, and someone can keep editing while offline. WebSocket supplies a two-way connection between browsers and a server. Getting both versions to the server still leaves a decision about how to combine them when that person reconnects.

Yjs provides shared data structures that merge concurrent updates, with separate editor integrations and networking modules. Its documentation makes the condition explicit: all changes must eventually arrive for the documents to sync. If its behavior fits your product, the team can integrate that machinery rather than design its own merge algorithm. You still have to decide who can edit, how documents are stored, and what happens when a connection drops.

The gain here comes from changing what the team owns. A completed synchronization ticket is visible. The decision to stop developing your own merge algorithm is harder to count, even though it removes that implementation from the plan. That’s the useful meaning of an efficiency multiplier: one decision changes the work for everyone who follows it.

Custom code can be the simpler choice, too. In Figma’s 2019 account of its multiplayer system, Evan Wallace describes using a central server to simplify the rules for keeping documents consistent. Figma could avoid complexity needed for a fully decentralized system. The team explored collaborative algorithms in a prototype before integrating its approach into the product.

Figma also made a tradeoff a shared text editor might reject. Wallace explains that simultaneous changes to the same text value resolve to one user’s whole value, rather than merging the edits inside it. Figma accepted that behavior for its design tool. If your shared editor must combine those edits, copying that rule would shorten the plan by dropping behavior you promised.

Show what the team can stop doing

A senior hire’s promised savings deserve the same scrutiny as a headcount request. Ask what responsibility the team could stop owning, and what it would take on instead.

For the editor, run concurrent edits to the same sentence, changes made offline, and recovery after reconnecting. Decide what the resulting document should contain before running those cases. Everyone seeing the same document is only part of the test; they could all be seeing a result your product shouldn’t accept.

Then put the old implementation plan beside the proposed one. Removing the custom merge algorithm still leaves editor integration, storage and access control; adopting Yjs also means keeping up with that dependency. Assign that work before claiming a staffing saving. You may have made the editor easier to build without freeing anyone to build the next feature.

The same reasoning applies to work already in the codebase. Martin Fowler describes technical debt as extra effort imposed on future changes by deficiencies in internal quality. He argues for leaving painful code alone when it doesn’t need to change, and warns that estimates of cleanup costs and savings are imprecise. Applied to your roadmap, that suggests tracing blocked features to specific dependencies before funding a general cleanup.

If every feature requires changing the same fragile module, adding implementers leaves that repeated work in place. Improving the module could reduce it, but the improvement has to survive an ordinary feature change by someone other than its author. Otherwise, you may have exchanged a difficult system for dependence on the person who understands the new one.

Senior judgment has to become usable

Will Larson describes a form of staff engineering work in which an experienced engineer helps a colleague reshape a project into something finishable, then uses their organizational influence to clear obstacles. The colleague remains the person doing the work.

That’s a more useful hiring target than finding someone who can personally answer every hard question. If only your new staff engineer can review each change, work still depends on one person’s availability. A useful handoff leaves colleagues able to implement and review ordinary changes within the design. Work that warrants specialist review should still get it.

Start with the people already on the team. If someone understands the constraint but spends their time answering questions and clearing tickets, give them room and authority to address it. Hiring can help by taking work off their plate. If the team genuinely lacks the experience needed to resolve the constraint, recruit for that specific responsibility.

And if the design is sound, the work can be owned independently, and the team can support newcomers, additional implementers are a sensible choice. Developing less-experienced engineers is part of building that capacity. A staff title supplies no guarantee that its holder will choose a simpler solution or help colleagues grow.

What saying it out loud costs

Revisiting an approved hiring plan means reopening a decision the board thought it had settled. If you made the original request, you have to own the assumptions behind it. The uncomfortable ask may be to take feature work away from an engineer whose output the board trusts so they can resolve the dependency holding everyone else up.

That requires a change in what you’re willing to reward. If the engineer validates an existing collaboration library and removes the custom merge algorithm from the plan, their contribution includes the tickets you no longer need to assign. Asking for that judgment while rewarding only completed tickets works against the decision you’re trying to fund.

Before you approve the roles, ask what the existing team could own after the dependency is resolved, and what would still be waiting for an owner. If the remaining work is useful, independent work the team has no capacity to take on, hire the three.