Tooling as a Substitute for Practice

When a team can’t get the behavior it wants, the cheap move is to configure the tool to force it: required fields, mandatory workflow states, permission schemes that make the wrong thing impossible. A required root-cause field stands in for an actual retrospective; a twelve-state workflow stands in for a conversation about how work really flows. The discipline now lives in the configuration instead of the team, which means it stops evolving the moment the admin who built it moves on. Multiply that across an organization where every group tunes its own instance and you get a system nobody can read: to understand how work happens, you have to learn each tribe’s local customs, one configuration at a time.

We treat heavy tool customization as a diagnostic. Every screen of custom fields is a practice conversation that didn’t happen. The fix runs backward from the configuration: name the practice you actually want, get real agreement on it (working agreements beat required fields), then strip the tooling down to the minimum that supports it, in the spirit of process minimalism. In one engagement, twelve competing custom “team” fields and hundreds of stale schemes were doing the work that a handful of shared practices should have been doing, and teams had quietly stopped using the tool’s core functionality to escape the demands of the configuration. If you’re looking for salvation, the ticket system is the wrong altar.

Resources

• Process Minimalism — the counter-stance: the least process (and tooling) that works
• By What Method — Deming’s question; a required field is not a method
• From Tooling Sprawl to Product Alignment — the anti-pattern at organizational scale, and the way out