Building Capability

Chapter 9: Your People Are Not Obstacles. They're the Point.

Before you read — by the end of this chapter you will understand:

• Why technology projects fail when people aren’t genuinely brought along
• The consultation cycle and why it earns buy-in before the work is done
• How to use user acceptance testing as a trust-building exercise, not just a QA step
• Who should own training and documentation, and why it matters
• The difference between clients who co-design and those who throw it over the wall

I’ve watched a lot of technology projects fail. And I mean genuinely fail. Not just come in over budget or take longer than expected, but actually fail to change anything in the business in a meaningful way. The system gets built. It gets deployed. And then, six months later, half the team is still working the old way.

When I look back at those situations and ask what went wrong, the answer is almost never the technology.

The technology usually worked. The logic was sound. The features were there. The platform was stable.

What wasn’t there was the people.

Not because the people were resistant or difficult or unwilling to change. But because nobody had thought to bring them along. The project was treated as a technology problem, solved by technologists, handed over to users at the end with a training session and a user manual.

That is not how human beings adopt change. And if you treat it as though it is, you will keep being surprised by the results.

People First

When I start a capability build with an organisation, one of the first things I want to understand is the people. Not just the processes.

What are they actually good at? What do they genuinely enjoy about their work? Where do they add the most value? Where are they spending time on things that don’t require their level of skill or experience?

These questions matter for two reasons.

The first is purely practical: you design a better system when you understand what the people using it actually do. The gap between how a process looks on a flowchart and how it actually operates when a real person is doing it is almost always significant. If you design to the flowchart without understanding the person, you will miss things. Important things.

The second reason is cultural: people who feel understood are open to change. People who feel like a problem to be solved are not. If your first move is to map their process so you can automate it out of existence, you’ve already told them what you think of their work. Don’t be surprised if they’re not enthusiastic supporters of the outcome.

The work is taken seriously when the people doing it are taken seriously first.

The Consultation Cycle

I use a phrase I keep coming back to: take suggestions at the start, earn buy-in at the end.

Early in any capability build, before a single line of code is written and before any design decisions are locked in, I spend time with the people who will actually use whatever we’re building. Not just their managers. The people doing the work.

I want to understand what’s hard. What takes too long. What breaks down in the handoff between one step and the next. What they wish they had. What they’ve been asking for that nobody has ever built.

This is not just a requirements-gathering exercise. It’s a relationship-building exercise. It’s a signal to those people that their experience and expertise matters, and that we’re not going to come in with the answer already decided and ask them to fit themselves around it.

The result is that when the thing gets built, when the system launches and it reflects the suggestions they made, when the feature they requested actually appears, when the problem they described is actually solved, they’re not passive recipients of someone else’s work. They’re invested in it. They helped build it. They want it to succeed.

I’ve seen this dynamic make the difference between a deployment that transforms an organisation and one that quietly gets worked around.

It costs almost nothing to do this well. And it changes everything.

Presenting as You Go

The consultation doesn’t stop at the beginning. It continues through the build.

As we progress through each stage, we bring concepts, wireframes, and working prototypes back to the people who will use them. Not to show off what we’ve done, but to ask if it’s right.

Does this make sense? Does this reflect how you actually work? If not, what needs to change?

Some of those suggestions can go straight into the current release. Others go onto the backlog, acknowledged, documented, and committed to for a future phase. The key is that nothing gets ignored. People who raise a concern or make a suggestion should always hear back about what happened to it: either it’s in, or it’s coming, or here’s why it can’t go in right now.

That ongoing dialogue does something important: it prevents the accumulation of resentment that kills adoption. When people feel heard throughout the process, they’re ready to embrace each release as it arrives rather than reluctantly tolerating it.

The First Release Is a Starting Block, Not a Finish Line

One of the most damaging mental models in technology projects is the idea of “launch day.” A single moment where everything goes live, the team celebrates, and the hard work is done.

That is not how capability building works.

The first release is the point at which you’ve completed enough foundational and infrastructure work that you can finally hand something with genuine value to the people it’s built for. It’s worth celebrating. You’ve made it to the starting blocks. But the race starts now, not ends.

This matters enormously for how you prepare your people. If they believe the first release is the finish line, they will treat it as such: relief, followed by a gradual drift back toward old habits when the inevitable friction of a new system appears. If they understand it as the beginning of something that will keep getting better, they approach every small frustration differently. Not “this doesn’t work” but “this doesn’t work yet.”

The practical difference is this: rather than one big preparation effort aimed at a single launch event, prepare people for an ongoing cadence. Each release is a step, not an arrival. Each one brings something that wasn’t there before. The adoption conversation isn’t “here’s the new system, please use it.” It’s “here’s what’s changed this month, here’s what it means for your work, and here’s what we want to learn from watching you use it.”

That shift in framing changes everything about how people show up.

User Acceptance Testing: More Than Just QA

Most technology projects have some version of user acceptance testing, or UAT. It’s the stage where real users test the system before it goes live, checking that it works as intended.

