Back to Blog & resources
Podcast

Process Debt Swamps Platform Teams, A Conversation with Mark Fussell, SPaMCAST 879

Mark Fussell dives into a challenge that’s becoming increasingly common in modern engineering organizations: process debt — and how it’s quietly overwhelming platform teams.

In episode 879 of the Software Process and Measurement Cast, host Tom Cagley explores why process debt — not just technical debt — is increasingly slowing down platform teams. Joining him is Mark Fussell, CEO of Diagrid and co-founder of Dapr, who brings decades of experience building resilient, scalable systems across the cloud-native landscape. Their conversation reveals a key message:

Complexity creeps in quietly — through abstraction, process, and patterns — and platform teams feel it first.

What Is a Platform?

Mark defines a platform as a layer of abstraction that gives developers just enough control to build their applications without handling the underlying complexity. That can range from operating systems to Kubernetes to cloud providers — or even Salesforce.

Platforms, he argues, exist to hide what you don’t want to care about and expose only what you need.  

The Rise of Process Debt

Platform engineering has emerged because organizations started building many services, both internally and externally. Without shared tools and patterns, teams reinvented processes over and over — messaging, deployment, security, telemetry, testing — creating duplicated effort and fragmented complexity.  

Process debt accumulates when:

  • Each team invents its own pipeline or messaging layer
  • Approval workflows balloon over time
  • Architecture decisions are made early — then hard to undo
  • Choices are made for today, not for evolution

Mark puts it simply: software is evolution — it changes over time. Processes must evolve with it, or teams get stuck.  

A Real Example: FICO’s Messaging Migration

Mark shares the story of FICO, which originally adopted Kafka as its messaging system — until they hit scale limitations. Switching to Apache Pulsar meant rewriting large parts of their architecture… until they instead adopted Dapr.

Using Dapr’s messaging abstraction layer, they swapped infrastructure without rewriting application code — saving months of work and reducing long-term process debt.  

Common Patterns, Not Custom Code

Mark advocates for treating platform architecture like Lego blocks, not raw materials. You shouldn’t build steel from scratch just because you’re building a bridge.  

Reusing software patterns, especially through open-source tools like Dapr, enables:

  • Built-in resiliency
  • Built-in telemetry
  • Built-in security
  • 30–40% faster delivery to production (based on real studies)  

What About AI?

AI already supports areas like code review and automation — but Mark warns against relying too heavily on AI-generated code. The risk? Poor-quality code becomes part of the training data, creating a feedback loop of mediocrity. Security concerns may follow.  

Final Thought

Platform engineering is more than tooling — it’s strategy with empathy. Teams must create leverage, not just layers. As Mark puts it, success comes when platforms give developers freedom without giving them chaos.