The night before the on-site, six of us went to dinner.
Forty people were flying in the next morning to spend two days working on one process. We were the ones who’d planned it, and we were doing the thing you do the night before, sketching out the agenda and arguing about what we actually wanted out of the room.
Somewhere in there I asked what I thought was a throwaway question. What’s the goal of this process? What’s the key output?
All six of us gave a different answer.
Not six phrasings of one answer. Six answers. I said out loud that I’d bet anything the room would do the same thing in the morning.
The room did the same thing in the morning. And it was worse than I expected, because underneath the disagreement about what the process was for, there were people who couldn’t tell me how their own work affected their own workcell. Not the system. Their workcell. The thing they were assigned to.
That’s the part I keep coming back to. We talk about systems thinking like the problem is that people can’t see the whole. Most of the time the problem is that they can’t see one level up.
I said in the last post that this one was coming. Here it is.
The questions nobody could answer
I moved to a different part of our business this year and got put in charge of one workcell. I was new to the space, so I did what you do when you’re new. I asked basic questions.
What’s the benefit of making this change?
What’s our budget on this KPI?
There are a lot of KPIs here. Which one matters more?
If I increase this one and lose that one, where’s the line?
None of these are clever questions. That’s the point. I wasn’t trying to catch anybody out. I was trying to find the floor so I could stand on it. It’s the product triangle, but for KPIs. You can’t have everything at once, and somebody has to have decided which thing gives.
Nobody could answer them.
I should say where those questions come from, because it isn’t insight and it wasn’t a choice. When I started in this business I was a TPM embedded with our in-house simulation platform teams. The people building the simulation engines, the self-service tooling on top of them, and the data science teams who used both to analyze how the system was actually performing. My team didn’t just ship our own code. Looking at the system was the job. I got assigned to that vantage point before I knew enough to want it, and it’s shaped how I look at everything since.
So I wasn’t annoyed when nobody could answer. I was surprised. I was very surprised. I’d come from a program where those answers existed, so I assumed they existed here too and that I just hadn’t found the right document or the right person yet. I’ll come back to that program.
What changed my mind wasn’t time passing. It was a change in altitude. I moved from running that one workcell to managing the team of TPMs who owned the overall program system, and I started spending time with them to work out what had been happening and why.
From up there it was obvious. I hadn’t been failing to find the answers. The answers didn’t exist. Nobody had done that work.
That one cuts at me too. For months, from inside a workcell, I couldn’t tell the difference between an answer I hadn’t found and an answer nobody had ever written down. You can’t see that from where I was standing. It’s the same limit I’m about to describe in other people, and I had it first.
And that work matters, because of how these buildings actually behave. When we move a lever in one workcell, the other workcells compensate. Or the system falls over. There’s no such thing as a local change in a system of systems. There are only changes whose cost lands somewhere you aren’t looking. Every local win is a withdrawal from an account nobody’s reconciling.
Three times in a few weeks
Here’s what the absence looks like. Two of these happened on the same day.
One. I was writing a paper for a program I’d just onboarded to, the one from the last post, where a system performance escalation had us mapping how a set of greedy algorithms interact.
A team pushed back on being included. Their algorithm didn’t have system impact, they said, so it shouldn’t be in the paper.
What I said back was roughly this. We proved that moving from your old version to your new version had no system impact. That’s great, and I believe it. But there’s no way your metrics are exactly the same before and after. Which metrics did you actually look at? How does this interact with the rest of the system? It’s not free. It affects something, somewhere.
And then the part I actually care about. Being greedy isn’t necessarily bad. Nobody’s here to tell you your algorithm is wrong. We’re trying to understand the scope of the greedy algorithms so we can understand how the system works. Why would you want to be left out of that?
Two. Later the same day I was in a different conversation with a partly overlapping set of teams, working on the next-generation architecture. We got to talking about how various parts of the system had been tuned.
Two parameters. Both tuned. Both greedy. They cancelled each other out.
One of those teams didn’t know. Their work had been erased by another team’s work and nobody had told them, because nobody had been in a position to notice.
In the morning, a team certain their algorithm had no effect on the system. By the afternoon, a team learning that the system had quietly undone them.
Three. A few weeks on from that dinner, at a different on-site. A different part of the same system, a mostly different set of people. Wednesday morning, someone cited a number to me and I heard a bottleneck.
We’d been shortening dwell times at the stations. Dwell time is a real lever, it’s measurable, and shortening it is unambiguously good work. Throughput didn’t move, because as dwell times came down, the gaps between units arriving at the station closed up.
So the other move is to attack the gaps. Also a real lever. Also good work. But closing the gaps generally came with longer dwell times.
Two teams. Two levers. Both improvable, both owned, both being improved. And they trade against each other, so neither one moves the number anybody actually cares about.
The binding constraint was a third number. How many unit visits per hour the system can deliver at all, meaning how often a mobile shelf can physically get to a station. That was the ceiling. Dwell time and gap were both downstream of it, and neither team owned it.
I’m not telling this story because I spotted something. The interesting part is how that number got into the room at all.
A data scientist brought it, and not as a bottleneck. They brought it because it’s a clean way to compare performance across generations of the system, which is otherwise hard to do well. It arrived as a comparison, not a diagnosis. Nobody was looking for it, and nobody had reason to be.
We’ve never compiled the list. The set of KPIs that would tell you where the bottlenecks in this system actually sit. Without that list, a number that indicates a bottleneck is just one more number on a slide, and this one wasn’t the story anybody had come to tell that morning. It surfaced because a good analyst was solving a different problem and I happened to be in the room with the system on my mind.
Three separate settings. A paper review, an architecture conversation, and an on-site weeks removed from the one I opened with. Different parts of the same system, mostly different people, no shared cast to blame. The same failure every time.
Greedy is not the problem
A greedy algorithm takes the best option available to it right now. Locally optimal, and stateless. It doesn’t carry a model of what the rest of the system is doing, and it doesn’t account for what its choice costs three steps downstream or two workcells over. It optimizes the decision in front of it and moves on.
That’s frequently the right engineering decision. Greedy is fast, greedy is easy to reason about, and for the problem the algorithm was handed it’s often exactly correct. Our systems are full of them, and they should be.
What happens when a lot of them run at once isn’t a matter of opinion, and this is the one place in this post where I can point at something proven rather than something observed.
Roughgarden and Tardos studied this exact shape. Independent agents each routing themselves optimally through a shared network. When congestion rises linearly with load, all that self-interest costs you at most about a third more than a coordinated solution would. That’s the good case. Drop the linear assumption and the gap is unbounded. There’s no reassuring worst case to fall back on.
The result I think about most is a different one from the same work. A network where everyone optimizes for themselves costs you, at most, what an optimally coordinated network would cost carrying twice the traffic.
That’s a proof about a model. Infinitely many infinitely small agents, perfect self-interest, well-behaved congestion curves. Our algorithms aren’t infinitesimal and our KPIs aren’t latency functions. It bounds an idealization. It doesn’t measure a building. What transfers is the structure: independent local optimization against a shared resource, with no term in anyone’s objective for the shared part. That structure is in our organization whether or not the math is.
Which brings me back to dwell time and gaps. Speeding up a stage that isn’t the constraint doesn’t move throughput. We proved that to ourselves the hard way, twice, on two different levers, before anyone had named the constraint.
So the failure isn’t greed. Each of those algorithms is doing what it was asked to do, and doing it well. The failure is that nobody’s auditing the interactions between them. We don’t track what one greedy component does to another, we don’t have a record of which ones touch the same resource, and we have no standing way to find out that two of them have been pulling against each other for a year.
That’s a tracking problem, not a design problem, and the two have completely different fixes. You don’t solve this by making the algorithms less greedy. You solve it by knowing how they interact.
Which means somebody has to be holding a picture of it. The diagram I mentioned in the last post is doing that job now. It isn’t a component map. It’s a system dynamics view, which variables move which other variables and where two of them are pulling on the same thing, and it’s what lets me check whether a set of recommendations coming out of separate teams actually composes. Without something like it, “we’ll keep an eye on the interactions” is a good intention with nowhere to look.
And it gets expensive in a way that doesn’t show up until you try to fix something. When nobody’s tracking the interactions, you either improve the wrong thing because you were never on the bottleneck, or you make one change and five new problems surface. Then you can’t tell which of them you caused, which were masked before and are only visible now, and which were always there and just never mattered. A change one team makes shows up as a different team’s problem, and the honest question, did we just break this or did we never exercise this edge case before, is one only somebody holding the whole picture can even ask. That failure mode deserves its own post and I’ll write it.
Both sides are right
Since March I’ve been sitting in weekly program reviews.
Leadership is frustrated. They aren’t seeing the system-level progress they expected, particularly on the newer generation, given the effort that’s gone in. And the teams are sitting in the same meeting pointing at delivered features and detailed metrics that show progress. Real work. Real movement. Not spin.
Nobody in that room is wrong. That’s what makes it worth writing about.
Part of that gap is a narrative problem. There’s progress happening inside the system that isn’t obvious from a list of shipped features, and it isn’t being told at a system level, because we aren’t thinking or talking at a system level. That deserves its own post, so I’ll leave it there.
And part of it isn’t a narrative problem at all. You can improve individual workcells all year. If they aren’t the bottleneck, and they don’t move the system-level KPIs, leadership isn’t going to see a change, because the system didn’t change. Portions of it changed. Those portions may or may not have been the right levers.
I can’t cleanly tell you what the split is. I don’t think the halves are equal, and I don’t think anyone in that room could give you a number, which is itself part of the problem.
Here’s what I don’t think is happening: I don’t think anyone screwed up.
I have a great deal of respect for the people working on this system. The analysis being done is good. Teams are correctly identifying where we’re losing time and they’re closing those gaps, and that’s not nothing.
What I think is happening is structural.
We have a system-level goal. Every year. And every team, every workcell, every process has its own goal, for good reasons. Accountability, a target, something concrete to aim at.
Translating between the two is the hard part. That translation does exist in places, and it didn’t exist where I was looking. Where it does exist, it’s complex, it takes real time to build, and it doesn’t get tracked with anything like the visibility the goals themselves get.
The goals were short and to the point. Systems aren’t short and to the point. Systems have balance, and trade-offs, and places where you give up one thing to get another. None of that survives compression into a team goal, so none of it shows up in the thing anyone is measured against. A translation can be sitting in a document somewhere and still lose, every week, to the number on the review slide.
There’s a second version of the same problem, one level down. The decomposition itself is sensible. People who knew what they were doing broke the system into reasonable pieces and hung KPIs on them. But it’s very easy to read that as I’m going to make my workcell perform against these KPIs, and very hard to read it as this set of workcells has to perform against this KPI together. The KPIs landed one level below where the system actually lives.
And then think about what it looks like from inside a team. What you get questioned on is your KPIs. Did you hit your targets? Are you the reason the system underperformed? Given that, optimizing your own number isn’t a failure of imagination. It’s the only rational reading of what you were asked to do.
This is an old failure. Ridgway wrote about it in 1956, that adding more performance measures solves the single-metric problem and creates a worse one, because nobody can tell whether a gain over here justifies a loss over there. It’s a short paper built from illustrative cases rather than data, so I wouldn’t build an argument on it. What earns its place is the date. This is a seventy-year-old defect in how measurement and accountability interact, it isn’t particular to my organization, and we walked straight into it anyway. Conway’s law points at the rest of it. Organizations build systems that mirror their own communication structures, and the corollary I keep running into is that optimization follows the org chart too. Teams are organized around components, so that’s where the improvement goes, rather than into the flow of material through the building. Nobody owns a seam.
I don’t fully know why it’s gone this way here. Is it that we don’t have enough people running the programs? That we stopped training or emphasizing systems thinking? That our structure makes the system opaque? I don’t have a clean answer. What I am confident about is that we aren’t incentivizing the right behavior from teams right now.
What we’ve been doing instead is micro-optimizing enormous, complicated systems, and building ourselves into fragile, complicated systems with levers that don’t play well together.
I have seen this done
None of that is inevitable, and I’m not describing an unsolved problem. I’ve watched it work. Twice on programs of this flavor and this scale, and in a different shape before that.
The different shape came earlier, at Fitbit, and it’s worth a minute because this isn’t a robotics problem. Every team there owned its own customer service tooling. Every team’s tooling was reasonable. Together they were a mess, for exactly the reason I’ll get to at the end of this post. The answer was a dedicated customer service tools team. One group owning the whole surface instead of a dozen groups each owning a slice of it. Different industry, different failure, same shape.
The first of the two was the program I mentioned earlier, from a few years back. Multiple products converging, real scale, a lot of teams. What the systems team built there wasn’t complicated to describe. Every team got a performance budget, meaning your allocation against the system-level target. There were written rules for what happened when a team couldn’t hit theirs. Here’s how we trade through the system, here’s what gives, here’s who absorbs it. And there was a theory of operations document that said what the system was for and how it was supposed to behave.
That program wasn’t a gold star. It’s live and it’s scaling, and it still isn’t perfect. There are things I’d do differently, and I wasn’t there at the beginning, so that’s hindsight from someone who arrived later. I think they made the right calls for where they were and what they knew at the time. What it did well was the starting point.
But that isn’t a small thing, and here’s why. The artifact wasn’t a process. It was an answer. When someone asked what their budget was on a KPI, there was a number. When they couldn’t hit it, there was a rule. That’s all a KPI hierarchy is. It isn’t governance. It’s arithmetic somebody did in advance so that forty people wouldn’t have to redo it, badly, in real time, with no shared picture.
The second was a program that got cancelled in January.
I spent a year on a tightly integrated cross-functional team working a smaller and different building format. It was the first time I’d really owned and revisited an entire building flow holistically, start to finish, with the authority to change any part of it.
Every conversation on that team came back to the same set of questions. How does it balance? What are the levers? What do we need to plan upstream to get a better outcome downstream? How does all of that interface and play? Can we reach further up the network to get better decisions made and better profiles coming to us, so the whole thing works?
It was the most fun I’ve had at work and the most rewarding, and it was the best design I’ve seen in a very long time. I was heartbroken when it was cancelled. I also understand why, and it was probably the right call. Both of those things are true and I’m not going to pretend otherwise to make a point.
Here’s the part that matters for the argument. The depth of the due diligence and the requirements and the planning on that program was heavy. And it was a small team, moving fast, iterating, building toward something exceptional. Those happened at the same time, on the same team, in the same year.
I’m going to come back to that, because it’s the answer to the strongest objection to everything I’m about to say.
One thing I should say plainly about both of these before I move on. Neither is a story where everything went well. One is live and scaling and still imperfect. The other doesn’t exist anymore. What they demonstrate is narrower than success, and the narrow thing is all I’m claiming, which is that the systems work paid for itself while it was being done. A program getting cancelled is a portfolio decision. It isn’t a verdict on how the system was designed.
What is actually missing
Somebody is going to read all of that and tell me I’ve just described bottleneck analysis, and that Goldratt got there in 1984.
They’re half right, and the half they’re wrong about is the whole argument.
Theory of Constraints isn’t a diagnostic you run when the numbers disappoint. Done properly it’s a design discipline. You identify the constraints and the risks and the dynamics up front. You make sure teams understand those dynamics and the trade-offs between them up front. You instrument for the metrics that would tell you the system is drifting, up front. The analysis at the end is the cheap part, and it’s only cheap because of what you did at the beginning.
That’s the investment. Here’s what it buys. Teams know their levers. They know where they have to balance and what their constraints are. When a constraint turns out not to be attainable, they can negotiate it and make an informed trade instead of escalating. When the system underperforms, they know which metrics to inspect. And the system is less likely to underperform in the first place, because somebody thought about the dynamics before anyone wrote code.
Running the analysis after the fact gets you one of those. Not the rest, and not the last one at all.
So yes, this is constraint thinking, and I’m not claiming to have invented anything. What I’m claiming is that we treat it as something you do when a program is in trouble, and it’s something you do when a program starts. One quick caveat on the evidence, since I’m invoking it: the published record on constraint management is large and close to useless as proof. Over a hundred documented cases and, as the people who catalogued them point out, not one reported failure. That tells you about what gets published, not about the method. I’m citing the discipline, not the win rate.
Four things. Each one either exists or it doesn’t.
A theory of operations. Not just what the system does and how it’s supposed to behave, but what matters at the system level and why it matters. The why is the part people skip and the part that does the work, because it’s what lets someone reason about a case the document never anticipated.
A KPI hierarchy with budgets and acceptable ranges. Which numbers outrank which, and how much each one is allowed to give up.
Trade-off rules decided in advance. What happens when a team can’t hit theirs, settled before it happens rather than escalated when it does.
Ownership at system altitude. Teams whose success is tied to the system, not only to the workcell they hold. This is the one that changes behavior, because it’s the only one that changes what people get asked about.
I want to be careful about what that last one doesn’t mean, because there’s a version of it that makes things worse. It doesn’t mean everybody shares one number and nobody owns anything. Shared goals without an owner is how you get a room where every team can point at every other team, and component goals exist precisely to stop that from happening. What it means is that one person is accountable for the system outcome, teams hold budgets against that outcome, and the trade-off rules say what happens when a team’s budget and the system number pull in different directions. That’s a hierarchy with a name at the top. It isn’t diffusion. Whether you call the name a single-threaded owner or something else matters a lot less than whether it exists.
Two and three only work if everybody has them, and that’s a design constraint on the artifact rather than a distribution problem to solve later. Every person on the program, at every level and in every discipline, should get the hierarchy and the rules on the day they join, and should be able to ask questions about them without it being a whole thing. They also have to be short. Short enough to cache in somebody’s head and recall in the moment they need it, because the moment they need it is when they’re making a call on their own with nobody senior in the room. A wall of documentation nobody can retain isn’t a KPI hierarchy. It’s a KPI hierarchy that exists and doesn’t work.
Both of the programs I just described had all four of these. Different scales, different building formats, different teams, and the same four things in place.
Here’s where I am right now, and it isn’t a clean story. There’s a metric we’re pushing on a process I own. I know it’s going to cost us somewhere else in the system. I think it’s the right call holistically. I think it’s a cost we should pay.
But somebody has to actually do that trade-off.
We have teams putting weeks and months into features that will improve one KPI while another process gets worse, and nobody has done the arithmetic on whether that exchange is a good one. Sometimes it is. Sometimes it isn’t. Right now we can’t tell which case we’re in, and that’s the problem, not the trade itself.
This isn’t only my read. There’s work out of the multi-agent path-planning community, Zhang and colleagues, on coordination and layout design for automated warehousing, that lands in the same place from a completely different direction. Human-designed warehouse layouts congest at high robot counts and cap what you can scale to, even paired with state-of-the-art coordination algorithms. Optimize the layout instead, a system-level variable that no coordination algorithm owns, and in some cases you can support twice as many robots. It’s simulation, not a live building, and simulated congestion is kinder than the real thing. But the finding is that the algorithm was never the ceiling, and it comes from people with no stake in my argument.
What it costs
None of this is free, and I’m not going to pretend that a cheap question at dinner scales into a cheap program.
The cost is real and it’s front-loaded. It’s systems engineering and TPM and PM-T capacity spent at the beginning, on people whose whole job is holding the parts against each other. And it isn’t a document you write once and file. You build the first version early, when you know the least, and you revise it as the team learns. That’s the difference between paying up front and paying retroactively, and paying retroactively is what an escalation is.
So yes, this is partly a headcount argument. I’d rather say that out loud than dress it up as efficiency. I made the same argument in the last post and I’ll separate it the same way here: that coordination work gets more valuable is one claim and I can support it, and that it also takes more people is a different claim and that one is my experience, not my evidence.
Here’s the part that makes the trade worth taking, and it’s why I don’t think of this as overhead. Every one of those artifacts is a decision somebody would otherwise have to come and ask about, or guess at. When an engineer knows what the system is for, what their budget is, and what gives when they can’t hit it, they don’t wait on a meeting and they don’t make a call that has to be unwound three months later. The upfront spend on connective tissue buys back implementation speed, because it lets the people building things go build and make more of the right decisions on their own.
That’s the whole trade. You aren’t adding a layer between engineers and their work. You’re removing the reasons they keep having to stop.
What we’re doing about it
Fair question at this point. I now manage the people who own this gap. So what have I actually done since March?
Three things, none of them finished, and I want to be accurate about who did them, because most of this is my team’s work and not mine.
On the process I own, we built the KPI hierarchy. It exists now, it didn’t in the spring, and the work is ordered and themed against it, which is the part that matters. A hierarchy nobody sequences against is a wall poster. It also only covers our process. It doesn’t cover the seams between us and the processes on either side, which is the harder half, and it’s why the trade I mentioned earlier still doesn’t have arithmetic behind it. I also spent a day walking the site with Ops, to understand the whole flow around our workcell instead of the workcell itself, and that turned up something I didn’t expect. We have unused time at our stations. I brought back a proposal for how we could spend it supporting the rest of the system using infrastructure we already have, and the team is running with it. That’s the exact inverse of the problem in this post. Local slack going out to the system, instead of local gains coming at the system’s expense.
The newer generation is my team’s work, not mine. They ran a series of on-site workshops at a fulfillment center, organized by process and theme, with the people who actually do the work in the room. The dinner I opened this post with was the night before one of them. They’ve since published a Top 5, the things everyone on the program should be working toward. That isn’t a KPI hierarchy yet. It’s the beginning of one, it’s short enough that people can actually hold it, and it’s the first time that program has had a single shared answer to what we’re all pointed at.
The older generation is the diagram. That one is mine, and it’s still in progress.
I’m being specific about the attribution because the split is the argument. I saw across, asked the questions, and put a proposal on the table. The people who own the work are building it, and that’s the division I want. Connective tissue isn’t supposed to be doing the building.
We are seeing more progress since we started looking at the system. More accurately, more aligned progress. That’s my read, it’s early, and it isn’t a number I can attribute, so I’m not going to pretend it is one. What I can tell you is that four months ago none of those three things existed, and that all of them got built the way I’ve been arguing for. Early, incomplete, and revised as we learn.
The strongest argument against all of this
I want to make the best version of the objection, because it’s a good one and I’ve heard it made well.
You’re asking a next-generation architecture to publish performance budgets and trade-off rules before anyone fully understands how the system behaves. Budgets defined against a system you don’t understand yet aren’t coordination. They’re confidently wrong numbers that teams will optimize against for a year. The teams shipping fast and iterating aren’t avoiding the work. They’re refusing to fabricate it.
That’s a real objection and I’d rather answer it than soften it.
Here’s the answer. Two programs started in the same window. The one I just described, and a next-generation effort on a different part of the building. Same era. Same maturity. Neither had the advantage of hindsight. What differed was the approach at inception, and the one that started without the systems depth has since wholly revisited its architecture more than once.
Now three things that are also true, and that I’d rather say myself than have someone else say for me.
Those teams were set up differently. Different people, different expertise, a different approach from day one. This isn’t one team outperforming another and I’m not making that argument.
Some of that re-architecting wasn’t avoidable. New technology arrived. The network changed. The dynamics changed. That happens, it’s fine, and it isn’t a planning failure. My claim is narrower than it might sound. More upfront system understanding would have eliminated some of that work, or limited it. Systems should change. They should be well understood while they change.
And that program isn’t the gold star. It’s live and scaling and it still isn’t perfect, and I wasn’t there at the beginning, so anything I’d do differently is hindsight I didn’t have to earn. They made the right calls for where they were. The claim is about one thing they did well at the start, and about how much starting points compound.
Which brings me back to the program that got cancelled. Heavy due diligence, heavy requirements, heavy planning, and a small team moving fast and iterating, at the same time. Those aren’t in tension. This isn’t an argument for waterfall and it never was. Sequence by risk. Prototype the parts you can’t reason about. Find the low-hanging fruit. Phase it. Build the requirements up as the team learns.
A budget that gets revised is doing its job. A budget that never existed can’t be wrong, and that’s exactly the problem. You can’t correct a number nobody wrote down.
And the cheap version costs nothing at all. Six people at dinner. One question. No mature system required, no governance artifact, nobody’s headcount.
One more objection, and it takes two sentences. Sometimes the component is the constraint, and the local win is the system win. That’s true, and knowing which case you’re in is the entire point. Dwell time was worth improving. It just wasn’t the bottleneck.
The group project
Nobody wants to be the weak player on the group project when it’s time to present.
Everyone wants to be a strong contributor. That’s the right instinct. It’s what you want from people, and I wouldn’t trade it away.
But when everyone brings their own strongest individual contribution, what shows up is a mosaic of products that are distinct, instead of a system of intentionally balanced collaborating products.
That’s where the problem is. Not in anyone’s effort, and not in anyone’s judgment about their own piece.
I said in the last post that acceleration is a given, and the argument is about when you pay. This is the same argument in a different place. A workcell win is acceleration you can point at this quarter. If nobody owns the sum, the bill still arrives. Later, larger, and in a number belonging to someone who never got to make the trade.
None of this comes together by accident. It takes real technical knowledge and real system-level analysis, and that’s where the magic in these systems actually is.
If you want to test whether you have the problem, it costs you one question. Ask the people closest to your process what it’s for. Ask them separately. Compare the answers.
All thoughts, opinions, and experiences are my own, and do not reflect the opinions or stance of my employer.
References
- Victoria J. Mabin and Steven J. Balderstone, “The performance of the theory of constraints methodology: analysis and discussion of successful TOC applications,” International Journal of Operations & Production Management, vol. 23, no. 6, 2003, pp. 568–595.
- V. F. Ridgway, “Dysfunctional Consequences of Performance Measurements,” Administrative Science Quarterly, vol. 1, no. 2, 1956, pp. 240–247.
- Tim Roughgarden and Éva Tardos, “How Bad Is Selfish Routing?” Journal of the ACM, vol. 49, no. 2, March 2002, pp. 236–259. https://theory.stanford.edu/~tim/papers/routing.pdf
- Yulun Zhang, Matthew C. Fontaine, Varun Bhatt, Stefanos Nikolaidis and Jiaoyang Li, “Multi-Robot Coordination and Layout Design for Automated Warehousing,” Proceedings of the Thirty-Second International Joint Conference on Artificial Intelligence (IJCAI 2023), pp. 5503–5511. https://arxiv.org/abs/2305.06436
