Six things a recruiter or hiring manager would reasonably want to know. Where there is a real gap, it is stated as a gap rather than answered around.
My role was eliminated in a layoff on 28 August 2026. I am formally employed until 26 October and available immediately after — in practice, now.
That is the whole answer. I would rather you had it here than work it out from the date on my experience table.
Correct, and it is worth being exact about it: no direct reports, ever. I have never owned a performance cycle and never made a hiring decision that was mine to make. Against a requirement for five years of managing designers, the honest number is zero.
What I have instead is a long record of getting design quality out of people under no obligation to give it to me — eleven vendors across four cities in my twenties, and five designers working on and against a platform I did not design all of. One of the three designers I coached has since been promoted to Senior.
Mostly true. SSE, ZTNA, cloud firewall and reporting since 2022; networking security before that.
The parts that transfer are the parts you would be hiring for. Writing documentation a machine can build from is not security-specific. Neither is proving a system still holds after a model has touched it, nor getting it used by people who do not report to you. The field test is built on a deliberately generic system, rebuilt in a clean room so the method can be checked without anything proprietary in it.
And one piece is conventional product design with no AI in it at all: a layout argument I made against my own team’s preference, tested with 43 participants, now a filed US patent.
Yes. I would rather say it than have you find it.
The move from about 25% to 90% on-system was measured by me, on a system whose guidelines I wrote, judged by me, with no control group and no blind rater. It is a practitioner’s measurement, not a study. The forward-looking part of the cost model also assumes the system keeps working without me, which is untested since I left.
What I can offer instead of trust is that the method is public and reproducible. I rebuilt it from scratch on a generic system so anyone can re-run it — and doing that proved one of my own published claims wrong about why it worked. I published that too.
The cost case, with its concessions → The claim that failed →
Build. The bulk-edit component on this site is a working web component with 53 passing tests and a public repository — you can operate it in the page rather than look at a screenshot of one. The field-test rig runs. This site is hand-written HTML with no build step.
What I am not is a production front-end engineer. I write code that settles a design question or removes a handoff, not code that ships to your customers. If the role needs the second thing, I am the wrong hire, and I would rather say so now than in week three.
Measure before changing anything. The number I would want first is what it currently costs to produce one correct screen, end to end — because most arguments about a design system turn out to be arguments about that number, and most teams do not have it.
Then I would hand you the unit rather than my total. On the last system, making the rules machine-readable returned roughly 3.9 hours per designed screen. Multiply that by your volume, not mine. A number you work out yourself is one you believe; a number I work out for you is a pitch.
The honest caveat that travels with it: unit economics improve with scale, but execution risk grows with it. At forty designers, adoption variance becomes the dominant term and I have not measured it.
Anything not answered here is worth an email — omkarpkh@gmail.com.