Before You Blame the Person, Look at the System

I left Shopify DotDev energized by two talks in particular.

The first was the fireside chat between Tobi Lütke and Harley Finkelstein. The second was Javier Moreno’s presentation on River, the coding agent Shopify built for its team.

At the time, I could not fully explain why the talks seemed connected. They just felt both familiar and inspiring. It was only after going back through my notes that I realized how much of both talks was about the same thing:

The environment people work within, and how that environment shapes the outcomes they produce.

You Will Fall to Your Systems

During the fireside chat, Tobi talked about the relationship between ambition, systems, and care.

Ambition sets the upper limit of what an organization might accomplish. Care determines how much attention people give to the details. But when things get difficult, an organization falls back on the quality of the systems it has built.

As Tobi put it, “You can’t rise to your ambition, but you will fall to your systems.”

I have spent much of my career doing the opposite.

When the work fell short, I looked first at the person responsible for it. Did they understand the assignment? Did they put in enough effort? Were they capable of performing the role?

Those questions are sometimes necessary. But I have asked them far too early, before asking what should usually come first:

What about the system made this outcome likely?

Tobi’s discussion of Norman Doors brought the psychology behind that question into focus.

A Norman Door is a door whose design makes it unclear whether it should be pushed or pulled. You try the wrong thing, the door does not open, and you feel a moment of embarrassment.

But the person did not fail. The design did.

The environment created confusion and then transferred the emotional cost of that confusion to the person using it.

Tobi connected this to the experience of someone starting a business. Many Shopify merchants are taking a significant personal risk. They may be uncertain, underfunded, and attempting something they have wanted to do for years. Shopify’s software should not add to that anxiety by making them feel stupid.

The Norman Doors themselves were a small symbolic gesture. Tobi had them removed from Shopify’s offices, but his explanation was more important than the doors.

He said you cannot ask people to create work of exceptional quality while surrounding them with an environment that visibly tolerates confusion and poor design. The details of the environment tell people what the organization notices, what it accepts, and how much it cares.

That is systems thinking, but it is also an understanding of psychology. The system does not merely determine whether work gets completed efficiently. It affects how people feel while doing it. It can create confidence and clarity, or it can create anxiety, hesitation, and embarrassment.

We have built plenty of Norman Doors at StatBid. In some cases, we have effectively locked the doors and forgotten to give people the key.

Improve the Environment, Not the Robot

Javier’s talk explored many of the same ideas from a different direction.

River is an AI coding agent that Shopify made available through Slack. The decision to put it there was deliberate. Shopify is a remote company, and Slack is already where people work, plan, communicate, and learn from one another.

Javier argued that many coding agents isolate people. Someone works privately with an agent, discovers a useful way of doing something, and that learning remains hidden. River was designed to work in the open so other people could observe those interactions, contribute to them, and copy useful patterns. Everyone is an apprentice, and everyone has something to teach.

Shopify also records River’s sessions. Each evening, River reviews recent interactions and looks for places where it struggled. Shopify calls this process “gardening.”

The response to a problem is not simply to remind River what it should have done. The team tries to change the environment so River is less likely to encounter the same problem again.

Javier summarized this as:

Improve the environment, not the robot.

That might mean improving the codebase, adding clearer instructions, creating a new tool, or reorganizing information so it is easier to find. The learning becomes part of the environment instead of remaining in the memory of one agent or one person.

In the Q&A, Javier explained that memory is a short-term solution. If River repeatedly needs to remember a workaround, the better answer is usually to improve the environment until the workaround is no longer necessary. Shopify’s gardening process turns temporary learning into a lasting improvement to the system.

That is a remarkably useful way to think about process improvement.

When a person struggles, our instinct is often to add another reminder, another training session, or another instruction telling them to be more careful. We place the lesson in the person’s memory and expect them to carry it.

Sometimes that is appropriate. But when several people are likely to encounter the same confusion, we should ask why the environment requires anyone to remember the workaround in the first place.

A Familiar Set of Ideas

Neither Tobi nor Javier was giving a presentation about W. Edwards Deming.

Still, both talks felt familiar to me because they arrived at many of the same conclusions found in Deming’s System of Profound Knowledge.

Two parts stood out in particular.

The first is an appreciation for systems. Organizational outcomes are largely produced by the systems people work within. The second is an understanding of psychology. People are not interchangeable parts. The environment affects their ability to learn, collaborate, take risks, and do good work.

Deming’s work is something I have connected with and am trying to apply at StatBid. We are still early in learning how to apply these ideas, and I am still working to replace old leadership habits with better ones.

One recent experience made that painfully clear.

The Missing Central Question