In most projects, UAT is treated as a quality assurance step. It’s about finding bugs, confirming that requirements have been met, ticking boxes before deployment.

That is the minimum. It should be much more than that.

Done properly, UAT is one of the highest-value moments in the entire engagement. It’s the first time users interact with the real system in a safe, low-stakes environment. It’s the moment where everything becomes concrete, where the wireframes they saw three months ago are now a thing they can actually use.

The right way to run UAT is to provide a separate test environment, a full replica of the system where users can run real processes, make mistakes, explore features, and ask questions without any risk to live operations. Encourage them to break things. To find the edge cases. To try doing things in unexpected ways.

One exercise I’ve found particularly valuable, especially where the system is replacing or improving an existing process, is asking people to run the same real piece of work twice. First, the way they normally do it. Then through the system.

Not as a race. Not as a performance test. As a side-by-side comparison.

The results are almost always revealing. Sometimes the system is obviously faster and the person relaxes visibly. Sometimes there’s a step that takes longer than it should, or something that was easy in the old way is awkward in the new one. That’s exactly what you want to surface here, while there’s still time to fix it. Sometimes a field is missing, or a decision that used to happen in someone’s head hasn’t been built into the workflow yet.

But here’s the less obvious thing it does: it makes the old way visible, often for the first time. People who have been doing something manually for years don’t experience it as effort. It’s just how things work. Running it alongside the new system suddenly makes all of that invisible effort legible. The copy-pasting. The chasing. The mental overhead of tracking what’s in which spreadsheet. People see it with fresh eyes and often say something like, “I didn’t realise how much of my time that was actually taking.”

That recognition is one of the most powerful moments for genuine buy-in. Not because you’ve convinced them of anything, but because they’ve convinced themselves.

Three things happen in this environment that don’t happen in formal meetings.

First, people discover things that need to change. Small things that weren’t visible until someone was actually using the system. A field in the wrong place. A step that feels backwards. A label that’s ambiguous. These are valuable findings. Finding them here, before the first release goes live, is dramatically cheaper than finding them after.

Second, people become familiar. By the time the first release deploys, the people who went through UAT already know the system. The learning curve has already been climbed in a safe environment. They’re confident and ready rather than apprehensive.

That confidence is contagious. The people who tested become informal advocates and support resources for their colleagues who didn’t. Each subsequent release lands more smoothly because the pattern of test, learn, and adopt is already established.

All of this is downstream of treating UAT as a human process, not just a technical one.

Who Owns Training and Documentation

Here is a principle I hold firmly: the organisation should own the training and documentation.

Not because an external team can’t produce good documentation. They can, and they should help. But because of what happens to adoption when the organisation takes genuine ownership of how people learn to use the system.

When an external team writes the training materials, they’re good but they’re external. When the organisation writes the training materials, even with support, they’re internal. The language reflects how the team actually talks. The examples are real situations from the actual business. The steps are described from the perspective of someone who does this job, not someone who built the software.

More importantly: when a senior user explains the system to a new colleague, that explanation carries authority that a document from an outside party cannot. Peer-to-peer knowledge transfer is the most effective kind. It signals that this system belongs to the organisation, not to the vendor.

This doesn’t always work out perfectly in practice. Teams are busy. Training documentation is unglamorous work. Sometimes the vendor ends up holding more of it than anyone intended. But the principle should guide the engagement, always pushing ownership toward the organisation, always creating structures that support them to own it themselves.

The engagement level varies. Some clients co-design everything. Others hand over a brief and step back. Neither is inherently wrong, but the ones who co-design consistently get more out of the investment. Their people are more engaged. The system fits the culture better. The adoption is smoother. The outcomes are stronger.

The People Who Get Left Behind

I want to address something that comes up less often than it should in these conversations: what happens to the people whose roles change significantly as a result of the capability build?

In most cases, building genuine capability doesn’t eliminate jobs. It reallocates them. The people who were doing manual, low-skill work within a high-skill role get to spend more of their time on the high-skill parts. The people who were managing spreadsheets get to manage decisions instead. The senior experts who were being used as executors get to act as advisors.

Most people, when they understand that this is what’s happening, welcome it.

But some don’t. And some situations are more complicated than that description suggests. There are cases where a capability build does fundamentally change what a role requires, where someone who was valuable because of their knowledge of a manual process is less central once that process is systematised.

There’s no simple answer to that, but there is a simple principle: it cannot be ignored.

The organisations that handle this well are the ones who have those conversations early and honestly. Not waiting until the system is live and the role has already changed, but surfacing the question in the design phase: what does this mean for the people currently doing this work? How do we bring them along? What support do they need?

That conversation should be part of the capability build. Not an awkward footnote to it.

When People Are the Whole Problem: The Union System

Sometimes the clearest illustration of what this chapter is really about comes from a project that nearly went catastrophically wrong.

We were engaged to build an internal management system for a mid-sized workers’ union. The union had decades of history and a deeply entrenched way of doing things, except there wasn’t really one way of doing things. Each department had its own processes. Individuals within those departments had their own variations.

