Most recently I was SVP of Supply Chain at a private-equity-backed national distributor, with six direct reports, about 195 people, and accountability for transportation, DC operations, planning and procurement across eight warehouses.
Having all four of those under one roof mattered more than it sounds. I was deciding how much to buy while also owning what it cost to move and where it had to sit. In most companies those sit with three different executives, which is exactly why placement decisions go unmade.
Before that I spent five-plus years at a high-growth food and beverage business that made nothing in-house. Everything ran through co-manufacturers and co-packers, so I was planning against capacity I didn't own and schedules I could influence but not set, often buying raw and packaging materials on the co-man's behalf, with a bill of materials that had to line up across three companies before a single run happened. Minimum runs that dwarfed a month of demand, shelf life and date codes, lot traceability, promotions that showed up as a forecast and left as a writeoff, retailer and distributor channels that each behaved differently.
The mechanics looked nothing like distribution. The failure was identical: too many hands on the number, and nothing producing it.
That's why I think this work travels. Whether what binds you is a co-man's line time, a shelf-life clock, a vendor's lead time or a dock, I end up asking the same question — does the plan come out of a system everyone trusts, or out of a meeting?
The process half
Most of that job wasn't technical at all. I was building the SIOP cadence, holding the monthly reviews, refereeing between sales and planning, and defending the numbers to a board. That was the third time I'd stood up a SIOP process end to end, in three organizations that operated very differently from each other.
That's the work that changes how a company decides, and it's the work I'd do first at any client. It's also the work that's hardest to hire for, because it isn't a methodology you can deploy. It's sitting in the room every month until the discipline holds, and being the person who says out loud that the override made in March didn't work out.
I've also led three out-of-the-box planning implementations end to end: ToolsGroup, Netstock and E2open. I say that early because my views on licensed platforms could otherwise sound like a grudge, and they aren't. I've run the selection, run the implementation, and been the one accountable for the go-live, three times over. It's also how I know the software is rarely what's holding a company back. All three went live. The ones that actually changed how the company decided were the ones where somebody did the definitional and process work alongside the configuration, and that work almost never appears in a statement of work.
It also means I can read a vendor demo the way the vendor reads it. I know which gaps are configuration, which are integration effort nobody has scoped yet, and which are the product's underlying model of how planning works — the third kind doesn't get fixed, and it's the one that sinks implementations eighteen months in.
The build half
The second half is the unusual one. The planning engine, the buyer workbench, the demand toolkit, the warehouse data model, the automated external feeds, the executive reporting — I designed and wrote those myself, in Python and SQL. They weren't requirements I handed to a vendor.
That closes the gap where most supply chain projects die: between the person who understands the operating problem and the person who can build the thing that solves it. In a normal project those are two people, an intermediary document, and six weeks of round trips. Here they're the same person, which is why a working system can exist in eight to sixteen weeks rather than eighteen months.
It also means I know what a real ERP looks like underneath — the fields nobody populates, the flags that mean something different in each branch, and the reports everyone quietly distrusts and rebuilds by hand. You cannot learn that from documentation. You learn it by writing the query that returns something obviously wrong and then finding out why.
Two parts of that are worth calling out, because people don't expect them from an operator. The first is optimization modeling: I formulate network decisions as mixed-integer programs and solve them in Gurobi. Freight lane and carrier assignment, co-manufacturer sourcing allocation, inventory deployment across nodes, and the facility-location question of which sites should exist and which customers each should serve. These are the decisions big enough that a sorted spreadsheet gives you a workable answer and no idea how far off the best one you are.
The second is KPI frameworks and reporting platforms. That starts with the definitional work — pinning down what each metric means, at what grain, from what source — then the dimensional model underneath it and the architecture on top. I'll use Tableau or Power BI where a company already has the licence and the appetite to self-serve, and Streamlit where what they actually need is an application somebody works inside rather than a dashboard they look at. Then somebody has to own it. I've stood up and funded a team to do that, because a platform without an owner decays.
How I work
Three things you should know before hiring me, because they're the ones that would make me a bad fit for some engagements:
I'll tell you if there's nothing here. The diagnostic is fixed-fee specifically so that finding a small opportunity isn't a commercial problem for me. If you're already disciplined, the readout will say so.
I don't do process without the build, or the build without the process. A cadence installed on manual inputs decays in two quarters. A workbench installed on an unresolved process automates the argument. If you only want one half, there are better and cheaper people for it.
Everything hands over. Code, documentation, the data model, the logic. You own it outright at the end, and the engagement is designed so your team can operate it without me. I'd rather you not need a retainer than build one into the architecture.
- SectorsCPG, food & beverage, distribution, manufacturing, multi-site retail
- ModelsCo-man & co-pack, manufacturing, multi-DC networks, retail & distributor channels, e-commerce
- SIOPDesigned, implemented and led at three organizations
- PlatformsThree out-of-the-box planning implementations led end to end — ToolsGroup, Netstock, E2open
- ScopeDemand & supply planning, procurement, inventory deployment, transportation, DC operations
- SystemsRelex, SQL Server, DuckDB, Power Automate
- ReportingTableau, Power BI, Streamlit; star-schema modeling and metric governance
- OptimizationMixed-integer programming in Gurobi — lane assignment, sourcing allocation, facility location, network flow
- Builds inPython, SQL, Streamlit, Anthropic API
- OwnersPE-backed, privately held and public companies; board-level reporting
- BasedChicago, IL — works nationally