Friction Fix

Friction is the invisible current that sinks every transformation. Friction isn’t one thing– it’s systemic. The fix is changing our patterns of thinking, communicating, and organizing. This TensorBlue analysis is based on reporting and source material from InfoQ (https://www.infoq.com/articles/friction-fix/).

What Happened

InfoQ Homepage Articles The Friction Fix: Change What Matters

Systemic patterns in relationships, communication, and organizational structures are all frictions that create invisible currents that derail work, regardless of tools or frameworks.

Counterintuitive behavior means organizations often solve the wrong problems, adding complexity instead of addressing underlying structures and shared goals.

Over-optimizing for speed and outputs produces brittle systems, while coherence and well-designed relationships across teams create resilience.

Friction arises when roles operate within silos and with fixed mindsets, whereas adopting a growth mindset fosters learning together with deeper insights.

Start small to reduce systemic friction, shifting from adding features to focusing on goals.

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,

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

InfoQ

Implications for Product and Engineering Teams

For TensorBlue readers, the useful question is not just what happened, but how this changes product architecture, engineering priorities, AI delivery, observability, team workflows, or executive decision-making.

• Review whether this changes your AI roadmap, platform architecture, or engineering operating model.
• Identify the specific workflow, reliability, governance, or developer-productivity lesson that applies to your organization.
• Convert the lesson into a small production experiment with measurable quality, latency, cost, adoption, or risk metrics.
• Document source assumptions clearly so teams do not overgeneralize from incomplete public information.

TensorBlue Takeaway

The practical opportunity is to turn this signal into a concrete implementation decision: better AI systems, stronger product instrumentation, more reliable automation, and clearer technical governance. Teams that connect public technology shifts to their own delivery systems will move faster without adding unnecessary complexity.