You can't improve a process you haven't seen

Any process alteration should begin with understanding the current state. That sounds obvious, but it is easy to skip. We can interview people, map a workflow and review the systems they use. Those things are useful. They are still no substitute for seeing the work happen.

At Calo, our clients are the experts in their domain. We are the software experts. The best result comes when we bring those two kinds of knowledge together. Sometimes that means I need to leave the desk and become part of the delivery team for a while.

Seeing the whole process

I recently worked alongside the GWC Regalia Hire team during a University of Canterbury graduation. I was not standing at the edge taking notes. I issued regalia to students, collected returned items, returned stock through the Zebra scanner and helped separate regalia that needed cleaning.

Doing the work changed what I could see. A software screen might show that an item has been returned, but the real process includes the physical handover, the conversation with the student, scanning the right item and deciding where it goes next. If an item does not fit and needs to be swapped, everyone needs to understand what has happened to the original item.

During that process, a volunteer who described herself as "not a computer person" pointed out that the return state was shown only by an icon. It was unclear. She suggested adding text so the person completing a swap could immediately see that the item had been returned.

It was a small change, but an important one. More importantly, she was no longer just using a system someone else had given her. She was helping make it better. That is real buy-in.

The people doing the work have already solved a lot

People are often proud of the processes they have developed, and rightly so. A working process usually contains years of decisions, fixes and knowledge that may never have been written down. Arriving with a new system and treating all of that as obsolete is a good way to lose trust and miss important details.

Spending time understanding what people have built acknowledges their work. It gives us a shared view of the current state and makes it easier to explain why something should change. The people doing the job usually have excellent ideas. They know which shortcuts are harmless, which steps protect against mistakes and which frustrations are worth fixing first.

The graduation example showed this clearly. Improving a payment step might shorten one queue, but it could simply move the delay to fitting. A returns screen can look efficient in isolation while the physical sorting and cleaning process becomes the real constraint. You only see those relationships when you follow the work beyond one screen.

What I learned during a bin rollout

The same lesson came up while working with Rotaforms on a bin rollout in Rotorua. I helped drop off bins while the experienced team carried out the main allocation process. My role was useful but limited. I could help with the physical work and observe how the RFID system fitted into the rollout without pretending I knew their operation better than they did.

The original plan assumed much of the scanning would happen in the warehouse. The reality was that bins had to be separated for delivery, so scanning moved closer to the trucks. That is the sort of constraint that can look like a minor implementation detail in a meeting. On the ground, it changes how the system needs to support the team.

If we had focused only on the warehouse screen, we could have built a tidy solution for the wrong part of the process.

Participation needs boundaries

Embedding yourself does not mean taking over. There is a balance. An unfamiliar person can slow a team down, distract experienced workers or create risk. The aim is to help where useful, follow the people who know the process and step back when your involvement gets in the way.

Safety matters too. I only take on agreed tasks, follow site rules and avoid equipment or actions I am not trained or authorised to use. The same applies to the software. A live rollout is not the place for uncoordinated experiments with real data.

This is not about becoming permanent operational staff. It is a deliberate part of discovery and implementation. Observe the current state, participate during the rollout, then return after people have used the system. That final step often reveals exceptions and bottlenecks that moved somewhere else.

Discovery, learning and the solution

This approach is already built into how we describe our process at Calo. We start with discovery and a shared understanding of the desired outcome. We then use a validated learning loop, building something, measuring how it performs in the real world and using what we learn to change direction or keep going. The product is not the end of that loop. We keep learning after it is in use.

This has a clear connection to the Build-Measure-Learn feedback loop. The important word is "measure". Usage data matters, but it cannot always tell you why someone hesitated, why a queue moved or why a worker chose a different route through the process. Direct observation gives the numbers context.

Software should fit the work

Software makes assumptions permanent. If we misunderstand a process, the system can encode that misunderstanding and force everyone to work around it. That is why observing the current state is a needed part of any meaningful process alteration.

Our clients bring the domain knowledge. We bring the ability to turn that knowledge into reliable software. The work is strongest when neither side pretends to have both.

If you are considering changing an important process, talk to us before deciding what the software needs to do. We can start by understanding how the work happens today.