INTRO

At 11:26 on a Wednesday morning, Naomi receives what sounds like excellent news. Her proposal to simplify small employee expense claims is, according to the finance director, "a very sensible direction." The operations manager agrees. Someone from HR calls it "a valuable opportunity to improve efficiency." Naomi smiles, closes her laptop, and leaves the meeting feeling cautiously victorious. She has spent three weeks demonstrating that employees routinely need several approvals to recover amounts smaller than the cost of the meetings held to discuss those approvals. Surely nobody wants to preserve that arrangement. Six weeks later, the procedure remains unchanged. The only visible progress is a spreadsheet containing eighteen comments, three unresolved questions, and a column labeled "Next Steps" that appears to have entered a witness protection program.

Naomi has discovered something that surprises nearly everyone who first tries to improve an organization: being right is not the same as getting something done. Her calculations may be accurate. The existing process may be unnecessarily complicated. Everyone in the room may genuinely agree that change would be beneficial. Unfortunately, agreement in principle costs almost nothing. Implementation requires decisions, resources, attention, cooperation, and somebody willing to accept responsibility when reality refuses to follow the presentation. An organization can enthusiastically endorse a proposal while simultaneously ensuring that nobody has the time, authority, or incentive to carry it forward. This is not necessarily hypocrisy. Sometimes it is simply how competing responsibilities collide inside a business.

Consider what Naomi's colleagues might be thinking. The finance director sees an opportunity to reduce administrative work but also worries about weakening financial controls. HR wants employees to stop complaining about reimbursement delays, yet has no appetite for explaining a new policy that might change again next quarter. Operations would welcome faster approvals, provided its managers aren't suddenly expected to investigate disputed expenses. Each person sees part of the same proposal through the responsibilities attached to their position. Naomi sees a tedious reimbursement process. They see a collection of consequences, some attractive and others considerably less so. Her mistake was assuming that proving the problem existed would automatically settle the question of what everyone should do about it.

When people encounter this problem, their first instinct is often to become more persuasive. They prepare another presentation, find a more impressive statistic, or arrange a meeting with someone more senior. Occasionally, that works. Frequently, it produces the corporate equivalent of shouting directions at a driver whose car has run out of fuel. The instructions may be perfectly clear, but clarity isn't what the situation lacks. If the person controlling the budget sees an unacceptable risk, more enthusiastic descriptions of the benefits won't make that risk disappear. If another department cannot provide the necessary staff, declaring the initiative strategically important won't magically create additional working hours. Your proposal needs to address the conditions preventing action, not merely become harder to ignore.

That distinction matters because organizational resistance is not one single phenomenon. A colleague might disagree with your diagnosis, support your objective but dislike your proposed solution, or consider the entire initiative less urgent than existing commitments. Someone else may remember a previous improvement project that promised simplicity and delivered six new reporting requirements. Another person may suspect that your brilliant efficiency gain involves making their team do all the additional work. And yes, occasionally you'll encounter somebody whose primary concern is protecting their influence. But assuming that every objection is political sabotage turns a difficult situation into an impossible one. You cannot solve a resource conflict by accusing everyone of lacking vision, although you can certainly make the next meeting memorable.

The alternative is to become curious about what makes cooperation possible. Who would actually benefit from the change, and how? Who would need to adjust their work? Which risks are real, which are assumptions, and which have never been examined? Who has the authority to make the necessary decision, and who possesses the practical knowledge needed to implement it? These questions lead to a different kind of influence. Rather than gathering people who politely admire your idea, you begin building relationships with colleagues who understand the proposal and can contribute something meaningful. You stop treating support as applause and start recognizing it as a commitment that deserves careful consideration from everyone involved.

This is where the subject of internal alliances enters the picture, sounding considerably more suspicious than it needs to. You do not have to become an amateur political strategist, memorize the executive team's lunch arrangements, or learn which senior manager prefers being approached on Thursdays. Building alliances can mean something much simpler: understanding other people's legitimate priorities, explaining your proposal honestly, involving the right colleagues, and finding workable agreements. Sometimes that includes negotiation. Sometimes it means changing your original idea after discovering a better approach. A genuine ally is not someone who promises unconditional loyalty to your PowerPoint slides. It is someone who sees a worthwhile shared objective and knows what contribution they can reasonably make.

