UXA2023 Erin Casali - Driving organizational change with co-design

Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the
joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or
used by any other party without authorisation.
www.captionslive.au | [email protected] | 0447 904 255
UX Australia
UX Australia 2023
Thursday, 24 August 2023
Captioned by: Bernadette McGoldrick & Kasey Allen

View Slide

CaptionsLIVE Raw Transcript
_____________________________________________________________________________________________________
Page 5
So, thank you, all, very much. You will, for better or worse, you are
gonna hear from me a little bit more over these two days. For some
people, that's a good thing, and for others, you'll get tired of it. But, look,
I'll minimise it as much as I can. What I will do, though, is I'd love to
introduce our first speaker and our opening keynote for the day, Erin
Casali, who is the interim general manager of design at Xero, and joins us
all the way from London. Please join me in welcoming Erin to the stage.
Thank you. (APPLAUSE)
ERIN CASALI: Wow. This is really nice to be here again. It's been 10
years because I spoke at this very conference exactly 10 years ago. So,
happy to be here again, with a topic that I'm very, very passionate about.
It is about change, about transformation, about how we can improve the
companies and organisations and the groups we work with. I consider this
a little bit cringe, but this is just to say that I work across consulting, big
organisations, small organisations, products, I run my own product as
well. So, hopefully, this is to say that you will find something that applies
to you and your work. And if it doesn't, please come to me and let's have
a conversation later.
And, of course, if you're too shy to ask questions, just reach me out
in one of the many channels out there. So, let's get into this. Why I
consider design, and designers, really well-placed to drive change in
organisations? There are many reasons for me, but there are some skills
that designers have that are really, really useful in this process. They're

View Slide

_____________________________________________________________________________________________________
Page 6
really, really useful. The first of which is listening. Unfortunately, a lot of
management, a lot of organisations spend too little time to listen
internally to the people, to everyone that works with them, but, again,
designers are really good at that. They're really good at emphasising, at
listening, and are really good at extracting the insight that comes out of
this listening process, right? Then we have the second one, that is
facilitating. Facilitating, of course, can be seen as an activity we do to
reach a specific goal. But the interesting thing about facilitating itself is
that within the process of doing it, we are also aligning the people that
are participating in the facilitation process, and this is incredibly,
incredibly powerful. It's a superpower that I feel too many designers
underestimate in their day-to-day. Then we have modelling. We are really
using and taking really complex problems and simplifying them,
translating them to something that people can assimilate, can process,
can understand. And this again is essential because if we're presenting
some change, if we want to transform something, we want to make sure
that the people understand the change that is coming, and so this is
essential. It's a ground-level element to transform and, again, bring
change in organisations, and again we're really, really skilled at this.
And then we have interfacing. Again, this is interesting because, to
me, it's very underestimated. So, when we're talking inside organisations,
a lot of the tools, the interfaces, the documentation we write, the stuff we
do inside, can be considered as a sort of an internal interface between the
people that work in the organisation. Yeah, these are often text-heavy
interfaces, these are documents. But if we create a guidance, it's basically
a sort of a text-heavy interface. And these, again, are a really, really good
way to automate, transform and facilitate change in organisations. Really,
really underestimated superpower. And so with these four, we can then
bring in and say, "Hey, design is focused on product, right?" So, we are

View Slide

_____________________________________________________________________________________________________
Page 7
used to use our skills to design a result, a software, to design a service,
to design a thing. So, we design the product. The thing is, this
statement - that is, of course, true at a base level - it's also
underestimating the fact that, first of all, designing is inherently a
collaborative practice, and second of all, that most people don't work
alone. We work with other people. We work and we organise. And as
these groups and these organisations grow and change and transform,
there is a thing that happens that is called Conway's Law. How many of
you have ever heard of this? Just to get a sense. Raise your hand. Very
few. So, I'm very glad to introduce this to you. So, Conway's Law is sort
of an informal rule. Like, it's very difficult to prove in practice with hard
numbers, but historically has been proven true and also in my experience,
every single time, I see this happening over and over and over again in
many organisations. And the core idea is that the way we shape the
people that work on things, the way we shape the various things, the
various groups and organisations, that gets reflected in the product we
build. If we split through a line between two parts of the product, the
resulting product will be split through that line. And this is essential
because that means that we actually have a lot of power in shaping the
product if we start shaping the organisation that shapes the product. And
this is another reason why designers are really, truly very well-suited to
this kind of change, right? Because we can start shifting our attention - of
course, this often comes intrinsically with seniority, with shifts to
management - but even at any level, if we start focusing on how we are
split, we can start thinking about what's happening. If we notice in an
organisation that there is a divide between two groups, we may put effort
in bridging that divide. And, of course, more broadly, this could also mean
that when we reorganise a company because we want to build a better
product, so there is a direct relationship there.

View Slide

