The Friction Fix: Change What Matters

When Andrew Harmel-Law was inviting speakers to QCon London, their first thought was, "Let’s put Diana and Cat on stage together!" This was an impish impulse.

Cat Morris is a Product Manager. Diana Montalion is a Systems Architect. We both specialize in software systems and platform development. And we both blamed the other for all of our sorrows. Not personally; we’ve never worked together, but we believed that the role the other represented was the problem.

But we are also committed to improving the way we work. If we could resolve our differences … that would be a good thing for everyone, right?

First, we modelled every big initiative we had worked on. We discovered that every initiative ended like the Titanic: hitting an iceberg.

We discovered these career-changing truths:

• Our work overlaps. A lot.
• We need each other. Working together would have delivered better results. We think about the same problems differently but complementarily.
• Technology is not the problem we are solving. Technology challenges are the easy parts. The hard problem is friction.

Friction is the invisible current that sinks every transformation. Friction isn’t one thing, it’s systemic. Relationships produce friction: between the people, teams and technology. The fix isn’t Kubernetes, the Cloud or AI. The fix is changing our patterns of thinking, communicating, and organizing.

This article describes six recurring frictions that show up in every initiative:

• Counterintuitive behavior
• Refusal to change
• Efficiency and control
• Product vs. tech blame games
• Linear pipeline thinking
• Inability to deliver

Each friction keeps us busy rewriting the same codebase or redrawing the same organization chart. Friction regenerates piles of wasted work that don’t help us avoid the iceberg. This article will help you figure out what to do about it.

Counterintuitive Behavior

We are blaming the wrong things. As a result, we are doing the wrong things.

Counterintuitive behavior, defined by systems scientist Jay Forrester, is the tendency of complex social and managerial systems to react to problems with solutions that make the problems worse. Adding more engineers to a late project, for example, can make the project go faster.

When faced with a systemic challenge, our human inclination is to blame. Unfortunately, we blame the wrong things. We blame the engineering team for failing to work fast enough or decide the team is too small, rather than recognize that our Gantt chart was fiction, which is an oversimplification of a complex dynamic.

"Every system is perfectly designed to get the result that it does." – W. Edwards Deming

When we change how a system works, we also need to change the underlying patterns, structures and mental models that shaped the system we have. For example, rather than put GraphQL over a bloated database and call it a graph, we need to restructure the way we think about data. We need to create asynchronous events instead of shoving everything into a pipeline and create feedback loops that show us when data, moving across the system in real time, fails to connect as expected.

That’s why the engineers are late. They are busy putting lipstick on a pig while simultaneously doing invisible work the Gantt chart didn’t anticipate.

The Fix: Understand the System

Counterintuitive behavior has gravity into which we are pulled up and swept away. At least, that’s what it feels like: doing something, making progress. What’s actually happening is, we are tumbling, like clothes in a dryer, around and around, looking out at the problem from the same small vantage point.

The fix is to pause and get oriented.

Begin by identifying the core domain, the North Star. What is the goal of the system? For Fedex, it is fast package delivery. Chances are, when you are experiencing counterintuitive behavior, it is because people are navigating in different directions while using the same words.

Does everyone involved understand how the change is explicitly connected to the core domain? How will package delivery get faster without a negative impact? How is the system itself causing the problem? What is the mindset out of which the current processes and patterns arise? How do relationships in the system reinforce those patterns? What change is needed that you have yet to see? Start mapping those patterns, identify your core domain and those changes will make themself visible.

Refusal to Change

Every organization trying to change has that guy: the gatekeeper, the dungeon master, the self-proclaimed 10x engineer who knows where the bodies are buried. They also wield one magic word: No.

They say, "We’ve tried migrating. We’ve tried re-platforming. We’ve tried reorganizing. It won’t work. Don’t bother". They hold the keys to production or pipelines or some critical system, so they’re difficult to ignore.

