Rewriting
How We Work

The shape of the work

Companies don’t get AI transformation by buying a tool. They get it by redefining, at close range, what design does, what engineering does, what research does, and where the seams between them sit. That redefinition is a design problem in its own right — and it’s the one my working group is running.

I sit in the design seat of that group. What I contribute is not policy — it’s evidence, framing, and working examples of what the new PDLC actually looks like when the team runs it end-to-end.

• Cross-functional working group. Every role in the product development lifecycle has representatives at the table. The mandate is company-wide: propose, pilot, and roll out the new ways of working that AI tooling makes possible — and identify what it removes from the table.
• Design’s contribution is upstream of policy. I don’t write the policy. I bring the working examples the policy has to reconcile with — the actual prototype built in an evening, the actual skill saving a team hours, the actual gap between what an AI tool can do and what a product decision needs it to do.
• Design × engineering vocabulary. A meaningful share of the work is translation. Design speaks in intent, edge cases, and journey; engineering speaks in interfaces, invariants, and tests. AI tooling sits on the seam. Bridging the two vocabularies — carefully, at the level of concrete artifacts — is where a lot of the value shows up.

Three roles I hold in the room

Not officially — informally. These are the three modes I move between across the working group.

Still finding the shape

This is work in progress — the playbook isn’t finished, it’s being written by the work we actually ship. What I’m certain of, and what I keep pushing for in the room, is that trying, failing, and iterating beats holding out for the perfect approach up front.

The perfect approach, if it turns up, will be the version we’ve already run three times and edited twice.