_____________________________________________________________________________________________________
Page 8
So, let's switch a little bit to another fundamental topic here - that
is about systems. To me, change cannot really be approached... Well,
many things cannot really be approached without system thinking. But it's
especially true in organisations because when you start putting humans
together in the same room, then it becomes inherently a complex system.
And so system thinking laws and dynamics start to apply every single
time. This is inescapable. And the idea about system thinking is that we
want to look at a system as a whole. There is a reductionist thinking that
instead says, "Hey, if we take a system and we split in all the
components, parts, and we do a deep-dive in each one of these parts,
then we understand the system." And system thinking says, "That's
actually not true." The system, but we're actually not understanding the
full dynamic and the full extent of how the system works because there
are a lot of things that are emerging behaviours. This is not a talk about
system thing. There are plenty of books and plenty of things out there
about it, but it's still essential.
The critical thing, however, that is connected to this is that it's not
possible to understand the full system. Like, there is no way for us, for
any individual, to grasp the complexity of all the interpersonal dynamics,
all the organisational dynamics, all the software dynamics. So, when we
start doing this, we are also acknowledging that we cannot understand it,
to an extent. This seems discouraging, but it's actually a very realistic
take of what we can do and how we can operate on a system. And I like
to quote Donella Meadows, one of the people that did a lot, a lot of work
on ecosystems and system thinking. Is that, "Everything, everywhere,
whatever we do, we are actually working on an abstraction on
reality." Because the system cannot be understood, we create models to
understand the system, and these models are the things we operate on.
But we always, always need to be conscious that we are operating on a

View Slide

_____________________________________________________________________________________________________
Page 9
model.
And I think that, for example, the Business Model Canvas is a
beautiful example of this. It's a model, a simple approach. It's a very
high-level approach. It's meant to help us to understand a whole system,
a whole organisation. Clearly, this is not how the organisation runs, right?
It's a very high-level abstraction. But it's a useful abstraction, it's a useful
model. I often say that when, especially in consultancy, when I used to
start a new project, I would also say, "Let's do the Business Model Canvas
of the client we're about to work with." Even if we're not working on
anything specifically related to the bottom line or internal things, we need
to understand at least at a high level how the organisation works.
So, the other thing about this is that we should not aim for the ideal
universal solution, in the sense that every organisation is unique, and
trying to come up with a solution that addresses for everyone, as we
pretty much know in design, trying to design something for everyone
means designing for pretty much nobody. So, we want to have a focus,
and often the focus here is our own organisation. And very simply
speaking, for example, let's talk about skill matrix or growth framework
for our disciplines, right? If we try to design a skill matrix that is
generalist, like this is the universal, industry-wide skill matrix, that will
not be effective. Because an organisation, for example, that doesn't have
a product function will have designers that need skills that compensate for
that. If we work in an organisation with a very strong research function,
the designers we need to hire and we need to grow don't necessarily need
all the research skills that another organisation would need. And so
always aim to work within the context you're referring to because that's
the most effective.
But the other thing is that all these things about systems also
implies that - and I love quoting Le Guin, that is system change. There's

View Slide

_____________________________________________________________________________________________________
Page 10
no such thing as a static system. And we know this from Ancient Greek
and long, long time ago, but this is the core thing. So, change, as it
happens, is inevitable. It happens even if we don't want it to happen, it
will happen. But if we shift from a passive take on this and we shift to a
more active take, we can also say that change is necessary because it
helps companies thrive, it helps people thrive within companies, and
within their own life, if we want to generalise further. So, change is also a
necessary action, a necessary thing that will improve what we do and our
work in general.
OK, and let's go down another level. Now we're talking about
circles, different kinds of circles that are really, really powerful tools to
start working with change. Influence circles are a pretty common concept.
But it basically is a way I personally think to put ourselves at peace. That
there are some things that are outside of our control. And what these
three circles - of course, there is no hard limit between the three, right?
So, it's pretty blurry and we all often work to blend and move between
each other. But, for example, if we start with The Circle of Concern, the
most outer one, these are things that are entirely outside my reach, that
are just happening, I cannot change them, I cannot influence them, I
cannot do anything about it. So, the only thing I can do about all these
things is that I can manage how much they impact me, how much they
influence me, and how much my team is affected - for example, for some
decision that the organisation is making as a whole, right? But - and
here's where we try to shift from one level to another - we can keep an
eye open for opportunities. Like we can say, "Do I have an opportunity to
shift to a different circle?" If it's something that matters to you. So, as an
example, I want to go - I was talking with my manager and it wasn't in
either of our power to do this, but I was like, "You know this vision piece
that we're using, it's meaningless. Like, the work is too vague. I could

View Slide

_____________________________________________________________________________________________________
Page 11
take literally this vision statement and apply to a different company and it
would work for them. So, there is no specificity." And the person was like,
"Yeah, no, I agree. I cannot do much about it." But because now I opened
the door, I was able to shift the level of concern, so a few months later,
the same person came back to me and said, "Hey, we actually want to
review the vision now. We're working on it." And this case, was like, "Do
you want to co-lead the change?" I'm like, "Sure," and so I shifted that, I
took the opportunity, and I was able to transform it.
Now, the next level down is Circle of Influence. These are the things
that I cannot act directly on, that I cannot transform directly, but I can
influence, so I can talk to other people and I can say, "Hey, what should
we do? Like, do you agree with me? Do you see this problem?" You know,
trying to say and talk to other people and see what can be done about the
thing. And so this is basically a change by alignment. So, again, another
example that was happened a while ago, I was discussing - this time not
with my line manager, but with someone in Product - and was like, "Do
you think how we're doing, how we're running road maps is effective? Is
it clear? Does it work for you? Because it doesn't for me." And it turns out
that that was the case, and it turns out that many, many people were
actually thinking the same thing. And so, again, a few months later, this
became a different piece of work, where we actually started working on
the road map, working on internal processes, and changed the way we
were doing things there. And, finally, we goat to The Circle of Control.
And these are the things that are directly in my power to change. These
are the things I can do, I can transform, and I can directly move forward
on my own. Now, on my own can be a stretch, especially in organisations
because, again, we're dealing with other people. So, that's why the circles
are blurred, to a point. So, I'm always dealing with other people, I always
will need to involve other people. And so a good example here is I was