It’s easy to blame that guy’s stubborn personality. But he embodies behavior that has been rewarded and reinforced. He’s become indispensable by managing the legacy complexity. To change him requires changing how the organization thinks, or another one of those guys will just take their place. Technology alone is not the answer.

Refusal to change is contagious. When that guy shuts down curiosity, others drift towards a fixed mindset. Doubt becomes the focus, not experimentation. The organization can’t balance avoiding risk with trying something new. The transformation is dead in the water.

"Change is hard because people overestimate the value of what they have and underestimate the value of what they may gain by giving that up." – Flight of the Buffalo: Soaring to Excellence, Learning to Let Employees Lead (Belasco and Stayer 1999)

The Fix: Fire That Guy

Okay, perhaps that’s extreme. You probably can’t fire them, but you can contain them. You’re not their coach, mother, or shrink. Don’t get stuck in that role.

Put them in a box. Give them a static domain where they can keep their scripts and their legacy while you transform the rest of the system. Balance their power word no with the power of Yes, and ...

Yes, and doesn’t mean agreeing with all ideas. It means exploring what’s possible. Redirect the conversation toward what can move forward. Find the people who are excited about change and help them solve their own problems instead of waiting for the gatekeeper to unblock them.

Efficiency and Control

Efficiency feels safe. Control feels like being responsible. Together, they form the most seductive anti-pattern in modern organizations: efficiency and control.

When they dominate, our focus narrows to outputs: features shipped, tickets closed, deadlines met. Work is measured in velocity, not value. The organization minimizes interaction and reflection, convinced that speed equals progress.

But in complex systems, pure efficiency is brittle. You get on-time delivery of the wrong thing. You get outcomes that match the blueprint but ignore shifting circumstances. You get short-term fixes that become concrete blockers down the road.

We get handed a roadmap with a budget and a timeline. The only context is a confusing pile of architecture.

We are asked to increase control without creating clarity. Efficiency is hiding incoherence. The result is organizational theater: Jira tickets, confident timelines, and metrics that track everything but meaning.

The deadline is immovable. The features are locked. What’s missing? A clear goal and a coherent outcome, with space to adapt as they learn. Package delivery times don’t improve, nor does the customer’s experience.

The Fix: Design Knowledge Flow.

Enable teams to be effective rather than overfocusing on efficiency. What can you do to ensure that time, energy, and attention are shaping outcomes that matter? Replace control with coherence: artifacts that enable the right information to get to the right people at the right time, travelling across boundaries without executive micromanagement.

Consider the project you are currently working on. Are you measuring outputs or outcomes? Do the deadlines reflect reality or wishful thinking? How can you improve the flow of information rather than structure a factory-style delivery process? Doing work is not the same as delivering value; improving knowledge flow will get you to value faster.

Product vs. Tech

Andrew brought us together because we have similar frustrations. We are both pressured to solve systemic problems with Kubernetes. Which, of course, we can’t do. We also, because of counterintuitive behavior, had fallen into the habit of blaming each other’s role.

Engineering teams dislike the pressure their Product Manager puts on them to deliver features in a tight timeline. They don’t understand why the changes they are making improve code quality. Infrastructure, architecture and DevSecOps complain that needed improvements never get prioritized.

Product teams dislike the resistance and negativity they hear from engineers. They don’t understand why something straightforward takes so long to build. They complain that meeting time is wasted overengineering everything rather than finding a way forward.

In many organizations, product and engineering are separate silos. Opposing forces with different definitions of efficiency and control. Product is expected to throw requirements over the silo’s wall and wait for working code to come back. Engineering is expected to code faster, without time for system design.

Even when the two roles sit side by side, their conflicting approaches and need for control exacerbate the friction.

The Fix: Become Learning Driven

Dr. Carol Dweck describes two mindsets: fixed and growth.

A fixed mindset says that being good at something means it should come easily. If something is hard, you lack the talent. In this mode, people avoid challenges, see feedback as criticism, and feel threatened by others’ success. The result is brittle teams that protect their turf instead of learning together.

