Wikipedia Change Leadership

A change is not done when the new system goes live. It is done when people keep using it without being told to. The Accelerating Implementation Methodology, developed by Don Harrison at Implementation Management Associates in the 1980s, makes this distinction its cornerstone: installation is the technical deployment, and implementation is the point at which affected individuals consistently perform new behaviors in their daily work. The gap between those two moments is where most transformations quietly die, and reinforcement is what closes it.

The mechanism is unglamorous. It is the reward that follows the new behavior, the follow-through that catches regression early, and the deliberate embedding of the change into routines until it becomes the way things are done rather than a thing being done to people. AIM names this as one of its ten practice areas—Develop Reinforcement Strategy—and pairs it with Create Cultural Fit, because a behavior that contradicts the surrounding culture will not survive contact with an ordinary Tuesday.

The sequential change frameworks reach the same conclusion from the individual side. In Jeff Hiatt's ADKAR model, Reinforcement is the fifth building block, the one that ensures the results of a change continue. Hiatt was explicit that the steps cannot be skipped or reordered, which means reinforcement is not an optional afterthought bolted on if time allows. Skip it and Awareness, Desire, Knowledge, and Ability all decay back toward the old equilibrium.

Lewin's model called the final stage refreezing, and the word is honest about what reinforcement does. Change unsettles a settled state; without something to hold the new state in place, the old one reasserts itself, because it is still supported by every habit and incentive that was there before. Sustained performance is not the change—it is the maintenance of the change after everyone's attention has moved on.

How to

1. Codify the change in the relevant policy or guideline pages and cross-link it so it becomes the reference future disputes cite.
2. Automate adherence where possible with bots, edit filters, or gadgets so the new behavior becomes the path of least resistance.
3. Update onboarding, help pages, and WikiProject documentation so new editors learn the changed practice as the default.

Watch out for

• Relying on a few dedicated editors to manually sustain the change — volunteer attrition guarantees regression.
• Leaving old contradictory guidance in place, which becomes the fallback the moment the change loses momentum.

Transformational leadership is defined by what followers do that they would not otherwise have done. It is a leadership style in which a leader's behaviors inspire followers to perform beyond their perceived capabilities, prioritizing a collective vision over their immediate self-interests. That last phrase is the whole point. The measure is not that people work harder, but that they willingly trade their own short-term interest for a shared goal.

The behaviors are specific rather than mystical. Transformational leaders exhibit the four I's: inspirational motivation, idealized influence, intellectual stimulation, and individualized consideration. They serve as role models who raise followers' interest in their projects, they challenge people to take greater ownership of their work, and by understanding individual strengths and weaknesses they assign tasks that fit, which improves performance. Individualized consideration is the least discussed and the most demanding, because it requires actually knowing the person in front of you rather than broadcasting the same inspiration to a room.

The theory belongs to the full range leadership model, which empowers followers by granting them autonomy and authority to make decisions—after they are trained. The sequence matters. Autonomy handed to unprepared people produces confusion, not commitment; autonomy earned through capability produces ownership.

What this style generates is commitment, and commitment is the currency change runs on. Transformational leaders help followers connect their personal values to the mission of the organization, which fosters shared purpose. A person who sees the collective goal as an extension of their own values does not need to be persuaded change by change. They have already bought in, and that standing commitment is worth more than any single campaign of persuasion.

How to

1. Recruit high-edit-count, well-regarded editors as visible early adopters before announcing any change, so intellectual stimulation and idealized influence come from peers.
2. Frame the change as advancing the encyclopedia's mission (individualized to what each WikiProject cares about) rather than as an administrative directive.
3. Model the new behavior in your own edits and talk-page conduct so followers see the vision enacted, not just described.

Watch out for

• Charismatic appeals that ignore consensus process read as manipulation on Wikipedia and trigger backlash from the community's egalitarian culture.
• Relying on inspirational rhetoric without individualized consideration for different editor factions (deletionists vs. inclusionists, wikignomes vs. content writers) leaves whole segments unmoved.

There is a ceiling on how much change a person or an organization can absorb, and past it, more effort produces less result. Transformation saturation is the threshold where an individual or organization can no longer effectively process or integrate any more change. When the capacity for tolerating disruption is exceeded, the response is not slow progress but active reversal: exhaustion, resistance, and a decline in efficiency and performance, sometimes tipping into apathy, confusion, disengagement, and opposition.

