Itâs quite common to see operations, change management and design acting separately as different transformational agents, but if these three forces can work together, the potential for effective change is great.
This article seeks to shed some light on how we can approach organizational changes through these three factors. Although I will not be giving the smallest details on how to execute each of these disciplines, I will leave references on how to leverage them and why they are important.

Letâs begin with a short storyâŚ
⌠about Breno, whoâs a dear friend of mine who Iâve worked with in the past. Breno wanted to implement a new process for briefing capture within his team, and although it was a simple change, he would often have to go after the task requesters to get additional information before delegating it to someone - it demanded time to make sense of what was written in the briefing and to correct it.
He wouldn't have it anymore - Â after 2 weeks of giving things a good amount of thought, Breno planned a new process in a visual collaboration tool and finally moved to program the solution via templates, task management system adjustment and e-mail comms. With that in place, not only would he have better quality of information, but it would allow the team to perform faster.
And everything was going to be perfect... or so he thought.
The first issues came from within the team:
- Since Breno didnât give a heads up about the process change, the team didnât know exactly how to act.
- Should they enforce his new way of working, or is that something Breno should do?
- What happens to the ones that are currently under approval, do they reject it or accept it for the time being?
- Some fields didnât seem to make sense to the team and they told Breno they felt the new process didnât take into account several important points in the briefing, like technical requirements and due dates.
- Ultimately, although the team didnât tell Breno, they felt their opinions were dismissed.
But wait, it gets worse:
- The process created a whole new set of problems, due to the fact it didnât quite link well with the other systems within the company. Multiple errors started to occur once the new requests started to arrive.
- The requesters got really mad with the fact they now have much more fields to write - as if the others werenât enough already - and some of them made no sense to them.
- An important field was taken off by Breno because he deemed it unnecessary for him and his team - but it was very important for the PMO... who was also mad when he found out the requests were no longer feeding him the necessary data for Portfolio Management.
Breno was in big trouble.

System thinking
What Breno did was try to change a system or subsystem. But what is that?
Systems, by definition, is a concept that involves elements, the interconnection between those elements and a purpose. And one system can have multiple subsystems that can interact with one another (they rarely donât).
When we deal with an organization, weâre dealing with  multiple systems, with visible and, most often, invisible interactions between themselves. Given our limited mental processing capacity, we tend to isolate those systems to ourselves and solve the problems within those systems only. Even worse, we tend to look at them as linear - increasing input will produce the same proportional output (ever heard about the joke about 9 mothers will produce one baby per month?).
Observing and understanding a system goes way beyond understanding the output it yields. Itâs easier because itâs visible, but outputs donât let you anticipate problems regarding adaptation, resilience and interconnections. To change any system effectively, we have to understand their behaviors, elements and sustainability.
And we do that with mapping and research.

Mapping and research
Itâs important to understand how the systems interact with each other and what patterns we can observe. Does a system overflow easily? Why? What causes that? What are the underlying causes? How to make sense of it?
Understanding the elements is quite important as well, like software, processes, structures and even people. People are the most complex and important element to understand within systems because they are generally the ones who enable a system's work. For that reason, thatâs one of the âwhyâ we observed an increase in user-centered design methodologies rising in the last 10-20 years.
Within those methodologies, there are several ways to extract useful information from the people element in the systems, like:
- Interviews
- Cultural probing
- âSafariâ
- Over even having a freaking conversation over a cup of coffee (virtual or not)
During the pandemic, this is a bit harder to do, but given the chance, get out of your chair and go talk to people. Even better, go observe them and learn what makes them tick. Youâd be amazed what you can learn from a bit of observation.
In this story, Breno didnât understand that changing a sub-system within a larger one would wreak havoc on his peers. By considering only the desired output and not talking to people, he didnât map important relationships, interactions and elements - if that system that Breno changed was a human body, it would probably be dead by now.

