Michelle Onizuka
The layer people touch.
Software, workflows, and the screens where work either happens or stalls. Twenty years reading operations before touching a tool. If you have talked to Onizuka Studio, you have probably talked to me.
None of it was a plan. All of it turned out to be the same job.
Every step taught me something the next one needed. That is not a career narrative I constructed afterward, it is just what happened, and it is the reason the audit works the way it does.
A puzzle game I was not supposed to be playing
Ocean Software, 1992. You set up a chain reaction and give it one push. It only completes if every piece is in the right place in the right order, and the failure mode is always the same: the right pieces, wrong sequence.
I was thirteen and I remember realising that finding the order was the part I was good at, more than any individual move.
Thirty years later it is the thing clients actually pay for.
Top of the board in telecom
Alltel, then US Cellular, then Verizon. I was good at it from the start and stayed at the top of the board, but the numbers were never the useful part.
The useful part was learning that what somebody asks for and what they actually need are two different sentences, and the second one is the one worth answering. You cannot sell well without hearing the second one.
Owners rarely describe the real problem. They describe the symptom that annoyed them most this week.
Paralegal certification
Dean’s list, president’s honours, and I founded the student chapter. What stuck was not the law. It was the habit of reading a rule closely enough to find the part everyone assumed was closed.
There is a difference between can’t be done and can’t be done that way. Almost everything I get hired for lives in that gap.
The bridge between the client and the developer
Michael writes the code. For more than a decade I have been the person in the middle: turning what an owner says into something a developer can build, and turning what a developer says into something an owner can decide on.
Websites, then web applications. Michael wrote the code, I owned the conversation on both sides of it.
The questions changed
Clients stopped asking about the site and started asking about what happened after somebody filled out the form. Where does that go. Who retypes it. Why does the office still keep a spreadsheet of the same thing.
My job shifted from project managing builds to architecting the internal systems underneath them — Zoho platforms first, then standalone applications when the thing a business needed did not exist for sale.
Nobody announced the shift. The questions just stopped being about the website.
Technical systems architect
The one who sees what others miss. Not because of a certification, but because every step before this one was practice at the same skill: hearing the real problem underneath the stated one, and working out what has to happen first.
That is where the audit came from. It is the same conversation I have been having for over a decade, written down and made repeatable.
Read the operation before touching a tool.
You tell me how your business runs. I mold the tech around it.
I do not work alone, and the split is the point.
I read the layer people use. Michael reads the layer it sits on: servers, infrastructure, deployment, and where the data actually lives. Between the two, nothing in a business falls outside the exam, and neither of us has to guess about the other half.
Read something before you talk to anybody.
Over a hundred published articles on how business systems actually break, industry by industry. Or take the free scan and see what comes back.