The cause is not the content of any single change. It is the accumulation. The rate at which saturation is reached is determined by the timing of when a change begins, the pace of change, and the length and magnitude of the transformation. An organization can handle a large change or a fast change or a long one—but stacking them, or launching a new one before the last has settled, drives the whole system past its limit. The individual programs may each look reasonable. The load they create together is what breaks adoption.

The practical consequence is that adoption depends as much on sequencing as on the merits of the change itself. A well-designed change introduced into a saturated organization will fail not because it is wrong but because there is no remaining capacity to receive it. The 2020s made this vivid, when the pandemic forced remote and hybrid work, supply chain instability, and new wellbeing priorities onto organizations at once, and the field shifted toward monitoring adoption and engagement directly rather than assuming appetite. Reading saturation before launching is the difference between a change that lands and one that arrives at an exhausted door.

How to

1. Inventory concurrent and recent changes (software deployments, major RfCs, tool migrations) before scheduling yours.
2. Space major changes so the community can integrate each before the next lands, and publish a shared roadmap so editors see the pacing.
3. Watch leading indicators of saturation—declining RfC participation, rising revert wars, talk-page fatigue complaints—and pause when they spike.

Watch out for

• Foundation-driven and community-driven changes often arrive simultaneously without coordination, doubling the load invisibly.
• Treating each initiative in isolation blinds you to the cumulative burden any single editor is carrying.

Threat rigidity is the reflex to grip tighter exactly when you should loosen. It is an organizational behavior where the response to perceived threats is an inflexible adherence to established routines and behaviors, even when change may be more appropriate. The cruelty of the pattern is its timing: the threats that trigger it are often the very conditions that justify changing, and the organization responds by doing more of what it already knows.

The reflex has a personal cost. Threat rigidity can lead to employee disengagement, and the return-to-office initiative has been attributed in part to this dynamic—a retreat to a familiar routine under pressure rather than a considered response to it. The term was coined in a 1981 paper, Threat Rigidity Effects in Organizational Behavior: A Multilevel Analysis, and the phrasing captures the mechanism precisely: rigidity as an effect of threat, not a choice made after weighing options.

The conditions that feed it are structural as much as psychological. In an atmosphere of psychological threat, learning often stops altogether. When the climate makes employees feel it is inappropriate to reveal true feelings, the feedback that would signal the need for change never surfaces, and trying new ways looks risky because it violates established norms. Hierarchical authority, specialization, and narrow spans of control all quietly discourage experimentation, so maintaining the status quo becomes the path of least resistance.

Contingency theory offers a way out, providing an alternative that enables changes to occur by matching response to situation rather than clinging to routine. Under threat, that flexibility is not the natural move. It has to be built in before the threat arrives, because once fear takes hold the reflex is already running.

How to

1. Diagnose whether opposition is escalating in rigidity (more rule-citing, less negotiation) which signals threat rather than disagreement.
2. Reduce the perceived threat first—reassure the community that core values like verifiability and neutrality are preserved—before introducing the change mechanics.
3. Pilot the change in a low-stakes WikiProject so the community observes it as safe before broader rollout.

Watch out for

• Pushing harder against rigidity intensifies it; the defensive response tightens under pressure.
• External events (media criticism, legal threats, mass-editing scandals) can trigger community-wide rigidity that has nothing to do with your proposal but sinks it anyway.

A learning organization is one that keeps getting better at getting better, and that capacity comes from culture rather than from any single program. Peter Senge laid out the foundation in The Fifth Discipline, published in 1990 and later named by Harvard Business Review as one of the seminal management books of the previous seventy-five years. The disciplines it describes—systems thinking, personal mastery, shared vision, the examination of mental models, and team learning—are the habits that let an organization absorb change instead of merely surviving it.

The payoff is concrete: maintaining innovation and competitiveness, better linking resources to customer needs, faster change, stronger knowledge sharing, and improved long-term decisions. But the same culture that makes change easier does not install itself. Senge points to real barriers. Personal mastery can be seen as a threat, and the threat can be genuine, because to empower people in an unaligned organization can be counterproductive—individuals may use that mastery to advance their own visions rather than the shared one. Where no learning culture exists, learning gets devalued and ignored, and it stalls.

Senge named four conditions for initiating change, and they read as a warning against underestimating what culture must carry. There must be a compelling case for change, time to change, and help during the process. The fourth is the subtle one: as barriers fall away, a new problem not previously considered important, or not even recognized, must not become the next critical barrier.