A growth mindset says that ability develops through practice (in context), feedback (in context), and persistence. You can’t just do what Netflix does. In this mode, people welcome challenges, treat effort as the path to mastery, and use setbacks as data for improvement. The result is more resilient individuals and teams who adapt instead of resist.

When everyone, regardless of role, adopts a growth mindset, they learn together. Empathy is a crucial skill. Empathy is not the same as feeling sympathy, it is the capacity to understand circumstances from multiple points of view. The impact on the user and the code. The entrenched problems caused by the processes and patterns between product and tech.

In order to make impactful decisions together, we need a growth mindset, allowing other people’s experiences to inform our worldview and lead us to deeper insight.

Linear Pipeline Thinking

Remember the olden days when the bug was somewhere in the software? Fix a line of code and: voila! Nowadays, in the complex world of microservices and distributed systems, the bug is usually somewhere in relationships between parts. The art and science of systems architecture is designing and.

Every day, we experience friction because we are delivering linear pipelines in an asynchronous world. We might call them platforms, but platforms are well-designed relationships between different technologies and processes. They can respond to different events, at different times, in different ways. Together, the parts generate something none of the parts could do alone. This phenomenon is called emergence.

Designing for emergence requires synthesis, integrating multiple points of view in order to understand how to change the system as a whole to achieve fast package delivery. Make changes without breaking those asynchronous relationships.

Synthesis isn't a solo activity. You need other people to contribute their expertise and integrate that expertise with yours. When we can’t architect practices that synthesize organizational knowledge and experience … we can’t design (or debug) platforms. So, we deliver a pipeline, and everyone blames the wrong things for its inadequacies.

The Fix: Architect Relationships

Rather than apply linear thinking to an asynchronous situation, step back and model these questions:

• In your system, how do relationships produce effect?
• How do the relationships between the parts enable something that the parts themselves don't do directly?
• How does information flow across the technology system?
• Where are the pain points and bottlenecks and how can relationships be improved in order to unblock them?

If your organization doesn’t support this work, form a stealth group. Bring different points of view into your recommended changes, regardless of your role. Ensure that information flows between people so it can flow between services.

When groups with different perspectives (like Diana the Architect and Cat the Product Manager) model these patterns, everything gets easier. Talk to other teams. Watch people use the system. Ask the infrastructure team about their pain points. Synthesize these insights into your solutions.

The Inability to Deliver

\We believe that we are focused on goals when we are actually focused on requirements. A goal is a measured outcome that, for example, improves fast package delivery. We achieve our goals when we improve the capabilities in the system, not by simply adding another feature.

An example for internal platform teams might be: The team is told to migrate their software deployment pipelines from Jenkins to CircleCI. This tells them exactly what to do, but nothing about why they are doing it.

The hidden goal here is to reduce developer toil on pipeline maintenance by fifty percent. Without that information, the team could migrate their software delivery pipelines without meeting the outcomes. They could also have ideas that would deliver the goal without needing a costly pipeline migration!

The capability already exists to deploy changes. This situation is where endless gaps open up in the delivery process. Everyone will have different ideas about how deploying changes should work. And those ideas will cause endless friction if the focus is on changing tools.

The Fix: Focus on Goals

Build goals that are meaningful and coalesce the options for achieving it. Describe a specific and measurable benefit or outcome that is being delivered. Ensure the goal aligns closely to the core domain, to your faster package delivery. All of the system’s capabilities are in service to that goal. Every time we deploy a change, we are (hopefully) improving the system’s ability to do its job. Focusing on goals ensures that everyone contributing understands the value of their contribution.

Go Forth and Experiment

Right now, you might be feeling overwhelmed. "I can’t do all this! I’m already swamped with work!" Truth.

Fortunately, there is no need to do all of this. Pick one thing. One small change that reduces the friction. Whatever interests you most or causes the most friction in your daily life.

That’s how systems work … small changes scale to big improvements. The friction is in the details. So are the fixes.