I build the rules into the system, so nobody has to enforce them by hand.
I work between operations, product, and engineering. Most of what I do is turning a policy that lives in someone's head, or a spreadsheet, into something the software checks on its own.
selected work
Attendance and utilization tracking
workforce systemsAn end-to-end attendance system with enforced dependencies: submitting a timesheet is what unlocks the next workflow, so compliance stops being something managers chase. Activity tracking is configurable to handle teams running several service streams at once.
Overtime governance
process governanceOvertime tracking with validation that runs before approval, not after. It replaced spreadsheet tracking and ad-hoc sign-off, so a request that breaks policy gets caught at the point it's filed instead of surfacing later as a payroll problem.
Operations dashboard
data reportingReporting that lets leadership look across teams, clients, and timeframes at the same time. I defined the metrics and the data model and worked with engineering on the build, including the caching and fetching strategy that keeps it fast under load.
Workflow standardization
operational designMapped and redesigned workflows that had drifted apart across operations, HR, and finance. The operational intent became system logic: validations, role-based access, and step sequences that have to happen in order.
how I work
- Systems thinkingI design for the dependencies and edge cases, not just the path where everything goes right.
- Problem definition firstBreaking a vague problem into solvable pieces is usually the hardest part, and where most of the value is.
- Data-informedI go by what people actually do in the system, not what we assumed they would do.
- Influence without authorityGetting operations, product, HR, finance, and engineering to agree is a design problem, not a reporting-line problem.
- Self-sustaining solutionsA fix that needs someone watching it isn't finished. The system should enforce its own rules.