View Slide

_____________________________________________________________________________________________________
Page 12
working in this case with my own team, and at some point I was like,
"Hey, what do you think about making our internal process to gain
flexibility, reduce the number of meetings?" People were like, "Yeah, let's
give it a try." So, I had a direct power because the team I was working
with, everyone was on board, and I was able to do the transformation,
and so our team became better and better and better at async work. We
changed the way we work and this was something directly in my control
to transform.
Now I want to present you a different circles. A lot of circles in
transition! But this is a model I personally created, and I find it useful to
plan, organise and structure change in organisations. And it's basically
structured on three levels. The reason why I work on this is that because
I don't quite care of the specific hierarchy within an organisation. But I
care, again, the influence - what each level does, right? And so I don't
care, like, how many levels there are in between, how many items are
there, how much is in between. But there are certain groups that can be
brought together. So, if we start talking, for example, at the Organisation
Circle level, this is the high level. This is usually controlled and managed
by executives, top management, and it's usually about especially large
organisations, about running the company, setting a vision, a direction, a
strategy, the financials, and organising at this level. The thing is, this
circle is also the circle that affects everyone in the company. So,
influencing at this level means changing for everyone, usually. Then we
have one level below. And, again, this could be many levels, it could be
one level, it doesn't quite matter. It could also be if you work in a matrix
organisation, it could also be a slice, either horizontally or vertically. It's
just a large group of people. Usually middle management, principals, it's
about strategy, tactic, and coordination, allocation of people, allocation of
work. This is usually just big chunks of the company, big chunks of the

View Slide

_____________________________________________________________________________________________________
Page 13
organisation. And finally we have the last level down that is Team Circles.
That is basically individual contributors, scoping and execution of work,
like, doing the actual work, and it's usually very simply as an
approximation, a single team. The thing here, again, why I don't consider
this, like, hierarchy thing, is because I consider, for example, the
manager working with the team part of this circle, not the one above. It's
a single unit - that's the first thing.
Now, if we start talking about change, then some changes happen
within the circle. I transform how a single level, how a single group, how
this group of people work together. This doesn't influence anyone else.
It's usually a very simple change that requires very little. Any other group
in the company doesn't need to do anything, so it's a fairly
straightforward transformation. Sure, it can affect others because, again,
it's a complex system, we're all working together, but the change is
usually self-contained. But the thing is, most of the time, that's not how it
works. Most of the time, we're actually working across different groups,
across different teams, and we're trying to influence and transform larger
parts of the organisation. So, how do we do this change, actually? And
using this model, we can start thinking about a sort of a language, or
about a sort of an approach on how to plan and how to organise. So, if
we're talking top-down approaches, now the thing about top-down
approaches, they often don't do these first steps. So, they often come as,
"Oh, we need to do this change. Everyone should do this change and
that's it. And it's pretty plain." But if we were going to do this right, our
first step would be consulting. "Hey, we want to do this change. What
everyone thinks?" And so we reach down, starting from the top level, to
all the layers in the company and see what people think, what people
suggest. Because we also want ideas, not just the reason why we
shouldn't do the change, right? So, we want to get a full view of this. The

View Slide

_____________________________________________________________________________________________________
Page 14
interesting thing about this is that, remember what I said at the
beginning about facilitation? The thing here is that the consultation
process is also part of the change itself because it's actually sending a
signal that is like, "We want to change this. We think there is a problem,
we think there is something that needs to evolve and transform," and this
is how you start the messaging in a way that is inclusive and brings
people together. And then again, ideally, it doesn't happen often, but we
want to run a pilot. Let's assume that this is a pilot of a change at a team
level. Again, we do the pilot, we see how it works, we see its success. And
finally, assuming it was successful, we roll out to the entire organisation.
Again, often this whole thing usually skips one and two, and just does
three. But this is ideally how we should work. Now if we get more
in-depth into this, consulting is again a facilitation process, a gathering
process. But we want to include, ideally, what the people directly
involved, so the people that will be directly affected by the change, but
also the people that are secondary-affected. So, the people that don't
have to do nothing but the change will also impact them. How do they
impact? What do they feel about it? You know? What changes for them?
And so the consultation process may be a little broader than what we
want. Now, the thing here is that I well understand that this model,
framed in this way, feels like a lot. But I want to start at the very
beginning, before I move to all the other steps, that this could also be
very lean. If you have a small company, small organisation, the
consultation step could be very short. It could be even an hour discussion
with a group of people, right? It doesn't have to be complex, as long as,
in a way, as it happens. The pilot, again, is the first experiment to see,
"Does the change work?" And especially, "Does the change stick?" So,
people are happy, is this effective, is this working, is it improving what
they're doing? This is key because it's also a way to gather insight and

