It is common to hear that people in organizations resist change. In reality, people do not resist change; they resist having change imposed on them.

– Fritjof Capra and Pier Luigi Luisi, The Systems View of Life

Every design project is a change initiative. Some are overtly so, while others are more subtle. In the more overt ones, organizational change is a stated objective/driver of the project. In the subtle ones, the work is a manifestation of an organizational change.

Consider a project for a website redesign. The redesign is motivated by a desire to change something about what the organization does or how it works. Perhaps the company is reorganizing, launching a new product, or rebranding. All entail change.

While the new website design is the most visible change, the project affects many different groups. For example, even something as “simple” as a logo change may require changing customer-facing documentation, which is managed by the support organization. The affected teams must be engaged so they can (at least) plan for dealing with the change. The question isn’t whether they should be part of the conversation, but when.

I’ve seen a gamut of approaches. On one extreme, the core team doesn’t engage other parties until very late in the process. On the opposite extreme, other parties come in as true collaborators from very early in the process. It’s a trade-off between openness and control.

A common perception is that involving more parties in making decisions will result in compromised outcomes and/or delays. The larger and more open the project, the messier it becomes since there are more requirements and constraints to track. There’s a real risk of watering down the original direction to appease everyone.

But waiting until the project’s later stages to engage affected parties also creates problems. Invariably, new requirements emerge from stakeholders who know their part of the business better than the core team. Waiting too long also generates animosity. As Capra and Luisi suggest, people don’t like having change imposed on them. They may even resist, slowing things down.

The ideal balance between openness and control shifts as the project progresses. In the project’s early stages, the team must develop a clear and coherent vision. This vision is informed by strategic goals and high-level requirements, opportunities, and constraints. These things are often expressed as conceptual maps, systems diagrams, and other abstract representations. Key stakeholders must buy into these directions early on.

This early “abstract” work is best done by a small core team that includes the key stakeholders. As the team moves to make the project “real” (i.e. create more tangible artifacts such as wireframes, comps, and prototypes), they must include other teams. Opening up to greater collaboration will invariably result in changes to initial assumptions. That’s good: it’s better to catch such issues early on.

I prefer to involve other affected stakeholders as early as possible in the process. Their contributions invariably add depth and relevance to projects and keep the organization from making costly mistakes. That said, this calls for making difficult decisions, including possibly shedding prized ideas, which can be challenging for stakeholders who insist on particular directions. Opening up calls for compromise, and compromise calls for leadership.

Strategic design leaders must often mediate these tensions. Acknowledging they exist is an important first step. A second is realizing that we, too, have preferences; we‘re not impartial observers. (Design leaders must strive to keep a beginner‘s mind.) The key is understanding the delicate balance between control and openness — and the fact that this balance must shift as the project moves along.