Too close to see the canvas – Part 6
The Pattern beyond the pixels – Change is a process
In the first post we set the foundations of the story. In part two we covered reactive work and being stuck. In part three we talked about seeing past the ”impossible.” In parts four and five we got into metrics, layers and the sunk cost trap.
This final post is about the thing that ties all of it together and also the thing that is hardest to get right: the human side of change.
Knowing what needs to change is the easy part
By the time I had my data, my analysis and a clear picture of what was wrong and what could improve — I felt ready. I had evidence. I had concrete suggestions. I had a plan.
And it still didn’t go smoothly.
Because knowing what needs to change and getting people to actually change are two completely different problems. The first is a technical problem. The second is a people problem. And people problems are harder, messier and far less predictable than anything in a test report.
When this story happened, I knew none of this. (Honestly, when I first told this story as a talk, I still thought it was about automation. It took nearly a decade of management work to understand what it was actually about.) I still did not know why I had such a tough time changing things. After working almost a decade in more managerial roles, my story took a different turn. I now know what I should have done differently, and why so much was so tough.
Change is difficult. It hurts. It takes time. You will not be able to just walk in and change big things. You need help. You need to understand people, teams and organisations. You need to find the people who will help you get traction — your drivers and their followers — and find ways to create momentum with them. You need to figure out who can be a sponsor, who can be a helper, and what actually drives and motivates the people you need to convince.
Change instils fear
Fear of change is not irrational. It makes complete sense.
People fear losing their job. They fear losing their seniority — the accumulated expertise that makes them valuable. They fear being the person who turns out to be less capable when the new way of doing things arrives. They fear having the thing they built and are proud of dismissed as not good enough.
Even change that is obviously an improvement means temporarily not knowing what you know. A period of being slower, less confident, more likely to make mistakes. That is uncomfortable for anyone. Add a workplace where performance is visible and careers are at stake, and the discomfort gets amplified significantly.
People also fear change because they’ve usually seen it done badly before. Improvement initiatives that became extra overhead. New tools mandated from above and quietly abandoned six months later. If your history tells you that change usually means disruption without payoff, of course you’ll be sceptical of the next person who walks in full of energy about how things could be better.
When I met resistance, my first instinct was to bring more data. More evidence. Better arguments. It mostly didn’t work. If someone is afraid, logic is not the first tool to reach for.
Emotion beats logic
This is the part I got wrong most consistently, and I think a lot of technically-minded people do too. We are drawn to this work partly because it’s a domain where good arguments tend to win. A clear case, backed by evidence, should carry the day.
But change is not a purely technical discussion. It touches identity, habit, pride, fear, history, relationships. And in that territory, emotion is not a distraction from the conversation — it is the conversation.
If someone has been running tests a certain way for three years and you tell them there’s a better way, they may hear: you’ve been doing it wrong. If a team has been celebrated for the automation they built and you start asking hard questions about its value, they may hear: the thing you are proud of is not worth being proud of. Those are not the messages you’re trying to send. But they can easily be the ones that land, regardless of your intentions.
What this means in practice: before you can have the logical conversation, you often need to have the emotional one first. Acknowledge what people have built. Name the real pressures they’re under. Show genuine curiosity about why things are the way they are — not just what’s wrong with them. This is not manipulation. It’s basic respect. And it makes the logical conversation land a great deal better once you eventually get there.
I learned this the hard way with a tool called Graphwalker — and with an engineer I should have handled very differently.
The team had an existing automation framework that one of the engineers had built himself. He had put enormous effort into it. It had reporting, classification, logging, screenshots, you name it. It was genuinely impressive. It also struggled with certain parts of the system and I could see it wasn’t going to scale. So I started looking for alternatives.
I came across Graphwalker — a tool by Karl Krukow, previously at Spotify — and we brought in an intern to do a proof of concept. The way Graphwalker works is that you build a model of a system and then let a crawler loose on it. It doesn’t guarantee coverage of every case. You never quite know exactly what you’ll get on a given run. In that sense it’s less deterministic — more like an extremely simple chaos monkey. It worked brilliantly. We built models for several of our main user flows in a matter of weeks. (The intern did insanely good work! He finished our 12-week-plan in a month,)
The engineer who had built the original framework was not convinced, or on board. And I didn’t understand why — not then. Part of it was likely that the framework was his. He had invested years of thought and care into it, and here I was pointing to something fundamentally different and saying this was the way forward. But the deeper issue, I believe, was that in his mental model, regression testing had to cover everything. Every case. Every time. Deterministically. The whole point of automation, to him, was certainty — the confidence of knowing exactly what had been tested.
So we ended up spending at least ten times as long rebuilding the Graphwalker implementation to be deterministic. Which rather defeated the purpose, for me. (While still ending up a fantastic and useful tool.) To me, the chaos was the point. We want unpredictability. We want something that explores the system in ways we haven’t scripted. To him, that unpredictability was not a feature — it was reduced confidence, which was the opposite of what testing was supposed to deliver.
I didn’t help him see my perspective, or properly tried to understand his before I went into fixing mode. I just assumed everyone saw things the same way. I was relatively new to management at the time, and I moved forward with the conviction that the data and the results spoke for themselves. They didn’t. Not to him. Not without the conversation I didn’t have early, or deeply, enough.
You can’t skip the dip
There’s a well-known model for how people move through significant change — the change curve. Shock. Denial. Frustration. A real dip that can look like depression or despair. And then, if people make it through: experimentation, a decision, and finally integration into a new normal.
The tempting thing when you’re driving change is to try to get people from shock to integration as fast as possible. Skip the messy middle. Just get to the good bit. But you can’t. The curve has to be travelled.
What you can do is be a better companion on the journey. Help people understand where they are. Normalise the difficult stages. Provide support and small wins at the right moments to help people believe the experiment stage is worth trying. For some people this is fast and relatively painless. For others it takes a long time and a lot of support.
What you cannot do is argue someone out of the frustration or depression stages. If someone is at the bottom of the dip, another slide deck is not going to help. What helps is genuine acknowledgement that it’s hard, and enough safety to try something different without fear of being penalised if it doesn’t work perfectly the first time.
This is also why change takes longer than technically-minded people tend to estimate. We build in time for the technical transition. We forget to build in time for the human transition. And the human transition is usually the bottleneck.
What actually works
To actually make an impact, you need to come at it from all angles at once.
The why — the data. Why are we doing this? What is the problem we’re trying to solve, or the goal we’re trying to reach? This needs to be clear, concrete and honest. Vague promises of ”improvement” don’t move people. Specific, believable descriptions of what better looks like do.
The reassurance — how will this affect me? For good or bad? People need to be able to answer this question for themselves before they can move. If you don’t help them answer it, they’ll answer it themselves — and they may not be optimistic about it.
A compelling story. Not a pitch. A story. Something that connects to what people actually care about and helps them see themselves in the better version of things you’re describing.
And then you repeat it. Over and over again. Change doesn’t land in a single conversation.
Find the people who are already ready — the ones quietly frustrated with the current state, who’ve been wanting to try something different and just need a bit of support and permission. Work with them first. Build evidence and momentum together. That is far more effective than trying to convince the most resistant people first. Who could that be in your organisation? And who could be that one person helping you get traction?
And to recap…
So what did I actually learn from all of this?
I learned that being stuck makes unstucking yourself really hard. It is so much easier seeing that stickiness from the outside.
I learned that ”impossible to fix” and ”impossible for us to fix right now” are very different things, but feel the same in the moment.
I learned that what you measure shapes what you do, which you can use for good or evil.
I learned that one thing can’t (shouldn’t) serve everyone’s needs at once, but that layers can be infinite if you need them.
I learned that the sunk cost of anything is a hard boss to fight, but that the thing you’ve already built could be valuable then, but still be worth changing now.
But mostly I learned that change is hard. You cannot shortcut the human side of it. You need to find the people who are ready to move and build momentum with them.
None of these are surprising ideas, from this side of the story. But seeing them play out in a real organisation, up close, that’s different from knowing them theoretically. That’s the thing about being too close to the canvas. You can be very capable and still not see the picture. Seeing it requires stepping back. And stepping back requires someone making space for it.
I went in thinking I was there to fix automation. I came out understanding I’d been learning about people the whole time. I’m not sure that’s a lesson you can be taught — I think you have to live it. But maybe reading this gets you there a little faster than I did.
This is the final post in the ”Too Close to See the Canvas” series. If you missed the earlier parts, start here.