This is why culture moderates whether a change takes. A team that can surface its own assumptions and share what it learns metabolizes a new practice quickly. A team that treats candor as risky and learning as threat will resist the same practice no matter how well it is designed.

How to

1. Build post-implementation retrospectives into the change and publish them where the relevant community reads (village pump, WikiProject talk).
2. Connect the change to a shared vision the community already holds so mental models shift rather than merely rules.
3. Create feedback channels that let editors surface and correct problems, treating early failures as learning input rather than proof of failure.

Watch out for

• Documenting a change in a policy page nobody visits mistakes archiving for learning.
• Systems-thinking gaps mean local fixes in one WikiProject create problems elsewhere unnoticed.

Before anyone changes what they do at work, three things have to line up inside their head: they have to see that the current way is failing, they have to want a different arrangement, and they have to know what the new behavior actually is. Awareness without desire produces informed bystanders. Desire without knowledge produces enthusiasm that dies at the first unfamiliar task. The order matters, and it runs front to back—you cannot install knowledge in someone who has not yet accepted that the problem is real.

This is why the human dimension of change gets its own discipline. Change management, at its core, is about preparing and supporting individuals in making an organizational shift, and readiness is where that preparation succeeds or quietly fails. The technical rollout can be finished on schedule while the people it depends on remain at zero on all three counts.

Readiness is manufactured, not discovered. Communication that spells out why the change is happening, what improves, and what specifically changes for a given person supplies the raw awareness and knowledge. A senior sponsor who visibly stands behind the effort supplies the signal that this is not optional and will not fade. A genuine sense that the status quo is untenable supplies the desire. Remove any of these upstream inputs and readiness thins out, no matter how well the software works.

Human-centred approaches push this further by involving people in defining the change rather than only executing it—co-creating the solution builds the desire and the knowledge at the same moment, because a person who helped shape the new way already understands it and already wants it to work. The readiness is not something you then have to persuade into existence. It arrived with the participation.

How to

1. Sequence the readiness build: establish awareness of the need, then cultivate desire through participation, then supply concrete how-to knowledge.
2. Recruit visible executive sponsorship (respected admins, WMF liaisons where appropriate) and a compelling case to feed awareness and desire.
3. Provide step-by-step guidance—templates, screencasts, worked examples—so knowledge is real, not assumed.

Watch out for

• Treating desire as something you can mandate; on a volunteer platform desire is earned through involvement, not directives.
• Assuming knowledgeable editors are ready—experienced Wikipedians may have high knowledge but low desire if not brought in early.

The most useful reframe in change work treats resistance not as an obstacle in the road but as a variable in the model—predictable, measurable, and manageable. The Accelerating Implementation Methodology, developed by Don Harrison in the 1980s, builds this in explicitly: resistance is expected, so you plan for it rather than being surprised and offended by it. The alternative posture, blaming people for resisting, tells you nothing you can act on. People withdraw from change for reasons that are legible if you look—inertia, self-interest, fear of loss, the plain discomfort of doing familiar work in an unfamiliar way.

Much resistance is manufactured by how the change is introduced. When plans are broadcast rather than discussed, when predetermined solutions arrive already finished, people have nothing to do but accept or refuse—and refusal is cheap. Human-centred design counters this by engaging the people affected in framing the problem and shaping the solution. Involvement in the design lowers resistance because a person defending a decision they helped make is not the same person defending a decision handed to them.

Communication does similar work when it answers the questions resistance actually asks. Not just what is changing, but why, and what is in it for me. Where fears are specific and personal, the standard playbook includes personal counseling to address them directly rather than hoping they dissolve. The failure mode is silence: failing to communicate what is happening and why leaves people to fill the gap with their worst guesses, and those guesses harden into opposition faster than any fact could.

How to

1. Identify the specific driver behind each pocket of resistance (inertia, self-interest, fear, discomfort) rather than lumping it together.
2. Use effective communication to close information gaps and stakeholder co-creation to convert resisters into contributors.
3. Distinguish resistance that reveals a genuine problem from resistance that is transitional friction, and act differently on each.

Watch out for

• Escalating to formal dispute resolution or votes to override resistance breeds lasting factionalism.
• Ignoring that threat rigidity amplifies resistance—the same objection is far harder to move when the community feels endangered.

