The Fastest Way to Get Approval Is to Stop Asking for It

What if the biggest mistake in organizational change is treating approval as the beginning of participation?

A leadership team can authorize a cloud cost program in an afternoon. A product team can collect hundreds of votes for a feature request in a week. Yet neither decision guarantees that anything meaningful will change. Approval can create permission, but permission alone rarely creates ownership.

The deeper pattern is this: systems improve when the people affected by a decision have a visible way to help shape, fund, or implement it. Leadership provides direction and legitimacy. Communities provide evidence and energy. Practitioners provide the difficult, unglamorous work that turns an intention into a functioning system.

This is why financial operations in the cloud and open product development, despite appearing unrelated, illuminate the same organizational truth. Both are exercises in converting distributed concern into coordinated action. Both fail when decisions remain concentrated at the top and participation is reduced to applause, voting, or compliance.

Approval starts a movement only when it changes who is responsible for making the movement real.

The approval illusion

Organizations often imagine change as a sequence with three steps: identify a problem, obtain executive approval, and execute the solution. This model is tidy, legible, and frequently wrong.

Consider a company whose cloud bill has grown dramatically. The finance team sees waste. Engineering sees the cost of reliability, experimentation, and speed. Product sees customer commitments. Security sees controls and risk. Executives see a number that threatens the plan. Each group is looking at the same expenditure through a different window.

An executive mandate may establish that cloud costs matter. It does not establish what a responsible cost looks like for a specific service, who should act when spending rises, or how tradeoffs should be made without slowing the business. Those questions live inside the operating system of the organization, not inside the approval memo.

The same illusion appears in product development. A user may passionately want a feature. They can file a request, rally other users, and demonstrate demand. This can influence a roadmap, but demand is not delivery. A vote does not design the interface, maintain the code, handle edge cases, or absorb the long term cost of supporting the feature.

In both cases, the visible decision is mistaken for the substantive work. Leaders approve a practice, or a community endorses an idea, and everyone quietly assumes implementation will follow. But implementation requires a different kind of commitment: time, technical judgment, feedback, maintenance, and willingness to make tradeoffs.

This distinction gives us a useful formula:

Impact equals authorization multiplied by participation.

If authorization is high but participation is near zero, impact remains near zero. A chief executive can approve a transformation, but cannot personally inspect every resource, rewrite every workflow, or resolve every local tradeoff. A thousand users can request a feature, but cannot collectively make a coherent product decision unless someone translates their demand into a viable design.

The point is not that leaders are unimportant, or that users should run the roadmap. The point is that each has a different type of power. Confusing those types of power is what makes many initiatives look supported while leaving them operationally empty.

Leadership is a coordination technology

Leadership is often described as the act of setting vision. In complex systems, it is more useful to see leadership as a coordination technology.

An executive does not need to understand every implementation detail of cloud financial management. They do need to clarify that cost accountability is a business responsibility, not merely a finance concern. They need to provide authority for teams to change incentives, invest in visibility, and resolve conflicts between speed, resilience, and efficiency. They also need to remain involved long enough for the new behavior to survive its first uncomfortable quarter.

This is a different role from issuing a command. A command says, “Reduce spending.” Coordination says:

• Here is why the problem matters.
• Here is how decisions will be made.
• Here is who owns each kind of action.
• Here is what tradeoff the organization is willing to accept.
• Here is how we will learn whether the system is working.

That structure matters because cloud spending is not produced by a single department. It emerges from thousands of local decisions: a developer selects a machine type, an engineer increases capacity for reliability, a product manager launches a new workload, and a data team retains information for future analysis. A leadership team can create the conditions for responsible decisions, but it cannot substitute for them.

The most effective leaders therefore act less like commanders and more like architects of participation. They make the desired behavior safe, visible, and worthwhile. They ensure that teams can see the consequences of their choices without being punished for every necessary investment. They distinguish waste from deliberate spending that creates customer or operational value.

This principle applies equally to product ecosystems. A core team cannot satisfy every user request. It needs a way to distinguish isolated preference from durable demand, and demand from feasible contribution. A request becomes more credible when users demonstrate sustained interest, supply clear use cases, contribute code, or fund someone who can contribute code.

That is not a rejection of users. It is a recognition that product decisions have a cost beyond the initial build. A feature is a new promise. Once released, it needs documentation, testing, support, compatibility, security review, and future maintenance. Participation helps reveal whether the request is merely desirable or important enough to justify becoming part of the product’s permanent surface area.

In both settings, leadership creates the decision environment, while participants increase the quality and credibility of the decision. The best systems do not ask one group to do the work of the other.

From complaint to contribution

There is a significant difference between expressing dissatisfaction and creating leverage.

A complaint says, “This should be better.” A vote says, “Others agree.” A contribution says, “Here is an increment of effort that makes improvement more possible.” All three have value, but they operate at different levels.

This suggests a participation ladder:

1. Attention: Someone notices and names the problem.
2. Evidence: Others confirm that the problem is recurring or consequential.
3. Commitment: People invest time, money, authority, or reputation in solving it.
4. Implementation: Someone creates and tests a concrete solution.
5. Stewardship: The organization maintains the solution and learns from its effects.