Of course, cooperation has limits. You cannot make everyone enthusiastic, remove every obstacle, or guarantee approval through excellent communication. Some proposals are too expensive. Others arrive at the wrong moment or depend on assumptions that fail under closer examination. Occasionally, the most responsible outcome is a clear refusal. There will also be situations in which obtaining support would require misleading people, concealing inconvenient information, or making promises outside your authority. Those are not impressive negotiation victories. They are warning signs. A useful idea should not require you to sacrifice your credibility merely to keep it alive. Knowing when to revise, postpone, or abandon an initiative is part of being effective, not evidence that you lack determination.

Nor does influence belong exclusively to executives. You might be a specialist who understands a recurring operational problem, a team leader responsible for a small group, or an employee who has noticed an unnecessary complication everyone else accepts as normal. You may have no budget and no authority over the people whose cooperation you need. Those limitations are real, but they don't prevent you from asking better questions, preparing reliable information, developing a practical proposal, and earning trust through your actions. Formal power can authorize a change. It cannot always make that change useful, understandable, or sustainable. Those outcomes depend on people who know what happens when a decision leaves the meeting room.

Throughout this book, we'll explore how ideas actually travel through organizations, from the moment somebody notices a problem to the point where a proposed improvement becomes ordinary working practice. You'll learn to recognize different kinds of resistance, communicate benefits without exaggeration, seek meaningful commitments, and turn vague enthusiasm into decisions. We'll also look at what happens when a sponsor disappears, priorities change, a promising trial produces disappointing evidence, or colleagues quietly return to old habits. The aim is not to turn every reader into a relentless campaigner for their own brilliance. It is to develop judgment about which initiatives deserve attention, what cooperation genuinely requires, and how to proceed without creating unnecessary conflict.

Before doing anything else, think about one idea of yours that has stalled. Perhaps it received enthusiastic comments but no approval. Perhaps somebody approved it, yet nothing happened afterward. Ask yourself what decision was actually needed, whose responsibilities would have changed, and whether anyone made a specific commitment. Don't immediately search for somebody to blame. You may discover a missing piece of information, an unresolved trade-off, or an assumption that never received proper attention. That discovery is useful even before you have a solution, because it gives you something concrete to investigate rather than another opportunity to rehearse why your original proposal was wonderful.

You don't need everyone to love your idea. You need enough shared understanding to determine whether it deserves action, and enough honest cooperation to carry it forward when it does. Sometimes that will mean a substantial organizational change. Sometimes it will mean one modest improvement that quietly makes everybody's working day easier. Both outcomes are worthwhile. The real achievement isn't persuading a room full of people to declare your proposal brilliant. It's creating the conditions in which something beneficial can actually happen. Preferably before your next project update acquires a title like "Alignment Meeting on the Strategic Approach to Future Alignment."

Chapter 1 - A Brilliant Idea Is Not an Approved Decision

At a regional furniture retailer, Eleanor has discovered something that seems almost embarrassingly easy to fix. Customers who order large items repeatedly telephone the company to ask when their deliveries will arrive. The existing system provides a date but no meaningful time window, leaving people to spend an entire day waiting for a sofa that might appear at nine in the morning or shortly before dinner. Eleanor proposes allowing customers to select a preferred two-hour delivery window during checkout. The customer service team loves it. The website manager calls it an obvious improvement. Even the sales director agrees that customers would appreciate greater certainty. Eleanor presents the proposal with a satisfying sense of having discovered common sense in a building where it occasionally requires a visitor's badge. Then the logistics manager asks whether she intends to buy additional delivery vehicles. Suddenly the room becomes considerably less enthusiastic.

Eleanor hasn't proposed buying a single vehicle. She wants to give customers more convenient choices using the company's existing delivery network. Unfortunately, the logistics manager sees something that isn't visible on the checkout screen: drivers whose routes change throughout the day, traffic that ignores carefully prepared schedules, deliveries requiring unexpected assistance, and customers who aren't home when the truck arrives. A two-hour promise might be entirely reasonable in some neighborhoods and prohibitively expensive in others. The proposal could reduce customer frustration while increasing missed appointments, overtime, and transportation costs. None of this makes Eleanor's idea foolish. It means she has demonstrated the value of a customer benefit without establishing whether the organization can reliably deliver it.

