A recurring report needs updating. A campaign needs another reviewer. A new tool needs someone to maintain its connection to everything else. Each addition can sound reasonable on its own. Together, they create work that competes with the growth work they were meant to support.
The useful question is: what does this step earn us each time we perform it?
In a public post, David Senra attributes a principle to Bending Spoons cofounder Luca Ferrari: people proposing added complexity should justify it, and people should actively suggest removing existing complexity. The available account offers an operating idea, without measured evidence that applying it improves growth.
My recommendation is to turn that idea into a small, reversible process test. Start with one workflow, identify one candidate for removal, and check whether the team can deliver the same quality with less waiting or effort.
Map one workflow around its decisions
Choose a recurring workflow with a clear beginning and end: preparing a lifecycle campaign, producing a weekly acquisition report, or launching a landing-page experiment.
Write down the steps from ready-to-start through completion. For each step, record:
- The function it serves and the decision it changes.
- The person responsible for completing it.
- The active work and waiting it introduces.
- The consequence of skipping it.
- Any other step that performs the same function.
Separate active work from waiting. An approval might take minutes to perform but leave a campaign sitting in a queue. Removing it could shorten delivery without saving much hands-on effort. Both outcomes can matter, but they answer different capacity questions.
Look for recent examples of the step changing something. Did the reviewer catch an incorrect audience? Did the report cause someone to change spend? Did the handoff resolve a dependency?
A lack of recent interventions is a reason to investigate. Some valuable checks catch rare problems, so frequency alone is a poor retirement rule.
Distinguish a redundant step from a necessary function
A step is a stronger candidate for removal when its function is already covered elsewhere, its output has no current consumer, or the condition that originally required it has disappeared.
Consider a hypothetical lifecycle campaign that passes through two reviewers. If both independently check the same copy against the same brief, there may be duplication. If one checks the promise and the other checks audience exclusions, they serve different functions even if both steps are called “approval.”
Before proposing deletion, finish this sentence:
“If we remove this step, its function will be covered by ___, or will no longer be needed because ___.”
If that sentence is difficult to complete, investigate further. A slow step might need clearer inputs, a smaller scope, or a different owner. Removing it may simply push its work onto someone else.
Write a removal proposal someone can evaluate
Keep the proposal short enough to discuss alongside the workflow itself. Include the candidate step, evidence of redundancy, expected benefit, eligible work, owner, and reversal condition.
For example, a team could propose removing a second internal approval from routine lifecycle campaigns that use established templates and unchanged targeting rules. Campaigns introducing new audience logic would remain outside the test.
That is a proposed scope, not a universal definition of low risk. The team needs to establish eligibility from the actual function of its checks.
State the expected benefit precisely. “Shorter time from completed brief to launch” is testable. “A more agile growth team” leaves too much room for interpretation.
Also name where displaced work might appear. If the campaign owner must perform an extra manual check after the approval disappears, include that effort in the assessment.
Test one removal with quality intact
For the approval example, the hypothesis is straightforward: removing a duplicate approval reduces time to launch without an unacceptable increase in errors or rework.
Keep the test narrow:
- Define eligible campaigns before assigning them to a workflow.
- Where volume permits, randomly assign eligible campaigns to the current process or the process without the approval.
- Balance campaign complexity across the groups so difficult work does not concentrate in one group.
- Set the observation period, meaningful time improvement, and acceptable error and rework levels in advance.
- Keep consent, targeting, and tracking checks in place, with a clear path to restore the removed approval.
Use median elapsed time from completed brief to launch as the primary delivery measure. Define what makes a brief complete so the starting point does not shift during the test. Inspect unusually delayed campaigns too; the median can conceal a troublesome queue.
Record rework and material customer-facing errors consistently in both workflows. Stop and investigate a material error rather than waiting for the observation period to end.
Shared reviewers can complicate the comparison. Removing approvals from some campaigns may free capacity and accelerate the remaining campaigns too. That spillover makes the groups less independent and should temper the conclusion.
With very little campaign volume, a monitored pilot may be more practical than a randomized comparison. Treat it as limited operational evidence. A few uneventful launches cannot establish that rare failures are equally likely under both processes.
Decide what the result actually supports
Faster delivery with acceptable quality can support retiring the approval within the tested scope. It does not establish that every approval should disappear.
Faster delivery with more rework suggests that useful work moved downstream. Count the repair effort before claiming a capacity improvement.
Little change in delivery time may mean the approval was not the main source of delay. The next investigation might concern brief quality, production capacity, or another queue.
Even a successful removal does not demonstrate incremental revenue. Delivery speed is an operational outcome. Whether the released capacity produces better experiments, stronger retention, or more revenue requires separate evidence.
Give new complexity a review date
Apply the same scrutiny to additions. A proposal for a new report, tool, approval, or process should explain its expected benefit, recurring maintenance burden, owner, and retirement condition.
Allow evidence to develop through a limited trial when appropriate. Requiring definitive proof before any addition can freeze the current process and block useful changes.
Review existing steps by the same standard. Otherwise, the team scrutinizes every new idea while inherited work continues indefinitely.
The practical discipline is to make maintenance visible and decisions reversible. A process earns its place by continuing to serve a useful function.
Evidence and limitations
The underlying principle comes from David Senra’s public post attributing remarks to Luca Ferrari about complexity at Bending Spoons. The available source account does not include independent verification of the remarks, a full interview analysis, or measured operational results.
The workflow inventory, removal proposal, and evaluation guidance here are recommendations built from that principle. The campaign example is hypothetical. No improvement in launch speed, error rates, or revenue is claimed.
This approach is best suited to bounded changes whose consequences can be observed and reversed. Where a step manages rare failures or dependencies that are poorly understood, a short test provides limited evidence for permanent removal.
Source basis
- A public post by David Senra attributing a principle of organizational simplification to Luca Ferrari at Bending Spoons.
- A proposed reversible test of redundant campaign approvals; no measured outcomes were supplied.