Buy-in and mere compliance look similar for a while and then diverge sharply. Compliance holds as long as someone is watching; commitment holds when no one is. The difference is emotional identification—the extent to which a person feels attached to the change and the goals behind it and considers the effort partly their own. That attachment is what produces the extra discretionary effort that keeps new behaviors consistent long after the launch attention has moved elsewhere.

Commitment does not come from being told the goal. It comes from a vision people can see themselves inside, from leadership that models the change rather than merely announcing it, and from having a hand in the design. Co-creating the change instead of simply securing sign-off closes the distance between the person and the outcome; you are no longer asking someone to support your plan, because it has become partly their plan.

The absence shows up plainly in the record of failures. Change collapses from a lack of shared commitment and leadership, and separately from a lack of clear urgency when the warning signs are obvious. Both are commitment failures—the first horizontal, across the people who must carry the work, the second vertical, in the leaders who never made the case land. Note the phrase leadership commitment appearing among the metrics organizations track: they measure it because it predicts whether anything else survives. Effective communication that tells people what is in it for them and for you is doing commitment work, not just information work—it is converting an announced goal into a goal people own.

How to

1. Frame the change in terms of the encyclopedia's mission (verifiability, neutrality, knowledge access) that editors already self-identify with, not administrative convenience.
2. Recruit respected long-tenured editors as visible early adopters whose participation signals the change is legitimate to their peers.
3. Make the extra effort visible and credited — barnstars, edit-history attribution, and acknowledgment in project pages convert compliance into ownership.

Watch out for

• Do not mistake the vocal enthusiasm of a small WikiProject core for broad commitment across the drive-by and occasional editors who do most cumulative work.
• Avoid framing that positions the change as serving the Wikimedia Foundation's interests over the volunteer community's — it triggers identity threat and collapses buy-in.

There is a moment on every change project that feels like completion but is not: the system goes live, the process is documented, the training is delivered. That is installation—the technical deployment. Implementation is a later and harder thing. The Accelerating Implementation Methodology defines it precisely as the point at which affected individuals consistently perform new behaviors in their daily work. A rollout can be fully installed and entirely unimplemented, with people quietly reverting to the old way the moment the launch team leaves.

Adoption is what closes that gap, and it depends on the front-end work having been done. People who arrived ready—aware, willing, and knowing what to do—adopt. People whose resistance was anticipated and addressed adopt. People who committed to the change rather than merely tolerating it adopt. When those inputs are missing, the new behavior does not take, whatever the project plan claims.

Diffusion theory adds a sobering detail about how adoption actually spreads. An innovation must be widely adopted to become self-sustaining, and it does not reach that state smoothly. Regis McKenna consultants named the dangerous point in 1989: a gap between the early adopters and the early majority, the boundary the innovation must cross to reach critical mass rather than stalling as a niche practice used only by enthusiasts. Inside an organization the same shape appears. Early adopters take up the new way readily; the broad middle waits, watches, and adopts only when the change looks safe and normal. Getting from the willing few to the self-sustaining many is where most of the real work lives, and where projects that declared victory at installation quietly fail.

How to

1. Instrument the behavior: measure how many distinct editors perform the new action per week and whether the rate holds after the announcement fades.
2. Reduce friction at the point of action — integrate the new workflow into the existing edit flow rather than requiring a separate opt-in step.
3. Run a pilot on one WikiProject or namespace, fix the friction the pilot surfaces, then expand rather than launching sitewide at once.

Watch out for

• Beware the adoption cliff where usage spikes during the launch push then falls to near zero once the coordinating editors stop actively promoting it.
• Do not count the actions of the deployment team and enthusiasts as adoption; strip them out to see whether ordinary editors have taken it up.

Adoption that lasts a quarter and then fades is not the goal. The goal is improvement that persists—effectiveness, competitiveness, morale, and adaptability that hold up after the project team disbands and attention moves to the next crisis. This is the hardest state to reach, because organizations have gravity. Left alone, new behaviors decay back toward the old defaults.

What prevents that decay is reinforcement and anchoring. Diffusion theory frames the durable end state cleanly: an innovation must be widely adopted in order to self-sustain. Below that threshold the change depends on continued external effort—reminders, monitoring, pressure—and the moment the effort stops, so does the change. Above it, the new way has become simply how things are done, and it holds itself up. The failure mode has a name in the record of why change collapses: poor anchoring of changes within an organization's culture. A change not woven into the culture is a change waiting to unravel.