Many organizations stop at the second level. They gather surveys, collect votes, hold listening sessions, and produce dashboards. These activities can create the appearance of engagement while avoiding the harder question: who will carry the work?

Imagine a platform team that receives repeated requests for more transparent cloud costs. It builds a dashboard and announces success. But engineers do not trust the allocation rules, product managers cannot connect spending to customer outcomes, and no team has responsibility for acting on anomalies. The organization has improved visibility without improving behavior.

Now imagine a different approach. Executives establish cost accountability as a shared business practice. Finance and engineering agree on allocation standards. Service owners review unusual changes. Teams receive timely information in the tools where they already work. Product leaders discuss cost alongside reliability and growth. The dashboard still matters, but it is only one component in a chain of participation.

The same logic applies to a requested product capability. A forum thread can establish that many users care. A technical contribution can reveal implementation paths. A funded developer can increase capacity. A clear use case can help the product team understand the underlying problem rather than blindly accepting a proposed feature. Each form of participation reduces uncertainty.

This is the central connection: participation is not merely labor; it is information.

When people contribute, they expose constraints that a central decision maker cannot see. An engineer who proposes a code change knows something about the architecture. A user who pays for implementation reveals urgency. A service owner who explains a cloud spike reveals a business dependency. Contribution turns vague demand into structured knowledge.

This also explains why participation should not be romanticized. Not every contribution is correct, and not every popular request belongs in the core system. Participation improves the signal, but leadership and stewardship are still required to interpret it. The goal is not to let the loudest group decide. The goal is to make the real costs, benefits, and constraints harder to ignore.

The architecture of shared ownership

If participation is so important, organizations should design for it rather than hope it appears. Shared ownership is not a mood. It is an architecture.

A useful architecture has four layers.

1. A clear decision boundary

People need to know what they can influence. In cloud financial management, a team may control resource selection and scheduling but not enterprise contract terms. In product development, users may influence priorities and contribute improvements but not determine every release decision.

Without clear boundaries, participation becomes either futile or chaotic. People invest energy in decisions they cannot change, while decision makers receive input without any obligation to explain how it was used.

2. A visible path from input to action

A request, anomaly, or idea should have a known route. Who reviews it? What evidence matters? When is it accepted, deferred, or declined? What happens after acceptance?

This is especially important for leadership initiatives. If executives announce a goal but do not establish a mechanism for local decisions, employees learn that the initiative is ceremonial. Conversely, if teams can see how their observations affect priorities, they are more likely to supply high quality information.

3. A contribution model proportional to the problem

Not everyone must write code or become a cloud economist. Useful contribution can include documentation, testing, analysis, funding, implementation, or careful articulation of a use case.

The mistake is to demand the same form of participation from everyone. A customer can provide evidence. A developer can provide a patch. A leader can provide authority and remove barriers. A finance partner can provide models and guardrails. Shared ownership works when different kinds of effort are recognized as complementary rather than ranked by prestige.

4. Feedback and stewardship

A solution that cannot be maintained is an expensive interruption. Every new dashboard, policy, integration, or product feature creates future obligations. Someone must monitor it, update it, explain it, and eventually decide whether it still deserves its place.

This is where many participatory efforts fail. They celebrate the launch and ignore the burden of keeping the result useful. Stewardship converts a one time contribution into a durable capability.

These layers create a practical test for any initiative: Can a person outside the central leadership group see how to help, understand what happens next, and know who will maintain the result? If not, the organization has probably built a request channel rather than a participation system.

Key Takeaways

• Treat approval as a starting condition, not a solution. After leadership agrees that an issue matters, immediately define ownership, decision rights, measures, and the next concrete actions.
• Convert demand into evidence. Do not rely only on opinions or votes. Ask for use cases, affected workflows, expected value, technical constraints, and the cost of leaving the problem unsolved.
• Offer multiple contribution paths. Make room for implementation, funding, testing, documentation, analysis, and sustained feedback. Different participants have different forms of leverage.
• Design the feedback loop. Show how a request becomes a decision, how a decision becomes work, and how completed work will be evaluated and maintained.
• Measure participation, not just outcomes. Track whether the people closest to the work can see consequences, make decisions, and act before problems become executive escalations.

The practical question for your next initiative is not simply, “Who approved this?” Ask instead: “Who has a meaningful way to make this real?”

A company that asks only for approval builds dependence on authority. A company that asks only for votes builds dependence on popularity. A durable organization combines both with contribution and stewardship.

That is the deeper lesson. Leadership is not the opposite of community participation, and community participation is not a substitute for leadership. They are two halves of the same mechanism. Leadership gives collective effort direction and legitimacy. Participation gives leadership contact with reality.

The most mature organizations therefore stop treating people as audiences for decisions. They treat them as co producers of the system in which those decisions must work.

The strongest mandate is not the one that produces the most agreement. It is the one that makes responsible action easier for everyone who must carry it forward.