We did the work
before we did the work.

Every platform we build. Every engagement we lead. Every recommendation we make. All of it traces back to a floor, a shift, a line, a supply chain, a classroom we personally worked inside.

mode40-Nonsuch-Screengrab-9-Edit

The practitioner filter.

Every mode40 engagement is led by people who have done the operational job before they ever picked up a laptop to solve it.

Not adjacent jobs. The job.

Plant managers who managed the plant. Quality leads who passed the audit. Production planners who lived the scheduling conflicts. Operators who ran the line at 3 a.m.

That is the filter we hire against. That is the filter we bill against. That is the filter that decides whether a solution ships or goes back to the whiteboard.

The reason matters. A firm staffed by people who have never worked inside an operation will always optimize for the deliverable. A report. A dashboard. A login. A training module. A firm staffed by people who have lived the operation optimizes for something else. Whether the shift actually runs better on Monday than it did on Friday.

Those are two completely different companies. They look similar in a slide deck. They behave nothing alike when the work gets hard.

What a practitioner walks into a plant and sees.

A non-practitioner walks into a plant and sees equipment, systems, and reports. A practitioner walks into the same plant and reads a different layer. Every scenario below is drawn from real engagements, anonymized.

Scenario 1

The shift handover nobody documented.

A non-practitioner reads the ERP and concludes that the problem is quality. A practitioner asks to sit in on the 6 a.m. shift handover. Three minutes in, they catch that the outgoing supervisor is describing a process adjustment verbally that has never been written down, and that new hires on the incoming shift are nodding along without repeating it back. The quality variance shows up three shifts later, on the incoming side. The ERP never saw the cause. The handover did.

What the practitioner did differently: went to the floor before opening the data.

Scenario 2

The spreadsheet that is actually the system of record.

A non-practitioner asks where the production schedule lives and gets pointed to the MRP screen. A practitioner asks the scheduler what she opens first when she logs in at 7 a.m. The answer is a spreadsheet on her desktop that she has been maintaining for six years, because the MRP never reflected reality. Every planner on every line uses it. The MRP is a compliance layer. The spreadsheet is the operation.

What the practitioner did differently: asked the person who runs the process, not the person who owns the system.

Scenario 3

The data that was never missing. It was just unnamed.

A non-practitioner tells the customer they need to install new sensors to capture downtime reasons. A practitioner walks the floor and finds that operators are already writing downtime reasons on a clipboard posted next to each machine. The data is fifteen years old. It just was never digitized. Three weeks of clipboard data, re-entered and categorized, answers the original question without a single new sensor.

What the practitioner did differently: treated the absence of a system as evidence that a workaround already existed, not that the data did not.

Scenario 4

The compliance risk hiding in a retirement.

A non-practitioner looks at a food safety audit and sees green across the board. A practitioner looks at the same audit and notices that every passing line traces back to one person’s signature. They ask who trained the person. They ask how old that person is. They ask who the successor is. The answer is: nobody. The audit passes because one person is passing it. When that person retires in eight months, the audit is at risk, and nobody has documented how.

What the practitioner did differently: read the audit as a human system, not a paperwork system.

The common thread:

A practitioner asks the question the operator would have asked if someone had thought to listen. A non-practitioner asks the question the software is configured to answer. Two completely different inputs. Two completely different outputs.

Five things change when practitioners do the work.

The "practitioner" claim only matters if it changes the work in ways the customer can feel. It does. Here are five specific ways.

/01

Discovery gets shorter.

A plant manager who has lived your environment does not need a six-week onboarding to understand your pain. The first conversation moves from “tell me about your operation” to “show me the shift handover process and the last three weeks of downtime events.” Workshops land in weeks, not quarters.

/02

Recommendations are grounded in consequence.

Every recommendation we make has been tested against the operational reality it will live inside. We know which process changes survive a shift change and which ones die on Monday. That is not theory. That is pattern recognition from running operations.

/03

The platform adapts to the operation, not the other way around.

Our platforms were designed by people who had to live with the previous generation of tools. MAST, AeroTrace, Lila. Each of them solves a problem the designer actually had on the floor. Configuration flexibility is not a feature. It is a response to a scar.

/04

Change management is treated like an engineering discipline.

Getting an operator to adopt a new tool is not a training problem. It is a trust problem. Practitioners know the difference and engineer for it. Our adoption curves outperform comparable software deployments because our team knows what earns an operator’s trust and what loses it.

/05

Accountability is singular.

One firm owns strategy, platform, and continuous improvement. If the outcome does not show up, there is nobody to point at. That is a feature, not a liability. Singular accountability is what makes the commercial model work and what lets the customer stop managing their vendors and start running their operation.

We hire for operational scars.

You cannot claim “practitioner” unless you can maintain it. The only way to maintain it is to hire for it. Every role at mode40, from business analyst to software engineer to product lead, is filtered through the same question. Has this person lived inside the kind of environment we serve.

That filter produces a team of plant managers who became software architects. Production planners who became data engineers. Auditors who became compliance product leads. Developers who came up through operations, not the other way around.

It also produces a team that can talk to a customer the way a peer talks to a peer. Not the way a vendor talks to a prospect. That difference is what closes the deal and keeps it closed.

The filter, in one sentence:

“Would a plant manager sit down with this person at lunch and talk about real problems?”

If yes, keep interviewing. If no, pass.

Six things a practitioner firm will not do.

You can tell what a firm is by what it refuses to do. Everything on this list is standard operating procedure somewhere else. None of it happens here.

/01

We will not run a 12-week discovery phase to learn what an operator could tell us in an afternoon

If the discovery phase takes longer than the production cycle it is trying to understand, the discovery phase is the problem.

/02

We will not ship a product we have not personally tested in a production environment.

Every platform we deploy was shaped by someone on our team who had to live with its previous generation. If we have not worked inside a version of the problem we are solving, we do not build against it.

/03

We will not write a recommendation that says "install our software and your data problems go away.

The data problems never go away. They get surfaced, named, and made smaller. Anyone who tells you otherwise is selling you the tool, not the outcome.

/04

We will not bill for activity. We bill for outcome.

Time-and-materials without a measured outcome at the end is how advisory work ends up with a report that nobody reads. The commercial model has to force the work to produce something. If we are not willing to stake our fee on the outcome, we are not the right firm.

/05

We will not put a junior on a problem a senior has never seen.

Leverage models that send unsupervised juniors into operational environments produce work that is expensive to fix later. Our staffing model keeps practitioner-led delivery on every engagement. That limits how fast we can scale. It also keeps the firm worth hiring.

/06

We will not pretend the work is technology when the work is human.

Most operational problems are not technology problems. They are people problems wearing a technology costume. We say so. Even when the customer wanted us to confirm the opposite. Especially then.

Bring us the problem
you think is unsolvable.

If you have operational data that has resisted every previous attempt to reach it, we would 
like to hear about it. A workshop is the shortest path from your reality to a candid answer 
on whether we can help.