The metrics organizations track for this stage are telling—financial results, operational efficiency, morale. These are lagging indicators, visible only after adoption has stabilized and held. A change effort proves itself not on launch day but months later, when the improvement is still there and nobody remembers it as new. That is the quiet signature of change that took: the behavior stopped feeling like a change at all, and the performance gain outlasted the people who fought for it.

How to

1. Bake the changed behavior into structural artifacts that survive individual editors: bot rules, gadget defaults, page-notice templates, and the new-editor onboarding path.
2. Establish a recurring metric review (e.g., quarterly quality or retention dashboards) so regression is caught while it's still correctable.
3. Document the change rationale in permanent policy pages so newcomers inherit the 'why,' not just the rule.

Watch out for

• Watch for silent reversion during editor generational turnover — the veterans who championed the change leave and newcomers never learned why it exists.
• Do not declare victory on a post-launch metric spike; measure at a horizon long enough to capture whether the gain held through a full cycle of editor churn.

A senior leader who blesses a change in a launch email and then disappears has done almost nothing. Sponsorship is a verb. What moves adoption is the sustained, visible presence of a credible leader who authorizes the effort, funds it, and keeps showing up for it after the announcement fades. The three actions are distinct: authorizing gives the change legitimate standing, resourcing gives it money and people and time, and visible support tells everyone watching that this is not optional and not temporary.

Credibility is the part that cannot be delegated. When a leader with real standing puts their name to a change, they are spending accumulated trust, and people read that expenditure accurately. They know the difference between a leader who has staked something and one who has merely signed off. A junior manager cannot supply this on a senior leader's behalf, which is why sponsorship sits so high in change frameworks as a driver rather than a nicety.

The reason sponsorship matters so much is what it does downstream: it shapes whether individuals are ready to change at all. People calibrate their own willingness to the signals their leaders send. A visible, resourced sponsor removes the quiet question every employee asks first — will this actually happen, or will it quietly die like the last one. When the answer looks like yes, readiness has room to form. When the sponsor is absent, that question answers itself, and no amount of process design compensates.

How to

1. Recruit sponsors from within the editing community — long-tenured admins or well-regarded WikiProject leads — before involving Foundation staff.
2. Have sponsors visibly participate in the discussion themselves (comments, RfC votes), not just announce support from a banner.
3. Pair any Foundation-driven initiative with community co-sponsors so it is not framed as top-down imposition.

Watch out for

• Treating a Foundation press release or Board resolution as sufficient authorization — it carries little weight in editorial-space consensus.
• Sponsors who lend a name but go silent when the proposal is challenged, leaving advocates exposed.

Change starts by making the status quo feel less safe than moving. Without that, the default answer to any proposed change is to wait, because waiting is comfortable and costs nothing visible today. A sense of urgency is the deliberate work of establishing why standing still is the riskier choice — naming a threat that is real, or an opportunity that will close.

The case has to be both clear and compelling, and those are two different tests. Clear means people understand it; compelling means they feel its weight. A rationale can be perfectly logical and still leave everyone unmoved, because logic explains why change is sensible without making anyone believe it is necessary now. The urgency lives in the gap between understanding a threat and taking it personally.

This is why urgency predicts individual readiness. A person becomes ready not when they are told to change but when they perceive that the need to move outweighs the pull of the familiar. The manufactured crisis — urgency without a genuine threat or opportunity behind it — burns out fast, because people detect the theater and recalibrate. The durable version rests on something true about the organization's position, stated plainly enough that a reasonable person, hearing it, concludes on their own that the status quo will not hold.

How to

1. Anchor the case in measurable, mission-relevant harm: unreviewed edits, declining new-editor retention, specific content gaps documented with data.
2. Show the cost of inaction using the community's own dashboards and past incidents rather than external consultant framing.
3. Let respected editors, not staff, articulate why 'now' — peer voices carry the urgency.

Watch out for

• Manufacturing crisis; volunteers detect and punish exaggeration, and a debunked threat poisons future proposals.
• Framing urgency around Foundation timelines or grant cycles, which editors read as irrelevant to the encyclopedia itself.

A vision earns its keep by answering a practical question for the people living through the change: what does the future actually look like, and why would I want to be in it. That is different from a slogan. An energizing vision describes a future state concretely enough that people can picture their own place in it, and it supplies direction when the day-to-day gets confusing — which, during change, it always does.

