How do I test a new delivery model in my engineering firm without getting the whole firm to agree?

You test it on one pod and one live lump sum project. Skip the firmwide rollout and the permission it would need. Pick a single pod, give it a minimum data layer, run the job through it, and measure before and after. That comparison is your business case.

Why not roll a new delivery model across the whole firm?

Never roll a new delivery model across forty teams before you have proved it on one. You would be asking every team to change before anyone has seen it work.

In my view, a new way of delivering engineering should not reach a firm as an idea. It should arrive as a result that one group already produced on real work. An idea invites a debate. A result invites a decision.

What is a pod, and why only one?

By a pod I mean a small group of people who deliver work together. That is how I use the word here, not a formal definition. Choose one.

In my view, one pod gives you a cleaner comparison than several. With one group and one job, there are fewer things that could explain the difference you see. You can look at how that pod worked before and how it works now, and the gap means something.

What does a minimum data layer mean?

It is the least structure the pod needs so its work can be measured and repeated. It is not a firmwide data project. It covers one pod and one kind of work.

Here is one example from our own work. A tool was seeded with 15 structured example reports for one report type, a wastewater discharge permit report. That is the whole fact I will state. The point I take from it is the size of the starting layer: one report type, a small set of structured examples, not the whole firm's output.

• One pod, not the firm.
• One kind of deliverable, not every service line.
• A small set of structured examples that show what good looks like.

In my view, the temptation is to build the full data layer first. Resist it. A small layer that one pod uses on a live job teaches you more than a large one nobody has tested.

Why does the project need to be lump sum?

This is my view, not a rule. When a job is billed by the hour, the test can send mixed signals. A pod that finishes sooner can look like it earned less, and then the pilot seems to argue against itself. That is Grandfather Engineering showing up in the numbers: hours treated as the product.

A lump sum job pays for the outcome. If the pod delivers faster or with less effort, I would expect that to show up in the calendar and in the margin. Those are things an owner or a regional MD can read without a translator.

The job should also be live. A pilot on a made-up project proves little. A live job has a client, a deadline and real stakes, so the comparison carries weight when you take it upstairs.

What do I measure, and how do I make the case?

Measure before and after, on the same kind of work. That is the core of it. What you measure is up to you, and these are my suggestions, not a fixed list:

1. Elapsed time from start to finished deliverable.
2. Hours the pod actually spent.
3. Margin on the lump sum.

Whatever you pick, agree on it before the work starts, and write down the baseline first. A before number recalled from memory after the fact will not hold up in a meeting.

Then take the comparison upstairs. It is stronger than any vision deck, because nobody has to imagine anything. They can see one pod, one job, and the difference.

I wrote about this in the book on the throughput ceiling, and it is the step I would give a regional managing director who has no firmwide mandate. It needs no permission to change the firm. It needs permission to run one job. If you are still working out how to move from owning the work to owning the firm, Chapter 1 of Engineer Your Freedom is free.

What should I do next week?

Here is what I would do. Do not ask for permission to change the firm. Ask for permission to run one job.

• Pick one pod.
• Give it a minimum data layer, kept as small as the work allows.
• Choose one live lump sum project already on the books and run it through that pod.
• Measure before and after, and write the baseline down before the work starts.

That is the whole plan. When the job is done, you will have a comparison from real work, and that is what you take to the people who need to say yes.