ABOUT
I’m most useful in the space between teams.
I’ve spent most of my career working on problems that didn’t belong neatly to one function. At DoorDash, my work often sat between Strategy & Operations, Product and Engineering, Analytics, QA, and frontline vendor operations.
Each group saw a different part of the system. I became most useful by understanding how those pieces interacted—and then designing the processes, data, tooling, automation, and decision logic that helped them work together.
HOW I GOT HERE
Operations was the starting point.
Systems became the through-line.
I spent approximately six years at DoorDash, working across Merchant Services, New Verticals and Catalog, Vendor Management Operations, and a Strategy & Operations secondment.
My formal roles were rooted in operations, but the work increasingly pulled me toward systems.
I found myself repeatedly asking questions like:
· Why does this process require so much coordination?
· What information is missing when people make this decision?
· Why are two teams interpreting the same rule differently?
· What does this metric actually measure?
· Which parts of this workflow require judgment—and which are just repetitive?
· What breaks when this process grows 10×?
· Could the system prevent this problem instead of asking people to remember not to create it?
Those questions became the through-line of my work.
THE WORK I GRAVITATE TOWARD
I like problems with enough ambiguity to need design, not just execution.
AMBIGUOUS
I’m drawn to work where the problem is real, but the path forward has not already been defined.
CROSS-FUNCTIONAL
The interesting work usually lives between teams, where ownership, incentives, data, and execution intersect.
OPERATIONAL
I like systems that have to survive real users, edge cases, deadlines, handoffs, and imperfect information.
SYSTEMS-ORIENTED
I naturally look for the rules, dependencies, feedback loops, and interfaces underneath the visible process.
BUILDABLE
I’m most energized when there is something tangible to design, launch, test, and improve.
HOW I THINK ABOUT OPERATIONS
Operations is a design problem.
A workflow is more than a sequence of tasks.
It is a collection of rules, dependencies, handoffs, exceptions, incentives, decisions, and feedback loops.
When a process struggles, I try not to start with “How do we make people work faster?”
I start with:
What is the system asking people to do — and why is it hard?
That changes the solution space.
Sometimes the answer is automation. Sometimes it’s clearer ownership, better documentation, different metrics, stronger controls, or redesigning where human judgment enters the process.
RULES
OWNERSHIP
DATA
DECISIONS
EXCEPTIONS
FEEDBACK
Design the layer between the people and the outcome.
The goal isn’t automation for its own sake. It’s a system that works better.
HOW I USE AUTOMATION + AI
Where does human judgment actually add value?
I don’t think the goal is to automate as much as possible. I think the goal is to automate the parts that benefit from consistency, speed, and scale—while keeping consequential judgment with the people best equipped to make it.
SYSTEM HANDLES
Repetitive processing
Data normalization
Validation + checks
Routing + prioritization
Pattern detection
Draft generation
HUMAN OWNS
Interpretation
Ambiguous decisions
Tradeoffs
Accountability
Final approval
Context-sensitive judgment
Automate the processing. Preserve the judgment.
SYSTEM ↔ HUMAN
HOW I BUILD
I like building in iterations.
I rarely expect the first version of a system to be the final one. I prefer to solve the most important problem first, put the system into real use, and let the next bottleneck reveal what should change.
UNDERSTAND
Find the real constraint
SOLVE
Build the useful first version
USE
Put it into the workflow
OBSERVE
See what breaks next
IMPROVE
Refine the system
Real usage is part of the design process.
The best systems I’ve built became better because people used them—not because every edge case was perfectly anticipated in V1.
THE ROLE I TEND TO PLAY
I translate between the people who define the problem and the people who make the system work.
Different teams usually see different parts of the same problem. I tend to sit in the middle—connecting business goals, frontline reality, data, quality, and technical constraints into something everyone can act on.
STRATEGY & OPERATIONS
What problem are we solving?
Goals, tradeoffs, operating requirements
FRONTLINE / VENDOR OPS
How does the work actually happen?
Constraints, edge cases, workflow reality
ANALYTICS
What does the data tell us?
Signals, definitions, decision support
PRODUCT / ENGINEERING
What should the system enable?
Requirements, rules, automation opportunities
QA
How do we know it works?
Standards, thresholds, feedback loops
LEADERSHIP
What does this mean for the business?
Risk, performance, scale, and impact
My role is often to make the system legible across functions.
That usually means turning ambiguity into shared rules, clearer decisions, and an operating model people can actually use.
WHAT I BRING
A systems mindset with an operator’s bias toward making things work.
SYSTEMS THINKING
I look for the rules, dependencies, constraints, and feedback loops underneath the visible workflow.
ZERO-TO-ONE BUILDING
I’m strongest when there is something new to define, launch, test, and improve.
OPERATIONAL EMPATHY
I care about how systems actually feel to the people using them—not just how they look on paper.
ANALYTICAL RIGOR
I use data to clarify the problem, validate assumptions, and focus attention where it matters.
PRACTICAL AUTOMATION
I automate repetitive work when it improves speed, consistency, or scale without removing accountability.
CROSS-FUNCTIONAL TRANSLATION
I connect business goals, frontline reality, data, quality, and technical constraints.
DECISION DESIGN
I turn implicit judgment into clearer criteria, thresholds, and escalation paths.
ITERATIVE IMPROVEMENT
I expect real usage to reveal the next bottleneck and use that feedback to refine the system.
I’m not trying to be the deepest specialist in every layer. I’m most valuable when those layers need to work together.
WHAT I'M LOOKING FOR
The title matters less to me than the shape of the problem.
I’m most interested in roles where ambiguous, cross-functional work needs to become a system people can actually operate.
I’m especially drawn to environments where there’s room to build—not just maintain—and where operations, product, data, automation, or AI intersect.
Business & Strategy Operations · Product Operations · AI Enablement · Strategic Programs · Systems & Automation
I care more about the opportunity to clarify, build, and improve than fitting neatly into one function.
OUTSIDE THE JOB DESCRIPTION
I tend to build systems even when no one asks me to.
The same instinct shows up outside of formal work. When I run into a repetitive decision, fragmented information, or a process that feels harder than it should be, I usually start wondering whether I can design something better.
A RECENT EXAMPLE
AI Job Search OS
During my own job search, I built an AI-assisted system to consolidate recommendations, normalize missing information, remove duplicates, evaluate roles against an explicit framework, and generate tailored application materials for human review.
SOURCES
CLEAN + ENRICH
EVALUATE
HUMAN REVIEW
HUMAN APPROVAL
For me, curiosity usually turns into a workflow.
I like learning by building something useful enough to expose the next question.
FEATURED CASE STUDY
Match Tool
Designing the human system around the model.