Building Better Platforms With Empathy

At QCon San Francisco 2023, David Stenglein explored the shift to a product model for internal platforms and how it benefited from people-centric tools like customer empathy and the DevEx framework. This TensorBlue analysis is based on reporting and source material from InfoQ (https://www.infoq.com/articles/building-better-platforms-with-empathy/).

What Happened

InfoQ Homepage Articles Building Better Platforms with Empathy: Case Studies and Counter-Examples

Building Better Platforms with Empathy: Case Studies and Counter-Examples

Empathy is the ability to see experiences from someone else's perspective, sharing their emotions (positive or negative) based on understanding their experience, unlike sympathy which focuses on acknowledging distress.

Organizations adopt platforms to manage the increasing complexity of growth, which strains the DevOps model as security, compliance, performance, and other operational demands create an overwhelming cognitive load on developers.

Building your platform as a product promotes a customer-centric approach. We recognise that internal users have choices and may resort to shadow IT if the platform doesn't meet their needs.

Building a culture of empathy, modeled through open communication and active listening, empowers you to understand users' true needs and fosters leadership from all levels of the organization.

The DevEx framework helps identify key areas for platform improvement by focusing on the interconnected elements of feedback loops, cognitive load, and flow state, ultimately addressing user pain points.

When it comes to platform development, achieving scale often involves absorbing excess cognitive burdens into the platform's framework. An important aspect of constructing these platform

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.