What looked like an organisation from the outside was, operationally, a loose collection of habits that had accumulated since the 1930s and never been reconciled.

The software project descended into crisis. Over a thousand issue tickets were raised. Deadlines slipped. The budget blew out. Both sides blamed the other. The union felt Redgum had failed to deliver. We felt the shifting requirements were impossible to build to. Both perspectives were right, and neither was useful.

What the post-mortem revealed was something more fundamental: there was no shared model. Nobody, client or developer, had a consistent understanding of what the organisation actually did or how it worked. We had been building to a version of the business that existed in one records admin manager’s head, her view of what should happen, layered on top of five years of reactive, piecemeal decisions made by a previous development team. There was no design. There was just accumulated assumption. And the people who actually worked there had never been brought properly into the conversation.

The recovery took over a year. A business process team was embedded with the union, mapping not the theoretical workflows but the actual ones: the way real people in real roles moved information through the organisation. Once that was understood, we used it to propose solutions. Here are the screens, here are the workflows, here are the reports. Both sides agreed on what would be built before a line of code was written.

Then we did something that sounds almost too simple: we pinned the planned screens, workflows, and draft forms to boards in the middle of the client’s office. Not in a meeting room. In the middle of the floor, where everyone could see them. Staff could look at what was coming. Ask questions. Flag problems. The changes stopped being a surprise delivered on a launch day and became something the whole organisation had watched take shape.

By the time the system went live, the people who worked there already understood it. The business process team had also written the training materials and run the sessions, and crucially, they’d explained not just what to do but why each process worked the way it did. The context made the adoption stick in a way that a how-to guide never could.

Ten years later, the State Secretary reflected on the project: “The membership system still ‘just works’; it’s fast, reliable, and does everything we need. The time we spent paid off many times over. Not only did I gain a comprehensive understanding of our organisation’s operations, but I also had a guiding hand that helped align daily activities with executive expectations. This process even allowed us to clean up a range of issues and behaviours that had been lingering since the 1930s.”

That testimonial came ten years after a project that almost ended Redgum as a company. The difference between those two outcomes wasn’t the technology. It was the decision, eventually and at significant cost, to treat the people as the point.

The Bottom Line

The technology is the visible part. The people are the point.

A system that nobody uses is not a capability. It’s a cost. The only way a capability build creates value is if the people in the organisation genuinely adopt and use what’s been built, and then build on it, improve it, and take it places you didn’t anticipate.

That happens when people feel like participants, not passengers.

Bring them in early. Keep them in the conversation. Give them ownership of what they can own. Respect what they know. Earn their trust before you ask for their buy-in.

Do that, and the technology almost takes care of itself.

Tool: The People Readiness Audit

Before the build starts, this tool helps you assess how ready your people are to engage with, adopt, and ultimately own a new capability, and identify the gaps before they become problems.

If you’ve completed the Business Landscape Map from Chapter 2, you’ve already done much of the groundwork for Steps 1 and 2. Your Base Layer shows you the roles whose working lives will change. Your Process Overlays show you exactly where the handoffs, decision points, and concentrations of knowledge sit. Don’t start from scratch — start from your map.

Step 1 — Map the people. Go back to your Business Landscape Map Base Layer. For each role that appears in the processes being changed, note how they’ll be affected and your honest read of their likely initial reaction. Include people who will use it directly, people whose outputs feed into it, and people whose processes depend on its outputs. If you haven’t built the map yet, list every role whose working life will change and do the same.

Step 2 — Identify who holds the knowledge. Look at your Process Overlays. Where the colour coding shows amber or red — the steps that are inconsistent, manual, or fragile — there is almost always a person holding the process together through knowledge that isn’t written down anywhere. These people are critical to building it right, and they’re also the ones most at risk of feeling bypassed if they’re not actively involved. Name them and plan their involvement explicitly.

Step 3 — Check the consultation. Have the people who will use this system been asked what they want from it, and has their input genuinely shaped the design? If you can’t point to specific suggestions that made it into the build, the consultation may have been information-gathering rather than genuine input.

Step 4 — Score your adoption risk. For each of the following, mark whether it currently applies:

• The team is very busy with limited capacity to absorb change
• Previous technology projects have gone badly, meaning low trust in the process
• Consultation has been minimal and people don’t feel ownership of what’s being built
• No internal champion to drive adoption from the inside
• Training and documentation plan is unclear or underfunded
• People are treating the first release as a finish line rather than a starting point

The more of these that apply, the more investment the people dimension needs before the first release goes live.

Step 5 — Assign documentation ownership. Who internally will own the training and documentation for this capability? This should be an internal person, not the development team. Name them now, before the build, so they can be involved throughout.

Want to go deeper?
The online version of this tool includes a full stakeholder engagement plan template, a consultation workshop guide, a user acceptance testing checklist, and a guide for handling role-change conversations constructively.
Available in the members area at [website]