View Slide

_____________________________________________________________________________________________________
Page 15
gather how much the change is effective in your organisation. Again, it
doesn't have to be huge most of the time, but you want to run it. And,
finally, once proven, we roll out. Again, ideally, the rollout should not be
just a message out, "We're going to do this from today on and it's done,"
and you assume it's done. It's a process in itself. And if the change is
complex, it's probably going to take a while for everyone to get on board,
for everyone to get adopted. But the most important thing is we still want
to check with the people how the change has been effected. Because even
if the pilot was successful, we want to make sure the pilot was
represented. Again, even in the rollout process, we want to be careful
about what we're transforming here. But let's go to other example.
So, name is a bit weird, but we start in the middle, and again we
consult down, we check what's happening. We run a pilot. So, again, we
want to make sure that the change, we define it in a consultation process,
is effective. But then we have the promotion. We have a step here where
we're saying, "Hey, this thing that we piloted was successful and now we
move up in the hierarchy and we say, OK, how can I promote this
activity? How can we make sure that it works for others?" There is, of
course, a rollout process. So, promotion is essential here because it
means that, first of all, we want to have a way to say, "Hey, the pilot
worked." So, the pilot isn't just a thing with the team, it's also a way to
gather the feedback we need to prove a point and say, "Hey, this change
could be useful to others. Let's try to roll out. Let's try to make sure
everyone else can use it again and it can become more widely adopted in
the company." Right? So, the promotion step, again, is often skipped.
Like, some people, like, do a change, transform, they improve their own
team... And then nothing! But if it's successful, why not? Let's have a
discussion, let's see if this can become more widely adopted. And then we
have another approach that, again, name is a bit weird - bottom

View Slide

_____________________________________________________________________________________________________
Page 16
expand - but the idea here is that we move horizontally. So, we create a
pilot - successful. In this case, in a sense, there is, of course, consultation
but it's within a team, so it's usually very short. But then we try to
influence horizontally and we try to make a transformational change all
the way down. Now, of course, this could also happen at any other layer.
It's usually here where it happens, however. But the idea of championing
can be incredibly powerful. And what we want to do in this process is not
just push into a team, "Hey, try this, try this, try this," but we want to try
and find champions, to find advocates that also say, "Hey, that idea is
good. Like, I want to do it with my team. Can we adopt? Can you help me
adopt it?" When they do, now they can do the same with other teams. So,
we're not just looking for teams that adopt a change but we're also
looking for advocates that can be part of the change and the
transformation itself. So, again, when you're planning this kind of change,
be careful and try to include the idea that it's not just how we include our
teams, how we propagate, but also try to identify, "Hey, I notice that you
are particularly passionate about this topic," and you elevate them with
you to become a champion.
Then we have the classic "bottom up". We have a pilot stage, we
champion - again, so we make sure that it works with our teams, other
people, it's adopted, it's successful. And then we move up and we try to
say, "Hey, again, this worked, this was effective." But, again, this
probably, because it's two steps up, you need to make a plan that is a bit
different. We need to find different strategies to be able to influence
multiple stages. And this could take multiple steps. Now, it's a bit
simplified, but, of course, it could be championed in one layer, rolled up,
then successful, up another level. It could be a multi-stage process, of
course. As I mentioned, rollout here.
Then we have another one, this is especially useful when we are

View Slide

_____________________________________________________________________________________________________
Page 17
trying to make a change that is not a change, for example, in this case, at
a team level. So, we cannot actually pilot or transform or do anything at
that level. But what we can do is try to influence others and say, "Hey, do
you think that this is a problem?" And so you start gathering and creating
allies that can work with you in creating a suggestion or a proposal, and
be part of the transformation you want to make. And then - then, only
then - we promote it up. And we say, "Hey, we all think, across all our
teams, that we should change this. And here is a few ideas we can
propose. And can we do the change at a higher level?" And, of course, it's
a bit trickier. If you remember The Circle s of Influence, this is working a
little bit more on the external circles, because you don't have a direct
power to do a change. But this is how you can articulate the change, even
if you don't have the power there, if you're not in control of the
transformation there.
And so the allyship is necessary in this case because you don't want
to be... Well, in some cases, you may have enough trust, enough
influence inside your company that you alone can create these kind of
ripples. But most of the time, by creating allies and creating, "Hey," more
and more people at your same level are actually saying the same thing to
the people, and then you can create a unified suggestion, it can be
incredibly, incredibly powerful to drive change.
So, the idea here is that these six, in a sense, verbs, could become
steps to configure your plan of change inside large organisations,
especially. This doesn't necessarily mean a huge organisation because as
long as you start having a few teams and maybe a couple of levels, all
these things apply. Again, it doesn't have to be huge things, it can be
very, very scaled down, but at the same time these are steps that happen
and that can help you shape and transform and prepare a plan for the
change you may want to do inside your own organisation.

View Slide