We have been developing a process for analyzing our cash position and understanding why it changes.

I wrote an initial process that listed several questions the analyst should answer. Was the change caused by a decline in business? Higher expenses? Planned investment? Operational problems? Low utilization?

A team member completed the first version of the analysis, and it fell well short of what I expected.

My frustration was directed at them. I began questioning whether they were capable of performing the role.

Worse, they sensed my frustration.

At some point, I managed to take a breath and ask the question I am trying to make habitual:

Where did the system fail?

Once I looked at the process instead of the person, the problems became obvious.

The analysis answered each of my questions separately, but it never centered on the primary result we were trying to understand. There was no clear conclusion connecting the individual parts.

Important terms were not clearly defined. Different measures of revenue and cash activity had been combined in ways that made the comparisons difficult to trust.

A snapshot was treated as a trend. A change in one month became evidence of a broader problem without enough history to support the conclusion.

Description also stood in for analysis. The report listed what had changed but did not break the result into clear drivers or explain how much each one mattered.

Most importantly, a timing difference between when we billed clients and when we collected the cash was interpreted as a contraction in the business. It was an alarming conclusion, but not an accurate one.

Nothing in my process had required the analyst to separate those two ideas.

They had largely answered what I asked them to answer.

The process did not identify the primary question, define the basis for the analysis, explain what evidence was needed to support a conclusion, or show what a decision-ready answer looked like.

I had begun evaluating the person before I had given them a fair system in which to demonstrate their ability.

The Method and the Standard

The biggest improvement we made was surprisingly basic: I created an example of a strong finished analysis.

The written process described the method. The example established the standard.

That distinction turned out to matter.

A process can tell someone to reconcile two sets of numbers. An example can show that reconciliation changing the entire conclusion.

A process can tell someone to compare spending against the plan. An example can demonstrate that an expense that initially looks concerning was actually intentional and expected.

A process can warn someone not to overstate what the evidence supports. An example can show what restraint looks like by declining to make a claim when the data is insufficient.

The example also showed what “checkable” meant. The analysis tied together from beginning to end. The identified causes explained the result, and the proposed response showed how we could improve the situation. Supporting information allowed someone else to follow the reasoning and reach the same conclusion.

Those standards are difficult to communicate through instructions alone.

The next version of the analysis was much stronger. The team member learned a great deal through the process, and we came out of it with a better relationship and a more durable part of our financial system.

The improvement did not come from asking them to work harder or be more careful. It came from giving them a clearer environment in which to do the work.

Unlearning an Old Habit

I wish I could say I now respond this way naturally.

I do not.

Looking at the person first is a well-worn pathway for me. Applying these principles requires me to interrupt a response that often seems innately wired. I am trying to develop the habit of looking inward at the system before looking outward at the person.

That does not mean individual ability or responsibility never matters. It changes the order of operations.

Before deciding that someone fell short, we should examine whether the system gave them a reasonable opportunity to succeed.

Did we clearly define the outcome? Did we show what good work looks like and provide the necessary information and tools? Did the incentives support the outcome we wanted? Did the person receive useful feedback early enough to adjust? Did the environment create unnecessary confusion or anxiety?

Only after answering those questions can we fairly evaluate individual performance.

Gardening at StatBid

The talks did not leave me with a new management system to install. They gave me more conviction that we are moving in the right direction.

At StatBid, we are trying to build a culture of continual improvement. As a remote company, much of that happens through pair-work sessions over Zoom.

Right now, we are working to define quality across our core services. We need a clearer understanding of good work before we can systematically improve it.

The people closest to the work experience the problems in our systems every day. They see the unclear instructions, missing information, unnecessary handoffs, and small points of friction that leaders can easily miss. They are in the best position to help improve those systems.

The cultural experiment is creating the conditions that allow their intrinsic motivation to emerge.

Every person in the company now spends time each week pair working with someone else to improve part of the system. Our gardening is mostly happening in Confluence right now. It may be less exciting than an AI agent rewriting its own environment, but the principle is similar.

We examine the work together, identify the friction that contributed to a weak outcome, and try to make the environment clearer for the next person. We then capture what we learned somewhere more durable than an individual’s memory and repeat the process.

We are still learning how to do this well, and there is plenty of room to improve the system we use to improve our systems.

Tobi and Javier reinforced something I increasingly believe: the quality of an organization’s outcomes depends heavily on the quality of the environment it creates.

When a result falls short, we can begin by asking why. We can use the Five Whys or another method to dig deeper. But before we look for someone to blame, we should answer a more important question:

What about the system made this outcome likely?

That question does not remove accountability.

For leaders, it is where accountability begins.