Skip to main content

Be pragmatic

When Wardley urges leaders to "Be pragmatic", he is warning against fetishising purity over outcomes. There will always be an edge case worth polishing or a bespoke component that looks tempting to build, yet users rarely benefit from the reinvention. Pragmatism means sweating existing assets, using what already works, and reserving precious capacity for the change that truly shifts the map.

Why this doctrine matters​

  • Outcomes over elegance. Delivering what users need matters more than polishing an internal ideal. If an off-the-shelf component meets the need, take it and move on.
  • Challenge bespoke cravings. Every departure from proven components should be justified. Building the perfect tyre rarely helps a taxi service reach more riders.
  • Balance today and tomorrow. Pragmatism makes room to maintain legacy estates while plotting how they evolve, acknowledging that a single rigid approach invites inertia.

Practices to embed​

  1. Map the “good enough” path. Highlight where existing services, COTS products, or shared platforms already meet needs so teams can reuse instead of rebuild.
  2. Record exception triggers. When a team proposes a custom build, capture the evidence and expiry date for that decision so it must be reconfirmed later.
  3. Plan how to sweat assets. Make explicit how long legacy systems will be supported, the safeguards around them, and the signals that allow retirement.
  4. Protect pragmatism culturally. Celebrate teams that choose simplicity over reinvention; make it acceptable to say “the colour of the cat doesn’t matter as long as it catches mice.”

Watch for anti-patterns​

  • Treating every component as a special snowflake and recreating what the market already provides.
  • Allowing temporary exceptions to drift into permanent entropy because no one revisits the decision.
  • Using “pragmatic” as cover for avoiding the hard work of evolving the estate in manageable slices.

Questions to ask​

  • What user outcome are we protecting by bending this rule, and is there a simpler route?
  • Where can we reuse existing capabilities instead of crafting new ones?
  • How will we maintain the current estate while funding the next evolution?
  • Which temporary workarounds need an owner and a review date?

Pragmatism is disciplined realism: keep the mission in sight, question departures from proven components, and move the map with the tools you already have before chasing shiny alternatives.