_____________________________________________________________________________________________________
Page 18
Now, this was preparing a plan, organising and everything, but
there is another element that actually I will touch later, but people are
resistant to change. So, if we start the discussion by saying, "Let's just
change," and you apply the change and that's it, people are often
resistant to it, and for the right reasons, actually. You know? So, one way
to do this is to take what I would call an experimental approach to
change. So, instead of saying, "We are going to change X," what we're
going to say is that, "We are running an experiment for a transformation
and see if the experiment is successful." Now, this changes completely
the mindset of the people. On one side, because you're not assuming that
what you're suggesting is 100% right. And at the same time, you are
asking people to say, "Hey, for a limited, specific amount of time, I want
you to buy in 100% on this. So, even if you - hopefully not - but even if
you disagree to a certain extent, let's give it a try. Can we give it a try in
earnest and see if it works for you and if it's effective? And if not, no
harm done, we can go back." So, this is something we can break down in
really high-level, but again it's very useful to have these kind of high-level
models, in three main steps. A plan stage, a run stage, and a review
stage. And the key, remember, is again communication. So, we want to
say clearly, "This is an experiment and this is how we're gonna run
it." So, on the planning stage, we want to be very clear about what is the
problem and what is the solution that we're trying to drive with this
experiment. So, we want to state very clearly at this stage, so, "This is for
communication," so people understand, but also for alignment. And later,
if this is successful, it's also an incredibly useful starting point for the
communication, you know, for the promotion level or for the championing
level of your work.
And, again, this is something that all of us, as designers, are really
good at. Really good at defining programs, really good at synthesising

View Slide

_____________________________________________________________________________________________________
Page 19
solutions, and just make sure you're stating and communicating it clearly.
And then another thing designers are really good at - so, we want to
co-design with the people. So, at the planning stage, we want to try to
identify solutions, to try to figure out, "OK, bring it in. Like, give me your
expertise. Give me your ideas. What would work for you? What would not
work for you? What are the programs you're seeing? Are we also aligned
with the programs?" Right? And so we want to bring into this discussion,
of course, the two levels, as before, so we want to bring in both the
people that are going directly having to do the change, but also the
people that are going to be affected. Like, as a second degree on that,
and get everyone's feedback before we shape the actual proposal and the
actual solution that we're aiming for. Now, how do this? This could be
workshops, this could be all kind of activities, online, in person, surveys.
These are literally all the tools that, as designers, we have available when
we're doing research, when we're shaping solutions, when we're trying to
identify what we want to build, how we want to build, and how we want to
solve this. So, should be nothing new, we're just turning the spotlight
inside your organisation.
One thing - and this is variable because artefacts are not super
clear when we're talking about processes. We're not talking about design
work, we're talking about starting maps, we're talking about all artefacts
that are defined. But if I ask any of you, "What is the artefact for a
process?" Right? We're probably going to get 10, 20, 30 different
answers, right? But the thing is, that using artefacts accelerates progress
and creates something we can discuss. And this is actually very, very
similar to the idea that if we present a frame, it actually communities and
shows what we're trying to design and trying to build much faster than
words and discussions and clarifications, and so on. The moment it
becomes real is the moment the change happens.

View Slide

_____________________________________________________________________________________________________
Page 20
So, how can we do this with processes or internal change? I would
define this as the checklist approach. So, try to write documentation and
internal guidelines as if it's a step-by-step checklist of the things that the
person needs to do with this change. You know, how it works, in detail.
Like, literally write it as a new joiner joins the company, needs to read it
through step by step, and needs to be able to replicate it. And you will
see that the moment you start writing this is the moment everyone
comes together because it's like, "Hmm, actually, no, this step, I don't
think it works, let's change it. ""and you switch around and you can
accelerate the transformation, accelerate the change so, so much because
now you have a single artefact that everyone has to come and agree on
and it's not anymore abstract thinking. It's actually, "Yeah, there are
steps in there, and do I agree with each step? Do I want to change
something? Is it actually going to make my life harder because now there
are a few steps in between that are adding work to me? Can I change
that in a way that is actually simplifying my work instead?" Right? And so
that is when it becomes clear. And so using checklists is an incredibly
powerful tool in this kind of scenario, in this kind of transformation. Then
we have the run stage. So, let's assume we plan, we co-design, discuss
the change together, we identify the solution, we identify how we want to
do things from now on, and now we kick off. This could happen whatever
is your internal communication channel, whatever, you know, I don't
know exactly how your company runs, but you want to make clear and as
public and as openly as possible that something has been changed.
Because this is a message not just for the people, again, that are going to
do the change but it's also a message to everyone else that something is
being tried. And, again, this also creates a marking point that later you
can refer back to and say, "Hey, we did this. We are doing this. We are
running this." And so you have a reference for everyone to see. And this

View Slide