This is the first distinction worth understanding about internal support. A proposal can be desirable without being practical, practical without being affordable, and affordable without deserving priority right now. Those judgments involve different questions. Does the problem matter? Would the proposed change improve it? What would implementation require? What other commitments would compete for the same resources? An enthusiastic answer to the first question doesn't automatically settle the remaining three. Yet many proposals are presented as though demonstrating a genuine inconvenience should trigger an immediate organizational response, preferably accompanied by applause and a budget code.

Organizations make choices under constraints, including constraints that aren't especially visible from your position. The software team may already have committed its next development cycle to a critical system upgrade. Operations might be dealing with unusually high demand. Finance may be protecting cash for an investment with a fixed deadline. The people involved can sincerely admire your proposal and still make a reasonable decision to do something else first. This can be frustrating when you've spent weeks researching the problem, but the comparison isn't necessarily between your good idea and another good idea. Frequently, it's between your new initiative and an existing obligation that somebody has already promised to fulfill.

One of the most misleading sentences in business is, "It wouldn't take much." Sometimes that's true. Frequently, it means the speaker has considered the visible activity but not everything required to make that activity dependable. Eleanor sees a small addition to the checkout page. The scheduling team sees the need to calculate which windows remain available. Dispatchers see changes to routing procedures. Customer service sees the responsibility for explaining unavailable options and handling requests to reschedule. The website may display a simple choice, but the promise behind that choice reaches several departments. It's rather like describing an elevator as a box with buttons. Technically accurate, provided nobody asks how it gets to the next floor.

Before defending an apparently simple solution, investigate what must happen behind it. Follow a customer order from confirmation to delivery and identify the decisions that determine its timing. Ask what happens when a delivery is delayed, a customer requests a change, or a vehicle becomes unavailable. Determine which activities already exist and which would genuinely be new. This doesn't require you to become an expert in every department. It requires enough understanding to stop making promises on behalf of processes you haven't examined. When somebody identifies an unexpected dependency, treat it as useful information about the proposal rather than an attempt to spoil your presentation.

The problem itself deserves similar scrutiny. Eleanor assumes customers want narrow delivery windows, but that may not be the whole story. Some might simply want more accurate updates on the day of delivery. Others may be frustrated because the company communicates changes too late. A customer who receives a reliable morning-or-afternoon estimate might be happier than one promised a precise appointment that repeatedly slips. To discover the difference, Eleanor needs to examine complaints and speak with people who handle delivery questions. The point is to understand the inconvenience before committing to the most attractive solution. Otherwise, she risks spending money on a remarkably sophisticated way to disappoint customers more precisely.

Another complication is that the people receiving a benefit aren't always the people paying for it. Customers would enjoy more predictable delivery appointments. Customer service might receive fewer routine calls. The transport team, meanwhile, could inherit additional route restrictions. If the savings appear in one department while the workload increases in another, organizational support becomes complicated even when the total benefit looks promising. It's tempting to dismiss the concerns of the department carrying the additional work as resistance to progress. But if you're asking people to accept a cost, you need to understand that cost and establish whether the organization considers the trade-off worthwhile. Declaring everyone a winner doesn't make the arithmetic more cooperative.

This is also why the phrase "The business will benefit" is often less persuasive than it sounds. The business isn't a single individual making every decision from a perfectly informed position. It's a collection of responsibilities, targets, constraints, and existing promises. A warehouse manager may be measured on dispatch accuracy and labor utilization. A sales director may focus on revenue and customer retention. Neither can responsibly ignore their obligations simply because another department expects a broader improvement. Somebody must establish how the competing effects should be evaluated and who has authority to accept the trade-off. Without that, your proposal can become a conversation in which everyone agrees with the objective but nobody wants the consequences.

Evidence can make this conversation more productive, provided it's used carefully. Eleanor could examine how many delivery-related inquiries customer service receives, which complaints concern uncertainty, and what happens when delivery estimates change. She might compare the experience of customers in different delivery areas. Such information would clarify the problem, but it wouldn't justify promising a precise financial return without examining the costs. If customer service spends fewer hours answering routine questions, those hours won't necessarily disappear from payroll. They may instead become available for resolving more complicated cases. That's a genuine operational benefit, but it should be described as such rather than converted automatically into cash savings. Numbers presented with unnecessary confidence tend to become particularly uncomfortable when someone asks how they were calculated.