Enter service design
What could Breno do, instead?
Remember when I talked about the increase of user-centered design methodologies, in order to take the âhumanâ element into account more effectively? Great, weâre going to use one of them, called Service Design. Why? Hereâs some reasons:
- Changing a process means changing a kind of system people use to gain some benefit from. Itâs basically an internal service we explore to have a specific experience while and after interacting with it.
- Service design takes into account the interaction with other systems, elements (read people as well) and dependencies, meaning it has a better possibility of avoiding isolation.
- Itâs an iterative process, meaning it doesnât stop at one attempt - you learn as you go, improving as you find the opportunities to do so.
The main advantage of service design is the possibility of leveraging the knowledge of other people and co-creating with them to achieve a more inclusive and efficient result. If Breno involved the team and stakeholders during the construction of the process, he probably wouldâve had far fewer problems.
There are several interesting tools to be used in that methodology, like the stakeholder mapping and service blueprint. Letâs start with the first one.
Stakeholder mapping
Very commonly used in change management, stakeholder mapping is a tool that allows the understanding of the position an individual/group has towards a specific subject (in favor, neutral, or against), needs and interaction with other individuals/groups. It can be a visual representation, by interlinking different elements within a system or it can be a detailed spreadsheet, with extra notes.
A lot of people find it unnecessary to come up with this kind of data, but understanding the relationship between different factors and what their expectations are is one of the most important pieces of information to have when designing/changing a complex system.
Service blueprint
This tool is a kind of x-ray of a service or process. After the research, itâs a good way to evaluate the perspective of the involved elements within a system and how it interacts with others.

There are many other useful tools that can be applied in this kind of scenario and itâs well worth it to study a bit more about service design. I recommend this book called âThis is Service Design Doingâ, by Mark Stickdorn.
What does process resilience mean?
Letâs say Breno did go through the service design methodology this time - had a workshop, made interviews and came up with a process.
âAwesome, letâs implement it rightâ. Result?

Sure, you could argue that the iterations within service design could make it better... but what does better mean? Whatâs the criteria? Knowing what you need to measure to deal with the right problems, at the right time.
Say that after Breno implemented the process, the first finding he has is that even though heâs able to get better details for the briefings, requesters are still complaining about the velocity the team is taking to reply with a proposition. Now what?
Every system behaves according to two factors: stock, which are the elements of the system that can be accounted for at any given time; and flow, which is the change of stock over time. In Brenoâs case, the stock would be the number of briefings, people in the team, available useful working hours and others. What about flow? It would mean the number of briefings over time.
In the ideal world, these stocks would stay at a certain constant number, meaning thereâs always work to be done and the quantity is under control. A constantly decreasing number, however, might mean that Brenoâs team could be overstaffed and someone will be empty-handed in the future; constantly increasing, the team is probably understaffed and will face an avalanche in time.
From this case, you probably can already guess some interesting criteria or metrics to start figuring out if the process (or system) is healthy or not:
- Team velocity;
- Quantity of briefings incoming over x time (system input);
- Quantity of briefings delivered over x time (system output);
- Average development briefing time;
- Team size;
There are many other possible KPIs, but looking into these will give some insights on what to act on and adapt in order to make the system strive towards its purpose. Agile frameworks provide some interesting metrics to gather team insights and possible solutions. However, like any framework, those should be adapted to the team reality, rather than being enforced as a rule.
There are some great references about operations management, metrics and product operations:
- âMatching Supply with Demand: an introduction to operations managementâ, by Gerard Cachon, or this Coursera course.
- âMeasure what mattersâ, John Doerr.
- The Product Ops Portal

What does a healthy system look like?
When we think about systems, one book comes to mind - âSystem Thinking: a Primerâ, by Donella Meadows. In her book, she describes what a healthy system should be like:
- Resilience - there can be times when your system will have greater input and will need to have a strategy to deal with it. Does the system break when under heavier stress? Thatâs one of the moments when you find out if your proposed process is resilient or not;
- Self-organization - if Breno went out for a vacation, would the system work by itself? Can people adapt and self-organize? If the system breaks easily or canât adapt itself when an element is missing, it might mean it needs to improve its adaptation.
- Hierarchy - are they solving the problem in the right stream? If something that should be a managerâs responsibility goes to the team, are they able to identify it and say no? If the system is solving problems too small or too big for it, it will probably present problems sooner or later.
Remember, a system has a purpose. We need to be able to measure if that purpose is being achieved and what factors are influencing that. KPIs and Metrics are an important way to understand if itâs doing so and provide insights for the right adjustments.

