It has been said, the only constant is change.

In businesses this is true. On daily basis, a business, which is a group of individuals working to provide services and/or goods to a group of individuals.

Everything about a business changes. Time ticks away. Employees come, and go. (On an average of 10% per year), which is really, much higher in the technology industry, and with innovative companies, in general.

Many changes at one time

It is okay to be working on many changes at a time.

Software teams do this very often. Multiple "tracks of work" are ongoing. This coordination of effort is commonly the responsibility of a Product Manager. For example, a team may have Designers interviewing customers about their needs and context. While Product Managers are working with stakeholders on communicating 360 degrees - typically upward and outward to executives and external stakeholders, and simultaneously inward to the team, and across to other teams and collaborators.

One change at a time

In the case where people are thought to be resistant to change, it is important to understand what is really going on. The rules of the game are changing.

Because the rules of the game are changing, the players of that game; the product teams and staff involved are best served to do their best work if they clearly understand the rules of the game.

In a way, the changing of the rules themselves, become a meta-game within themselves.

Software teams do this by using Merge Requests, where a discrete code change is adopted into the master branch.

Organizational processes are its source code. People are its runtime interpreter.

The system needs to be able to assimilate each change effectively and safely.

A map that guides action

Video games often use a navigational map, conveying the entire world. A dot on the map shows you where you're at.

Simon Wardley has been very influential in my thinking on the subject. Mapping being specifically useful for "situational awareness." Check out Wardley Mapping.

Understanding where you are currently at, as well as the possibility space is essential in navigating a business ecosystem successfully.

What I'm getting at is, designing for change is different than designing for an idealistic level of efficiency. The basic cycle of building, measuring, and learning repeats itself, in a fractal pattern, from the delivery of a feature through code, out to the design of a feature through customer interview and feedback, through production definition and alignment with business objectives. Cycles, spiraling up like a cone, whose point is the bits that are shipped. There is an opposing cone that represents the user's experience and context as well.

---

General Considerations

When designing processes, as well as software systems and interfaces, consider the following:

• Sensible defaults
• Convention over configuration
• Don't repeat yourself
• Proper affordances
• Feedback mechanisms
• Wayfinding (where am I, where am I going? what's available?)