_____________________________________________________________________________________________________
Page 21
basically states what is the problem, what is the solution, what are the
changes that we're suggesting, and so on. It's sort of a summary of
where we're starting on.
The next step here is what I call check-ins. We want to make sure
to review this ongoing. And this is a bit tricky because we're not just
looking for changes in the actual process we just defined. Like, "Oh,
maybe we tweaked this, maybe we didn't consider this issue, we thought
actually this is gonna be simpler so we want to make some tweaks here
and there." But also we want to check in for the people's commitment to
the change we just did. Because, yeah, everyone agrees, everyone joined
in, everyone is happy to try, but sometimes they're just, "Oh, yeah, sorry,
I just did the thing as we were doing it before." So, reminders and
checking in with people is almost as important as making sure that the
new process, the change, is actually happening in the way you planned
and you discussed. So, this also leads to adjustments. And the important
thing about adjustments here is that you want to tweak the things as they
happen, so, of course, you don't have to be strict about, "Oh, we defined
the plan, it's not gonna change until the end." But at the same time, you
don't want to radically change it, so you want to still stick to the initial
hypothesis, the initial problem, initial solution you developed, the core of
it. The collaterals can change but the core should not because you are
trying to prove if it works or if it doesn't, right? And, for example, what I
mean with this is that a while ago I was discussing with the team - not
from me, but it came out from one person in the team that was
suggesting, "Hey, what if we start doing, like, stand-ups in text, in
Slack?" And, OK, yeah, everyone happy with it, because everyone is like,
"Yeah, I can take that moment to just write down, take five minutes,
focus on the one thing I want to focus today on. It's gonna help me to
truly assess." OK, so we explored what it meant. We adopted a cool called

View Slide

_____________________________________________________________________________________________________
Page 22
Geekbot at the time, and everyone was happy to try, which I think for
three months or so. But, of course, so the thing here is that we kept
tweaking it, right? So, Geekbot was sending out questions to everyone,
every morning, but then we tweaked the questions. Because after a week
or so, people were like, "Hmm, actually, this question is a bit weird,
sounds strange." Actually, there was a question that was like, "Oh, this
actually feels too happy. Like, I'm not that happy every day!" So, let's
make it more neutral. So, yeah, we tweaked the language but we didn't
change the core of it. So, we didn't change the fact that it was text
standups in Slack, just tweaked to make it work.
And, finally, we reached the third stage and we run a retrospective.
Ideally, we try to involve everyone, people directly involved with the
change, and people indirectly involved with the change, affected. And we
want to check basically to see if the experiment was successful.
Depending on the experiment you're running, this could be focusing on
different things, right? So, you may want to check to see if you can check
productivity, you may want to see if you have hard numbers - sometimes
you can also do that. Like, if it was a change, for example, that was
geared toward, I don't know, reducing the number of cases solved per
day, or the time to conduct a code review, or things, then, yeah, you can
measure the time. Otherwise, there are softer measures. So, figure out
what works for you. And also always check how people felt. Did the
change feel good? Because maybe it was an increase in productivity but it
felt like a chore to everyone. Like, hmm, that's probably not something
you want to push forward. Because, ultimately, if people's mood goes
down and down and down the more this keeps going, it stops being
effective at some point, even if initially it is, right? And the other thing
important here is that you're not running this to check if the actual team
wants the change, but you're running this also to create the source - like,

View Slide

_____________________________________________________________________________________________________
Page 23
in a sense, the data you need if you later want to promote it and you
want to expand and say, "Hey, these are the results with my team. Do
you like these results? You could have the same results for yourself."
And, of course, there are three things here. If the experiment is
successful, stops being an experiment, becomes rolled out and becomes
official, let's say, in your team. And so from now on, it's done, good,
that's how we do things from now on. The second thing is, "Actually,
there was some major tweaking, so not the in-between tweaking that we
did so far, but we need to revisit this." So, usually this means we keep
the problem because we know that's a problem we want to fix but we're
actually changing the solution, so we're trying to look for another solution
and rerun the experiment. Or - and this is also a good thing - so revert.
Nobody liked it. Or the productivity didn't increase, or it didn't free up
people's time, or didn't make things more flexible. Good, OK, we know
now. Let's revert. We learned something. And this is also super important.
It's super important that teams acknowledge that these experiments can
fail, and will fail. I won't go as far as saying maybe the first time run
something, you know you're gonna fail to prove the point, so that people
start feeling comfortable in saying, "Oh, that was not just you telling us a
story just to convince us to run the experiment," you're actually OK to
make a fail and revert back. So, of course, you can try, but this is
something that is super, super important, that people know it could
happen.
Now, time is your friend in all this, because you need to
acknowledge that you cannot make a change in a very short amount of
time. You need to give people the time to understand, to process, to try
things out, and see how these things work for them. And that's the only
way to make sure that change stays and sticks. This also means that time
is also your enemy because, ultimately, the fastest you can make a

View Slide

_____________________________________________________________________________________________________
Page 24
change, the better, if it's successful, of course. But also you don't want to
push too hard, because if you start pushing hard or too many changes at
once, people would feel resistance, and then you're like, "Even if the
change was good, you changed too much at once, and people were just
like, nope!" But if you split it out in five stages, incrementally, then people
will be totally OK for exactly the same changes. So, there is a balance
there. That is something you need to address and review.
And usually call this, in a bit of a cheeky way, the same is
product-market fit for products, is a process-organisational fit. What we're
trying to check is if the process change is fit for the organisation we're
designing for, for the team or group it's designed for. We're not trying to
design universal solution. We're trying to design a solution that fits the
organisation and the team it's designed for. And how do we check this? I
would say there are many ways to check this. But there are two key
ways, to key questions. One is, do people want it? So, if I run this and I
have a successful pilot program that maybe is expanding, do other teams
look at the first team and say, "Can I have that?" If they're doing that, it's
super strong. I mean, it's not usually that strong, I have to admit, but if
you have a hint that people are curious about it, that are asking about it,
that they're like, "Hey, I think what you have there could help me," that's
a pull, right? And so people want it and now you have a strong, strong
sign that your change is effective. And the second thing, is the change
sticky? Because you may do a change, the team applies, it's happy, it's
successful, you reach the end, and then it doesn't stick. So, something
did not work and you may want to check why it didn't stick. This becomes
a question for you. But if it sticks, again, it means that it was desirable, it
was effective, and um proved people's lives - - improved people's lives,
improved processes, and it was sticky.
One thing that is unfortunate, and it happened so many times

