Friction is the core obstacle in software systems
You might think your biggest challenges in software are technical, cloud architecture, deployment tools, or frameworks. That’s not the problem. The real issue is friction. Not friction between machines, between people. Communication breakdowns. Misaligned priorities. Conflicting incentives. These are the factors that quietly erode execution and derail transformation.
This type of friction is systemic. It lives in your organization charts, your processes, your mental models. Tech teams and product teams blame each other for failure, while large initiatives move forward with impressive dashboards, until they don’t. The project collapses, you perform a retrospective, and then you do it again. This cycle doesn’t stop until friction is addressed at the root.
What’s required is to change the way your teams think and operate. That includes how information flows, how decisions are made, and how problems are defined. You can’t solve execution risk or delivery challenges by forcing more features through. You solve it by reducing the drag created by miscommunication, misalignment, and outdated structural incentives.
Cat Morris, a Product Manager, and Diana Montalion, a Systems Architect, explored this problem through direct experience. They brought opposing perspectives, and found the problem wasn’t each other. The problem was the system they were trying to navigate. Their roles overlapped in unexpected ways. Coming together aligned results and eliminated waste. That’s a lesson for all tech leaders: the enemy isn’t on the organization chart. It’s in your operating patterns.
Counterintuitive behavior derails progress
When projects go off track, teams react fast. They add engineers, extend deadlines, and increase oversight. This feels like action, but it often makes the problem worse. That’s what systems expert Jay Forrester described as “counterintuitive behavior.” The solution appears obvious but intensifies the actual problem.
This shows up when technical timelines slip. The default assumption? The team is underperforming. Or the schedule was too aggressive. But the real issue might be that the system is delivering exactly the result it’s designed for. W. Edwards Deming said it clearly: “Every system is perfectly designed to get the result it does.”
That’s the trap. Leaders respond based on symptoms. They rarely pause to examine whether the structure itself is producing failure. If the plan is built on poor assumptions or incompatible models, like forcing a linear delivery model on a non-linear system, no amount of urgency will fix it.
So here’s the move: step back. Align everyone on the actual mission, call it your North Star. For FedEx, that would be delivery speed. In tech, maybe it’s deployment reliability or reduced customer friction. Then trace how your current system fails to support that goal. Look at how decisions are made, how teams are connected, and how progress is measured. Is data flowing in real-time? Are feedback loops in place? Are people solving the right problem?
If not, you’ve got invisible blockers orchestrating visible failure. And you can’t out-engineer that. You need clearer thinking, better structure, and systems that reinforce outcomes, not cycles of misdiagnosed effort. That’s how you stop reacting and start fixing.
Resistance to change stems from cultural inertia
In almost every company trying to improve, there’s someone slowing things down. They’re experienced, know the legacy systems inside and out, and hold the keys to critical infrastructure. They’ve seen re-platforming efforts fail. They’ve survived multiple reorganizations. So they say no, to new approaches, new tools, new thinking. It’s easy to point a finger and call them resistant. But they’re just reacting to the system that empowered them.
Their resistance has been rewarded. These individuals become indispensable not because they support innovation, but because they manage complexity. When your organization defines value based on who can “keep things running,” not who can improve systems, you end up protecting the status quo. The result is a mindset that favors caution over curiosity, and you stop hearing new ideas because the people with those ideas stop bothering.
The more dangerous part? This mindset spreads. One gatekeeper creates a silent momentum: others begin to avoid uncertainty. Entire teams move from asking “What could work?” to “Why try at all?” When old patterns dominate, transformation halts, not because there wasn’t a strategy, but because the system shut down the people who wanted to implement it.
John Belasco and Ralph Stayer wrote about this in their book Flight of the Buffalo. They put it bluntly: “Change is hard because people overestimate the value of what they have and underestimate what they may gain by giving it up.” That’s a psychological barrier, not a technical one. And it needs to be treated at the system level, not just corrected at the individual level.
If you’re leading change, don’t waste cycles convincing blockers to move. Give them a space where they can maintain stability without controlling transformation. Then, shift energy toward the teams that are ready to move. Let them show results. Change is rarely convincing in theory. It’s proven through momentum.
Efficiency and control can undermine true value
Most organizations default to efficiency as the north star. It makes things predictable. You count features delivered. You track story points closed. You hold teams to timelines. It feels like progress. But what often gets lost in this process is actual value.
When work becomes output-driven, focused on productivity metrics, you end up optimizing for motion. Teams are under pressure to hit deadlines, not to rethink whether the work is solving anything important. So you build fast, but what you deliver might not matter to customers or to the business. That disconnect is what creates long-term inefficiency, even when your short-term metrics look good.
Control also contributes to this. The tighter you try to control delivery, the more you limit the flow of important information across teams. Questions don’t get asked. Trade-offs don’t get surfaced. Feedback arrives too late. You mistake alignment for silence. And when real complexity appears, the system has no flexibility. It can’t adapt.
At a system level, what you want is coherence, not just control. You want the right data moving to the right people, at the right time, with clarity, so teams can act intelligently, not just quickly. That means rethinking the tools you use to measure progress. Ask whether your teams are solving for outcomes, or just updating dashboards.
If your roadmap is locked and your deadlines don’t reflect reality, step back. Optimize for knowledge flow, across disciplines, across mental models. That’s what actually accelerates meaningful delivery. When you understand how work contributes to business goals, you waste less time and deliver more real value.
Product and tech silos aggravate friction
This is a common pattern: product teams want new features shipped quickly, and engineering teams feel like they’re being asked to deliver rushed, low-quality code. Neither side is inherently wrong. They just operate under different pressures and definitions of what progress looks like. That tension, when unmanaged, becomes one of your biggest bottlenecks.
Product teams are accountable for customer outcomes. They push timelines and prioritize user impact. Engineering teams are accountable for system integrity. They push back on fragile code, technical debt, and poor architecture. When these two roles operate in isolation, collaboration turns into blame. You don’t get alignment. You get arguments over scope, feasibility, and why something took longer than expected.
The bigger issue isn’t the disagreement, it’s that both teams are stuck in a fixed mindset. They assume the other side doesn’t understand, so they stop trying to build mutual understanding. No shared goals. No shared success. That creates brittle teams, where learning is replaced by territorial defense.
The way forward isn’t more process. It’s adopting what Dr. Carol Dweck calls a growth mindset, across roles and teams. This means focusing on problems to be solved, not just tasks to be delivered. It means interpreting pushback as context, not conflict. It means encouraging teams to reflect on what’s working and course-correct without blame.
When people understand each other’s goals, they stop seeing collaboration as a tradeoff. Product learns to appreciate long-term technical health. Engineering connects their work to short-term business value. That’s the shift. Not just getting along, thinking together. That’s where resilience starts.
Linear pipeline thinking fails in an asynchronous world
A lot of delivery frameworks operate on the assumption that work flows in a straight line. Plan, design, build, test, launch. But in today’s systems, where teams rely on distributed services, APIs, and microservices, very little actually happens in a straight line. The work isn’t sequential. It’s interconnected, event-driven, and asynchronous.
Here’s what that means in practice: issues often don’t originate from one component, they emerge from the interaction between components. That’s why debugging gets harder. The system now behaves based on its relationships, not just its parts. So when delivery models are built on purely linear frameworks, they exclude the very complexity they need to manage.
You can’t model modern systems effectively without including synthesis, bringing together multiple perspectives across roles, teams, and platforms. Architects, developers, infrastructure, security, and product must collaborate to understand how different parts of the system influence performance, reliability, and user experience. These aren’t isolated concerns. They’re joint responsibilities.
This shift requires teams to think in terms of relationships, how services communicate, how data flows, how changes ripple through the system. If you ignore those dependencies, problems get hidden until they hit production. At that point, the cost of correction is high.
Executives should support the design of systems, not just software, but organizational systems, where information moves clearly between teams. Cross-functional insight has to be part of the development process. If your operating model silos responsibility, your architecture will replicate that silo in code. And the result is fragile delivery, slow incident recovery, and limited adaptability.
Don’t optimize for the illusion of linearity. Optimize for clear relationships. That’s how you stop delivery problems before they scale.
Delivery failures result from focusing on tools instead of goals
Teams often get assigned a task, migrate to a new platform, replace a legacy tool, implement some off-the-shelf system. But they’re rarely told why. Without a clear purpose, they follow instructions, check the box, and move on. Whether or not the work improves anything becomes irrelevant, because outcomes weren’t defined at the start.
This is one of the core reasons delivery fails. When execution is framed around activity instead of intent, your organization starts optimizing for project completion rather than business value. A team might execute all planned tasks, yet the result doesn’t improve system performance or user satisfaction. Time and money are spent, and yet capability remains unchanged.
To fix this, you need to clarify the goal before the work even starts. A goal is not a task. It’s a measurable outcome tied to core business priorities. For example, if you say you want to move from Jenkins to CircleCI, that’s a task. But if your actual objective is to reduce developer toil, then the migration is only one option. Teams might find better alternatives, less costly, more effective, if they understand the end result you’re aiming for.
Outcomes-focused execution also avoids misalignment across stakeholders. When engineers, product teams, and executives all know what impact they’re working toward, they make better decisions. They prioritize based on contribution to that impact, not just completion of assigned effort. That leads to faster iterations, more relevant solutions, and systems that evolve toward business goals instead of just modernizing infrastructure for its own sake.
Your role as an executive is to ensure the objective is visible, precise, and connected directly to meaningful returns. When that happens, your teams stop merely executing work, they start driving value.
Small, intentional experimentation drives systemic improvement
The complexity of modern systems can be overwhelming, especially when friction appears everywhere, from coordination to technology to delivery breakdowns. It’s tempting to look for an overhaul, to realign everything in one bold move. That approach rarely delivers. The better move is smaller, intentional experimentation.
You don’t improve a system by replacing every piece. You improve it by making thoughtful changes, observing results, and adjusting in real time. These experiments don’t need to be massive. They need to be specific enough to reveal where friction lives and how your teams react when that friction is removed. This gives you clarity without risking unnecessary disruption.
This approach also respects limited capacity. Teams are already under pressure. You don’t need to add more chaos. You need to help them focus on one constraint, one inefficiency, one pattern that’s not working. When that changes, the feedback helps inform broader decisions. Momentum builds naturally, not artificially.
As a leader, your job is to give permission and support for these kinds of changes. Let a team challenge a handoff process. Let a product manager redefine success criteria for a feature rollout. Let an architect introduce better knowledge flow across functions. Start small. Measure impact. Share results.
That’s how system transformation gets done, when teams are empowered to think, adapt, and lead improvements based on what they see daily. Every friction removed compounds over time. You don’t need top-down mandates. You need smart, committed people focused on fixing what they’re best positioned to understand. Empowering them is the strategy.
Recap
If you’re leading a company that builds anything with software, take a step back and ask where the real blockers are. Chances are, they’re not in your tools. They’re in how your teams communicate, how roles are structured, and how decisions get made. These aren’t flaws, they’re signals. They show you where to focus if you want stronger systems and faster outcomes.
Friction happens when systems aren’t aligned with how people actually work. Fixing that doesn’t mean tearing everything down. It means removing barriers that slow your teams down. It means structuring around shared goals instead of isolated output. It means creating space for learning, synthesis, and smarter execution.
Your advantage isn’t in having the latest platform or the biggest headcount. It’s in how effectively your organization adapts to complexity, how quickly your people can make the right decisions, ship meaningful changes, and evolve with the needs of the system.
You don’t need to control every detail. You need to design the conditions where the right things happen without you micromanaging them. That’s how you scale. That’s how you get speed without chaos. Strip out the friction, and progress stops being hard. It just becomes the next thing that happens.