Change management... or empower your leaders
Change management is about this: your brain is a jerk. Itâll do whatever it can to save energy and give us that sweet feeling of âcomfort.â
So Breno now has a process that he co-designed with his peers and team. Heâs also able to measure it through established KPIs and metrics, after some trial and error. He presented a beautiful dashboard to his director he made on Klipfolio and it even sends automated reports via email.
So now everything is perfect, right? Nope - some requesters downright refused to use the new process, saying they didnât agree to this. Also, some of his team members werenât using it, since they didnât understand why it changed so much, and are sticking to the old ways of working.
Implementing change is tricky - most people will only accept change if they understand the value of it, for themselves and for the companyâs purpose. You could say that people directly involved in the co-creation will support it, but what if you canât involve everyone, quite common in big organizations? Did you ever try to make your son or significant other do something they donât want or agree to? Most people, in those situations, try to impose it, threaten and even apply penalties in order to achieve the necessary outcome.
Seeing that scenario, researchers and specialized companies have been working on a discipline called change management, which is about giving leaders and employees the necessary tools to be able to navigate through transitions occurring within organizations. Itâs not a way to force something down peopleâs throats with sugar, but a way to help people cope and manage the consequences of a transition.
There are several methodologies and frameworks for change management - most of them created for corporate environments and very well structured - that propose several step-by-step ways to lead the transition within your organization. Although worthwhile to learn and even do some training, most change management frameworks go a bit like this (extracted from Harvard Business School):
Prepare the organization for change
People need to understand whatâs happening in the current context to realize the need for change. Awareness and buy-in are the most important parts of transition - most of the time, leaders are included as well and you might need help from higher places.
Craft a vision and plan for change
Sure, it can be downright simpler to just yank the change into our software and call it a day - but the reality is more complex than that. There will be implications and consequences we might not be aware of. Who should be involved? Do leaders know their role? What do we do when roadblocks arise? Planning ahead and setting small steps towards a change, so we can have a better width of adaptation is easier than dealing with a whole sea of problems all at once.
Implement the changes
This means giving the employees the means and power to take the necessary steps to achieve the end state of change. The organizationâs role, with its leaders, is to communicate, assist and guide their teams during this transition. Change is done and executed by the teams, not its leaders.
Embed change within company culture and practices
It is normal for us, humans and animals, to go back to things as they were. Our brain is lazy and hates to change things. For that reason, we need to be able to start incorporating these changes into the company culture and reinforce them for some time, until they become natural. Some even recommend using a reward system, changing the organizational structure and other ways to incentivize the transition.
Review progress and analyze
More metrics! Some change management frameworks propose a way to measure if the change itself is going well and it is successful, like adoption rate and velocity. Just donât forget the important metrics which are if the change is actually achieving the proposed goal.
Whoâs responsible for change management and how do you get good at it?
Changes need to be led by the organization's leaders, itâs better by small steps and resistance is natural. You can even do it through iterations and experimentation, but donât try to do it alone. There are some great reads about that kind of discipline like:
- Any Prosci book about change management. âADKAR: A model for change managementâ, by Jeff Hiat is a great start.
- âSwitch: when change is hardâ, by Chip & Dan Heath
- âLeading Changeâ, by John Kotter
- âLean Change Managementâ, by Jason Little.
Last considerations

In a very visual way, what I mean is this:
- You set your mind to understand that you are working within a system that probably interacts with several others.
- Do your homework to understand its elements, interactions, people and what itâs trying to achieve.
- Co-create, through design methodologies (I recommend service design), taking into account any process or internal system is actually a service that people use to gain some benefit from it.
- Measure the right things and understand how well your system is resilient and flexible.
- Implement by understanding our brains are natural lazy jerks and help people transit/lead through change.
Developing and implementing processes is hard work and something you wonât figure out by yourself. Be sure to involve the people this service will benefit and work together to refine it to a point of maturity.
Looking for more inspiration and insights on all-things product operations? The Product Ops Portal is where you need to be.