View Slide

_____________________________________________________________________________________________________
Page 25
especially at the beginning, trying to change things, present an idea,
discussed an idea, made a workshop, everyone is aligned, everyone is
happy, let's do the change, yay! And nothing. And then a month passes
by and it's like, "Didn't we say that we were doing to do this? What
happened?" It was like, "Oh, yeah, yeah, actually, yeah, I want to do this,
just forgot, sorry." So, agreeing doesn't necessarily mean that the change
is gonna happen. You still need to put the effort in to remind people,
remember the check-in stage I mentioned before? The whole point about
experimental approach, you need to keep, in a sense, hand-holding the
change until it sticks. And the moment you can step out and not be there
anymore and the change sticks, then you're done.
Now, pushbacks. Because change is hard. And there are people
involved! And people sometimes are not quite conciliatory. But the thing
is, a note on politics. Like, often when we use this term - politics - inside
an organisation, yeah, it's with a negative connotation, right? But I also
use that as a sort of a moment to trigger a question, in the sense that if I
hear someone say, "Yeah, no, it's usually company politics. I cannot deal
with this." I was like, "Hmm, OK, stop a second. What do you mean with
politics there, in that specific instance, in that specific situation, what is
happening?" So, I use that as a driver to then trigger a deeper dive in
what's happening. Because politics, as I noted here, are just humans
interacting, in a way. And so this is, to me, the key thing, right? And, yes,
I want to acknowledge, yeah, sometimes there are - can I swear?!
(LAUGHS) But sometimes these people exist, so I don't want to dismiss
that. But depending - and hopefully you are in an organisation that is
good and these kind of people are very, very few - but what that means is
that you are getting angry at someone for other reason, and usually the
reason is that everyone is thinking they're doing the best thing they can
but are just not quite aligned with each other. And so the three core

View Slide

_____________________________________________________________________________________________________
Page 26
issues that often I see that usually gets referred to and cascade down,
maybe weeks after week, this builds up, builds up, and then people start
referring to it as politics, the first one is - lack of clarity. Like, we are not
even clear on what a goal was. We're maybe working on something, we're
maybe discussing something, but what is the goal? What is the thing that
we're actually referring to? I always find, still today, after decades of
working in this profession, that sometimes the question is, "OK, what is
the goal?" It's still one of the strongest drivers of change anywhere. But
then let's assume we have a goal but they're not aligned. Now we have
groups of people, heaps of people, teams, that they all have goals but
they're different. And so this is the second layer, right? So, are we
aligned? Are we talking the same message, thinking the same thing?
Maybe not. So, sometimes identifying that the other team, or
acknowledging that the other team is not working with you because they
just have a different goal, can be super important. And so, again, politics.
And the third level is just lack of organisation. Sometimes, you do have a
goal, you are aligned on the goal, but the organisation is poor, especially
if you're working with many teams, with many people, larger groups,
because exponentially the larger the group is, the more organisation you
need, the easiest it is to make mistakes. But sometimes it just lacks
organisation. We're working on the same thing, it's just that, "Oh, yeah,
no, I didn't communicate this clearly. Or, yeah, no, I know that this was
not quite the thing you asked for." There are a lot of things, lack of
organisation, again, can cascade down. And then you figure out three
months later that, "Oh, wait a second, I thought we were, like, we were
planning to do this, but your plan was different, even if we have the same
goal, and we didn't quite align what we were trying to do." And then we
have pure resistances. Like, these are factors that us, as humans, as
individuals, have and play all the time. The first one is inertia. So, the

View Slide

_____________________________________________________________________________________________________
Page 27
energy and the time required to change is often on zero, right?
Sometimes, you can do a change by automation, so you can modify your
software, modify your guidelines, so the change is actually a zero cost.
But it's rare. So, most of the times, you are requesting people to
understand the change, change something, how they do things, and the
answer is, "I don't have time." Maybe they're in crisis mode, maybe
they're responding, maybe they have a deadline, maybe they're just
overwhelmed by things. Maybe there are just five other changes
happening at the same time, right? And so you need to start helping them
if this is the problem. Start helping them. "OK, how can I help you to find
the time?" Sometimes it's just a matter of, "OK, let's wait three weeks
until you have delivered this and bring up this conversation again," so
you're not pushing them in the wrong moment, right? Sometimes they're
just, "Hey, what if I book one hour of your time next week and we have a
conversation about this change and let's have a discussion?" So, yeah,
first one. Second one is fears. This is raw, this is, in a sense, lowest level
in our emotional level, internal processing. And sometimes the fear - the
tricky thing with fear is that sometimes you don't even recognise there is
a fear there. We're just reacting defensively or not wanting change, and
so the kind of process with fear is trying to merge them. What are the
things? Let's have a chat? Let's review. What are you worried about?
What are the things that will happen if we are doing this change, right?
And this is, of course, one of the main reasons why the experimental
approach is so effective because it helps lessening fears. Because, like,
"Yeah, we can revert it. I'm good in trying. I'm good in giving it a go and
see how it goes."
Then pure ignorance. It happens a few times, mostly in consulting,
that start working with a team, start discussing with someone, and they
just don't know that a better process exists. And so they're just used to