There's another question that authors often overlook because it feels disloyal to their own idea: what would happen if the company did nothing? Maintaining the existing delivery arrangement might continue to generate complaints, unnecessary telephone calls, and customer dissatisfaction. It might also be a reasonable temporary choice while the organization completes more urgent work. The cost of inaction should be considered alongside the cost of implementing change, not described as an approaching catastrophe merely to create urgency. If delaying the decision by eight weeks would have little additional impact, say so. That honesty can help you secure a realistic place in the schedule instead of spending the next two months insisting that every Thursday represents a historic missed opportunity.

Once the problem and constraints are clearer, consider which decision you're actually seeking. Eleanor initially wants approval for two-hour delivery windows across the business. That requires confidence in costs, scheduling capabilities, and service reliability that she doesn't yet possess. A more appropriate immediate request might be permission to investigate whether narrower delivery windows are practical for certain routes, using existing operational data and a small amount of agreed staff time. This is not a clever trick for obtaining approval in installments. It's an honest distinction between deciding to investigate something and deciding to implement it. The first decision can be reasonable while the second remains premature.

The size of the next decision should follow the uncertainty involved. If the organization already has reliable route data, a focused analysis may answer the most important questions without changing operations. If those data are insufficient, managers may need to agree on a practical way to collect the missing information. A live trial would require additional consideration because customer delivery promises can have real consequences. You shouldn't offer appointments you cannot reasonably honor just to demonstrate enthusiasm for experimentation. And if the change would affect contractual commitments, safety, or other formal obligations, the relevant approvals must come before implementation. Small scope is useful when it reduces risk and provides meaningful evidence, not when it becomes an excuse to ignore normal responsibilities.

How you handle criticism during these conversations matters almost as much as the information you collect. When the logistics manager identifies a problem with two-hour windows, Eleanor has a choice. She can defend the original proposal as though the manager has questioned her intelligence, or she can ask where the constraints are most severe. Perhaps densely populated areas allow more predictable routes, while rural deliveries require broader windows. Perhaps customers would benefit from accurate notifications without being offered fixed appointments. These possibilities deserve examination because they address the underlying problem, not because every objection must receive a compromise. An idea becomes more valuable when it survives contact with reality, even if it looks different afterward.

It's worth noticing how much emotional energy can attach itself to an initiative. Once you've named a solution, built a presentation, and imagined colleagues praising its success, criticism starts to feel strangely personal. You may find yourself defending a feature that you didn't particularly care about before somebody suggested removing it. That is a poor basis for business decisions. Try describing the outcome you want without referring to your chosen solution. Eleanor wants customers to spend less time waiting without reliable delivery information. That objective leaves room for several approaches. If someone suggests a better one, adopting it doesn't erase the value of her original contribution. The important achievement would be improving the customer experience, not preserving the exact arrangement of boxes in her first diagram.

There are occasions when the resistance really is unhelpful. A manager may refuse to discuss the evidence, a decision may be repeatedly delayed without explanation, or somebody may protect an outdated practice because changing it would threaten their influence. Recognizing legitimate constraints doesn't require accepting every objection as decisive. You can ask for the specific requirement that prevents progress, the criteria for reconsideration, or the appropriate person to resolve a conflict of priorities. Keep the conversation anchored in observable issues rather than announcing that your colleagues are frightened of innovation. Accusing someone of being against progress is satisfying for approximately four seconds. Explaining what decision remains unresolved has a much better chance of changing anything.

For Eleanor, a more informed proposal eventually emerges. Instead of promising two-hour appointments everywhere, she identifies delivery areas where scheduling is comparatively predictable and distinguishes customers' need for reliable information from their preference for narrow windows. The website team outlines what could be supported, logistics clarifies the operating limits, and customer service identifies the messages most likely to reduce uncertainty. Management now has a meaningful choice between improving notifications and exploring narrower appointments in suitable areas. Neither option has been declared a guaranteed success. Both are more credible than the original company-wide promise because their consequences are understood.

A well-prepared idea is therefore not simply an attractive description of how things ought to work. It's a proposal whose problem, expected benefit, assumptions, costs, and necessary decisions are clear enough for other people to evaluate. Sometimes that evaluation will lead to approval. Sometimes it will expose weaknesses or competing priorities that justify waiting. Even a refusal can be useful if it identifies a real reason. What you want to avoid is spending months improving the persuasiveness of an idea while leaving the conditions for acting on it completely unexplored. The organization doesn't need you to prove that your proposal is magnificent. It needs to understand what accepting it would actually involve. That may be less glamorous than unveiling a revolutionary new feature, but it has the considerable advantage of making a real decision possible.