Make work visible
Map workflows, consolidate information, clarify ownership, and create tools that help teams understand what needs attention.
About
A cross-functional operator who turns scattered information, unclear ownership, and messy workflows into practical systems and forward movement.
I started in communications, graphic design, marketing, and community organizing. Work that came down to making complicated things understandable to people who did not have time to decode them.
From there I moved into roles supporting executives and organizations in construction, mortgage lending, manufacturing, supply chain, and customer operations. The titles said administrative support. The work kept turning into something else: documenting a process nobody had written down, building the report that finally showed leadership what was happening, sitting between two departments that had stopped talking to each other and getting the handoff working again.
Somewhere in there I stopped being interested in completing the assigned task and started being interested in why the task existed in that shape. Why the information was three systems away from the person who needed it. Why the same question got asked every week. Why ownership was obvious to everyone until something went wrong. Why good ideas from the people closest to the work almost never reached anyone who could act on them.
That curiosity is the actual through line. It is what I would bring to an operations, systems, project, or improvement role, and it is what this portfolio is built to show.
One more thing worth saying plainly. When I join a team, I do a lap. One on ones with as many people as I can get time with, early, not to make friends, though that is a nice side effect. To understand what each person is actually dealing with. Then I come back around the three month mark, because by then I know enough to ask the questions that are worth asking. If I do not know something, I say so, and then I go find out.
Map workflows, consolidate information, clarify ownership, and create tools that help teams understand what needs attention.
Define scope, owners, dependencies, risks, communication, and launch conditions so complex initiatives do not rely on memory or constant follow up.
Turn scattered knowledge and operational signals into documentation, onboarding, recommendations, and decision ready information.
Working style
Signals I notice first
Work I move toward
How I operate
Design and operations
My background in graphic design and communications is not a separate chapter. It is the reason a process map is readable, a dashboard puts the important thing first, a training guide gets used instead of ignored, and an executive summary fits on one page without losing the argument.
Information hierarchy is an operational skill. When someone has to make a decision quickly, the layout of the information in front of them determines whether they can. I am not applying for design roles. I am saying that knowing how to build something people can read is part of why the systems I build get adopted.
Perspective
Working across these settings means I have seen the same operation from several sides at once: how it feels to the customer waiting on an answer, to the frontline employee working around a broken step, to the project team tracking a dependency, to the operational lead balancing capacity, and to the executive who sees only the summary.
That is where useful pattern recognition comes from, and it is why an unfamiliar system does not slow me down for long.
How this shows up in real work
The case studies on this site are simulations, built so no former employer information appears anywhere. This one is real, described at a level that keeps it that way.
A recurring shipment schedule had a timing mismatch built into it. Product consistently arrived after the window where it would have been most useful, and the same schedule put pressure on another team at exactly the wrong moment. Nobody had flagged it, because it had always run that way and everyone assumed a reason existed.
The fix was not complicated. Change when the shipments went out. What took the work was noticing the pattern, tracing it back far enough to be sure the timing was habit rather than a constraint, and making a case somebody could act on.
That is the shape of most of what I do. The answer is usually simple. Finding the right question is the part that takes effort.
A note on automation and AI
I am interested in automation and AI where they remove work that should never have been manual. I am not interested in adding them because they are available.
That means a human stays in the loop on anything requiring judgment, and governance comes first rather than last. Before deciding what to automate, I want to know who owns the process, which source is authoritative, what happens when the output is wrong, and who reviews it. Those questions are not a hurdle in front of the interesting work. They are the reason the interesting work holds up.