The strongest visions are assembled rather than issued. They draw on the individual visions people already hold across every level of the organization, so what emerges feels partly authored by the people who will carry it out. A vision handed down whole, however polished, tends to align expectations only on paper. One built from what people at different levels already want has purchase, because it borrows their existing motivation instead of asking them to adopt someone else's.

What a shared vision buys is commitment and buy-in, and the mechanism is meaning. People will accept considerable disruption if they understand what it is for and believe the destination is worth the trip. Strip the vision away and you are left asking for effort without offering a reason that survives the first setback. Alignment of expectations is the quiet dividend: when everyone can describe the same future in roughly the same terms, coordination stops requiring constant correction, because people are already pulling toward the same place.

How to

1. Run open consultations (Village Pump, on-wiki RfCs, community wishlist surveys) to surface what editors actually want before drafting.
2. Express the vision in the community's terms — free knowledge, verifiability, NPOV — connecting the change explicitly to founding principles.
3. Iterate the vision statement publicly and let it be edited, treating it as a wiki page rather than a decree.

Watch out for

• Publishing a finished vision with a 'comment period' that is clearly cosmetic — editors will detect and reject the pretense of participation.
• Vision language borrowed from tech-industry mission statements that clashes with encyclopedic and anti-commercial norms.

The most common communication failure in change is treating a single clear announcement as sufficient. People do not absorb the reasons and details of a change on first hearing, especially when the change threatens something they value. The reasons, the benefits, and the specifics have to be communicated clearly and then repeated, because repetition is how a message moves from heard to understood to trusted.

Repetition alone still falls short if it stays one-directional. Broadcasting — the all-staff message, the town hall with no real exchange — informs without engaging, and it leaves the sender guessing about what actually landed. Meaningful dialogue does two jobs at once: it lets people surface the questions and objections they would otherwise carry silently, and it tells the leaders what the message sounded like from the other end, which is rarely what they intended.

Communication done this way works on two fronts. It builds individual readiness by closing the information gaps that keep people uncertain and hesitant. And it directly lowers resistance, because a large share of resistance is not opposition to the change itself but a reaction to being kept in the dark or spoken at rather than with. When people can ask, disagree, and be answered honestly, the friction that would otherwise harden into resistance has somewhere to go before it sets.

How to

1. Announce early and in the channels editors already read (relevant WikiProject talk pages, Village Pump, the Signpost), not only via top-down banners.
2. Explain the reasoning and the evidence, and commit to answering objections in the same thread within a predictable window.
3. Repeat the message across multiple discussions and languages, since there is no single audience to reach at once.

Watch out for

• Deploying MassMessage or CentralNotice banners as the primary vehicle — editors experience these as spam and impositions.
• Going quiet after the initial post; unanswered objections become the dominant narrative.

There is a decisive difference between asking people to execute a plan and asking them to help build one. Participation means the affected individuals are engaged in framing the problem, designing the response, and shaping the change — not just carrying out decisions made without them. This is the core of human-centred and participatory approaches, and it changes what the change actually becomes, because the people closest to the work know things the planners do not.

Participation lowers resistance for a reason that is almost mechanical. People resist what is done to them far more than what they had a hand in making. When someone has helped frame the problem and shape the solution, opposing it later means opposing their own work, and the psychological posture shifts from defending against an imposition to improving something they partly own. The change stops being an external event and becomes a thing they are inside of.

The same involvement produces commitment and buy-in, and the two effects reinforce each other. Co-creation is more expensive up front — it is slower, messier, and it forces leaders to accept ideas they did not originate. What it buys is a change that fits reality better and a set of people already invested in seeing it through. The trap worth naming is participation offered as a gesture, where the plan is fixed and the consultation is decorative. People detect the difference quickly, and hollow participation breeds more resistance than honest instruction would have.

How to

1. Open the problem to the community before proposing any solution, and let editors define what success means.
2. Run opt-in pilots and beta features rather than default deployments, so adoption is voluntary and measurable.
3. Give editors real authority over decisions — binding RfCs, not advisory surveys — on features that affect their work.

Watch out for

• Confusing a feedback survey with shared authority; editors know the difference and resent the substitution.
• Default-on deployments that force change before consensus exists, which historically produce reverts and revolts.