Jason Robin Dyck
How I work
I keep this page for the same reason I keep documentation with what I build: so the people who work with me know what to expect. The short version is that I chase leverage. The rest is what that looks like in practice.
What drives me
Leverage on leverage. I don't optimize the task; I optimize the thing that produces the tasks, and when I find the multiplier I stand on it.
I learned that at my first software job, at a genomics company. I spent years supporting and teaching a platform that handed hours back to lab scientists, and those hours went into their research. Some of our customer labs were early cancer and disease detection groups, so an hour returned there was worth more than any hour I could have spent directly. That trade has been the point ever since.
Same job, smaller scale: I turned one-off training prep into reusable packages, and per-customer prep dropped from about a week to one or two days. The pattern has repeated in role after role. My recurring product is the operating system a team runs on, and useful is the standard I hold it to. Useful points at your problem, not my magnitude.
How I build and enable
I work at the intersection of three lanes that usually come separately: the builder who uses the tools daily, the systems designer who turns what works into scaffolding other people can run on their own, and the trained coach.
On a BC government modernization program, I collaborated with the program's Scrum Masters to replace the all-teams sprint review with smaller live reviews scoped to each team's stakeholders, recorded for anyone who missed them. Overall meeting time fell by about half against a ceremony running 150 to 300 person-hours, engagement went up, and the live review started earning its place again. At a Big Four firm (EY) I led two Microsoft 365 Copilot adoption cohorts and handed copies of the methods that worked to the peer cohort leaders. I also rebuilt a manual program intake as an AI-assisted flow, designed so teams could move through it with far less live facilitation. The team adopted parts of it.
The test my systems have to pass is whether they keep working without me. The team health check I built for my own Scrum teams passed it: the program's other Scrum Masters picked it up, and it outlived my time there.
Tools and rituals
Claude and Claude Code are my daily tools, in a terminal, across my three machines, extended with agent skills and MCP servers, including a personal memory system I built. I'm mapping my whole build system onto Claude Cowork. As of July 2026 I've built 21 orchestrated agent workflows, and 14 of them run today. They cover software delivery, content generation, and research.
Quality gets its own machinery, because that is where the leverage compounds: better machinery raises every draft, while polish raises one. Before I trust a draft, AI reviewers grade it against strict rubrics that can fail it outright, and every plan is challenged by nine reviewers running on different models, capped at four rounds so review can't spin forever.
Where AI fits
In late 2025 I published the frame I still work by: the bottleneck isn't generation anymore, it's discernment. Anyone can produce output now. The scarce skill is evaluating it.
AI will sometimes get things wrong, so I build the catching systems, with a human decision at the end that nothing gets to skip. My own fleet runs the same way: every output is gated and measured before it goes anywhere, and I approve every word published under my name. That includes this page.
If you're interested in learning more, I love giving the tour.