I’ve been thinking a lot about how we talk about repair in the context of delivery in software building.

Thinking a lot about the exercise of ‘repair’ and how too often, the conversations always devolve into what we’re building, what we’re designing, and not what we’re fixing or maintaining. I’m constantly reworking and iterating on how we talk about “the work” and this framing is often absent.

I’m constantly A/B testing titles on various social platforms. I remember two of my more intrepid friends noticing this years ago, back when Twitter was still in vogue, and I thought it was hilarious, because it never occurred to me that anyone was paying attention to this.

I explained to them that I’m mostly seeking clarity in a world that lacks it. So much of the work we do, especially working in “tech,” devolves into a kind of jargon that makes sense in context to us, but not to anyone else. It’s especially funny when you deal with people who work across fields, when we have to detassle our jargon between our sectors.

“Oh RPG means this to you? For us it means that.”

This isn’t uncommon. The thing I find interesting is trying to define my own goals. I started writing this a month ago and I’m just getting back to it now.

In building this idea, I reflected on a lot of what I’m seeing (on microblogs) with would-be experts, often from Product Management, talking about the right way to build things without a semblance of consideration into whether we’re actually building the right things—all while lamenting how designers ask too many questions or needlessly slow things down because their creative brains don’t understand “strategy” as defined by someone whose only difference from a cubicle dweller with a PMP certification is $60k, stock options, and Jira access.

//rant over//

I’ve been playing around with all sorts of reframing of work, lately thinking about “deterrence” as a practice alongside design, product, and engineering—as a proactive way to think about repair work. All the red-teaming in the world, no matter how much “trust & safety” you have nibbling around the edges, what we lack is still internal thinking around the management of fixing what needs fixing.

How we evolve this kind of relies on the same shorthand that made Shopify flatten its design titles away from specifics, but their reasoning was naturally aimed more at diminishing the technical capabilities of designers than anything benevolent.