View Slide

_____________________________________________________________________________________________________
Page 28
something else and the fact that they don't know, it makes them not
acknowledging that a better way exists, and so they're not even seeking
it, they're not open to it, because they're just like, "Yeah, this is just what
I know about it." So, sometimes being closed down, and this happens,
especially there is a dynamic, especially in organisations that have people
that sit for a long time, that they have very little openness to the industry
as a whole, they have little awareness of the changes that happen in what
other companies have tried. Often, these are people that don't go to
conferences! Because that's where, you know, ideas get shared. And so
this is a very good way to fight it, is to start sharing and opening up the
individuals to external stimuli.
And finally, hubris. "My way of doing things is the best way." That's
it. It's like, "OK." Again, this is probably one of the hardest to deal with.
There isn't a lot that we can do this, especially if this person is in a
position of power. But, again, acknowledging that this is happening, that
is not one of the other three cases, for example, is important because you
can work around it. Because you can try to say, "To find ways, you know
there is one specific person fighting against it, OK, what can you do to
align them?" Or I'm saying it softly, like - or to make them think it's their
idea! (LAUGHTER) Right? So, what you can do here. Yeah, these are all
good strategies you can use there. But I acknowledge this is the hardest.
And sometimes pushback happens. Again, we need to acknowledge
the negatives. So, pushback sometimes is just a consequence. Maybe you
timed it wrongly, maybe you did a change, it was a good change at the
right time, but something else happened. At the same time, that just
broke the change process. So, pushback can happen, and we need to
acknowledge it. So, the first thing to do is learn about it. What was the
actual thing that broke it? What was the actual thing that created the
pushback that stopped the change from happening? Right? And the key

View Slide

_____________________________________________________________________________________________________
Page 29
thing here is that, yes, focus on what went wrong in the process. If you're
using an experimental process, you already have half an answer here,
you can run a retrospective from. But it's also essential here to
acknowledge the reaction of the people. Like, what happened between the
people that created the pushback, right? And we can go back to the fears,
we can go back to the discussion about politics, like, all these elements.
You want to learn because you want to know exactly what to do different
the next time, right?
Then this is probably the hardest part - wait. You don't want to
keep pushing something because there is a sort of a period of resistance
after a pushback. And keep pushing during that period will just make you
look bad. You can, from time to time, still remind that the problem has
not gone away, right? But you may be careful it's not pushing too hard
about it. Again, happened to me in the past. This was more of a product
change than an organisational change, but someone tried to make a big,
sweeping change in one of the products - which was a good change,
which was a good transformation - but the solution was not quite right.
And when it started, it wasn't directly my change but I was trying to push
it forward, it was a good one, I was trying to support, but I started seeing
that it was going bad and was not going well inside the organisation. And
at that point, I knew that I could not do that again for the next 12
months. And so I needed to wait 12 months before raising the point
again, suggesting a solution again, bringing people together again, and at
that point the change started to happen because we learned from it.
Finally, we want to catch when the problem resurfaces. And, again,
maybe you that brings it up again. But if the problem resurfaces, we want
to be there, ready with the learnings, to be there again at the right time
to now bring it up and bring the transformation you want.
And, finally, you just try again, with all the steps, all the things I

View Slide

_____________________________________________________________________________________________________
Page 30
mentioned earlier in the presentation. You create a new plan, you create
a new adoption, you use the circles approach, you use the experimental
approach, and you design a new change and you try again to make it
happen. But the key thing in all of this is the waiting bit, that
unfortunately, and it's disappointing because we have to wait, but at the
same time it's also essential because people need just time to forget that
the bad thing happened in the past! (LAUGHTER) And so, yeah, I want to
close again quoting Le Guin, one of my favourite authors, in saying that,
with this quote, because I think it's really powerful, as an invitation to
start asking and focusing often on the right question. Because the right
questions are a really, really strong driver to change, and asking the right
question is often more important than pretty much everything else. And
that's it from me. Thank you. (APPLAUSE) Any questions?
STEVE BATY: Thank you. I'll let you take your seat and get people to
come and chat to you during the break for questions. Erin, thank you!
(APPLAUSE) I find, as I'm listening to someone talk like that, when I get,
you know, just this sort of series of wonderful ideas one after another,
that I think of different things along the way. And I won't bore you with
all of the different things that I was thinking about as Erin was talking,
but I just want to share where I ended up.

View Slide

UXA2023 Erin Casali - Driving organizational change with co-design

UXA2023 Erin Casali - Driving organizational change with co-design

uxaustralia
PRO

More Decks by uxaustralia

Other Decks in Design

Featured

Transcript

UXA2023 Erin Casali - Driving organizational change with co-design

UXA2023 Erin Casali - Driving organizational change with co-design

uxaustralia PRO

More Decks by uxaustralia

Other Decks in Design

Featured

Transcript

uxaustralia
PRO