I was teaching a workshop in Las Vegas when someone in the audience said something that made half the room flinch.

“We have FogBugz for IT support tickets. Azure DevOps for product development. And Jira for our infrastructure work.”

He wasn’t complaining, exactly. He was just… describing his reality. Three tools. Three backlogs. Three ways that work arrives for what turned out to be roughly the same group of people.

I asked him: “Is there a screen anywhere — in any of those tools — where someone can see everything your team has been asked to do?”

He just laughed.

I’ve Seen This Movie Before

A while back, I worked with a utility company. Five developers. They were struggling to get anything done, and leadership was frustrated. The security auditors were unhappy because compliance work kept slipping. The business stakeholders were unhappy because feature requests were moving at a crawl.

When I started digging, the problem wasn’t the developers. The problem was that this five-person team was servicing work from roughly ten different “bosses.” Each boss had their own priorities. Each boss had their own backlog — some in a ticketing system, some in email, some in hallway conversations. Each boss looked at their queue, saw maybe two or three items, and thought: “Why is this taking so long? They only have a few things to do.”

But nobody — nobody — had a view of all ten queues at once. The developers couldn't see it either — but they sure could feel it. They were living it. But they didn’t have the organizational standing or the emotional energy to sit their bosses down and say: “You think we have a few things to do. In reality, we have 93 things to do. And you can’t see each other.”

Two Flavors, Same Disease

I see this pattern constantly, and it usually shows up in one of two ways.

The Tool Problem. Your team’s work arrives through multiple systems — Jira for one thing, Azure DevOps for another, ServiceNow for a third, plus email, plus Slack DMs, plus “hey, quick question” interruptions that are actually two-hour tasks. No one consolidated view exists. Each system tells a partial truth and none of them tell the whole truth.

The Boss Problem. Your team reports to (or takes work from) multiple stakeholders, departments, or product owners. Each stakeholder has their own priorities. Each one thinks their ask is the most important thing in the queue. None of them can see what the other stakeholders are asking for. And the team — caught in the middle — absorbs the chaos because pushing back feels like admitting failure.

And then there’s the version that really hurts: both at the same time. Understaffed and no unified view of demand. That’s when you get teams that are sprinting at full speed, producing nothing, and getting blamed for it.

The structural problem is identical in all three cases. Let me show you what it looks like.

Welcome to the Pentagonal Restaurant Group

Imagine a restaurant company with a bold vision: five distinct dining experiences under one roof. Italian. Steakhouse. Seafood. Farm-to-Table. Pan-Asian. Maximum choice for discerning guests.

The business plan looked brilliant. Five revenue streams. One building. And then someone in finance said: “Why do we need five kitchens? That’s redundant. One kitchen, five menus. We’ll save a fortune.”

So they built it.

---
config:
  flowchart:
    subGraphTitleMargin:
      top: 10
      bottom: 10
    padding: 20
---

flowchart TB
 subgraph subGraph0["What They Think They Have"]
        R1["🍝 Italian Restaurant"]
        R2["🥩 Steakhouse"]
        R3["🐟 Seafood"]
        R4["🥗 Farm-to-Table"]
        R5["🍜 Pan-Asian"]
        K1["Kitchen 1"]
        K2["Kitchen 2"]
        K3["Kitchen 3"]
        K4["Kitchen 4"]
        K5["Kitchen 5"]
  end
    R1 --> K1
    R2 --> K2
    R3 --> K3
    R4 --> K4
    R5 --> K5

Each restaurant thinks it has a kitchen. Each restaurant manager looks at their dining room — maybe it’s half full, a reasonable Tuesday night — and wonders why the food is taking 45 minutes.

But here’s what they actually built:

graph TD
    subgraph "Front of House"
        R1["🍝 Italian (OpenTable)"]
        R2["🥩 Steakhouse (Resy)"]
        R3["🐟 Seafood (Phone Calls)"]
        R4["🥗 Farm-to-Table (Custom App)"]
        R5["🍜 Pan-Asian (Instagram DMs)"]
    end
    
    subgraph "The Kitchen / Your Dev Team"
        P1["Pass 1"]
        P2["Pass 2"]
        P3["Pass 3"]
        P4["Pass 4"]
        P5["Pass 5"]
        
        COOKS["👨‍🍳 5 Cooks\n(Shared Capacity)"]
        
        P1 --- COOKS
        P2 --- COOKS
        P3 --- COOKS
        P4 --- COOKS
        P5 --- COOKS
    end
    
    R1 --> P1
    R2 --> P2
    R3 --> P3
    R4 --> P4
    R5 --> P5
    
    style COOKS fill:#ff6b6b,stroke:#333,color:#fff

One kitchen. Five ticket machines. Five passes where food gets plated. Five separate windows where servers pick up orders. Five reservation systems — none of which talk to each other.

And five restaurant managers who each look at their pass, see food dying under heat lamps, and think: “The kitchen is incompetent.”

The kitchen isn’t incompetent. The kitchen is the only thing that’s not lying about reality.

It Gets Worse

Each restaurant manager runs their own reservation system. OpenTable for the steakhouse. Resy for farm-to-table. The Italian restaurant's manager’s nephew's buddy went and vibe coded something custom that only runs on a raspberry pi. Seafood takes phone calls. Pan-Asian uses Instagram DMs for some reason.

So the kitchen has no idea what’s coming. Friday at 4pm, the board looks quiet. By 6pm, all five passes are on fire because everyone booked the same seating window and nobody could see it coming.

“Why didn’t you prep more?”

Because we didn’t know. There’s no consolidated view. We can’t see what you sold until the tickets start printing.

But wait — it gets better. The Steakhouse manager, trying to hit his numbers, has started running a “secret supper club” on Wednesday nights. Off the books. Different menu. Didn’t tell the kitchen. Just… tickets start printing from Pass 2 for dishes that aren’t on the prep list.

Pan-Asian saw that and thought: “Good idea.” Now they’re doing a monthly ramen pop-up. Also unannounced to the kitchen.

graph TD
    subgraph "Known Demand"
        R1["🍝 Italian"]
        R2["🥩 Steakhouse"]
        R3["🐟 Seafood"]
        R4["🥗 Farm-to-Table"]
        R5["🍜 Pan-Asian"]
    end
    
    subgraph "Surprise Demand"
        S1["🤫 Secret Supper Club (Steakhouse Manager)"]
        S2["🍜 Monthly Ramen Pop-Up (Pan-Asian Manager)"]
        S3["📧 'Quick Favor' Requests (Various)"]
    end
    
    subgraph "The Kitchen"
        COOKS["👨‍🍳 5 Cooks (Same Capacity As Before)"]
    end
    
    R1 --> COOKS
    R2 --> COOKS
    R3 --> COOKS
    R4 --> COOKS
    R5 --> COOKS
    S1 --> COOKS
    S2 --> COOKS
    S3 --> COOKS
    
    style S1 fill:#ff9800,stroke:#333,color:#fff
    style S2 fill:#ff9800,stroke:#333,color:#fff
    style S3 fill:#ff9800,stroke:#333,color:#fff
    style COOKS fill:#ff6b6b,stroke:#333,color:#fff

So now the cooks aren’t triaging five restaurants. They’re triaging five restaurants plus an unknown number of ghost restaurants that may or may not materialize on any given night.

And when the kitchen pushes back? “You need to be more flexible. We’re a dynamic organization.”

The Monday Meeting

Every Monday, there’s a leadership meeting where five managers sit around a table and argue about who deserves more kitchen capacity this week.

Italian says they have a private event Saturday. Steakhouse says they’re always slammed Friday. Seafood says their tickets are “simpler” so they should get priority. Farm-to-Table says they have a partnership launch coming up. Pan-Asian says they’ve been waiting the longest.

The kitchen isn’t invited to this meeting. And nobody mentions the pop-up restaurants.

The kitchen has become a political problem instead of an operational one.

Somewhere, a line cook is thinking: “What if we just had one ticket stream, one expeditor, and we cooked food in the order it came in?”

But nobody asks the kitchen. They just keep asking why the food is late.

Now Translate It Back for Software...

The Pentagonal Restaurant Group is silly. Nobody would design a restaurant this way on purpose.

But organizations build software teams this way all the time — one decision at a time, each one reasonable in isolation.

“We’ll just add our tickets to the dev team’s queue.” Reasonable.

“Our department needs its own tracking tool.” Reasonable.

“Can you also handle these support escalations?” Reasonable.

“We’re starting a new initiative — we’ll need some dev time.” Reasonable.

And then one day you have five backlogs, three ticketing systems, two shadow work streams, and a team that can’t deliver anything because nobody can see everything they’ve been asked to do.

The question that diagnoses this problem is simple: “Is there a screen anywhere where someone can see everything your team has been asked to do?”

If the answer is no — or if the answer is a nervous laugh — you have a Pentagonal Restaurant Group.

What to Do About It

I’m not going to pretend this is easy to fix. Consolidating backlogs means somebody has to give up control of their queue, and that’s a political conversation, not a technical one. But here’s what actually works:

First, make total demand visible. You don’t have to merge systems on day one. Just create a single view — even if it’s a spreadsheet — that shows everything the team has been asked to do, from all sources. The reaction when leadership sees this list for the first time is usually worth the effort by itself. “Wait… there are how many things in flight?”

Second, count the ticket machines. Walk through every way that work arrives to your team. Jira tickets. Email requests. Slack messages. Hallway conversations. Standing meetings where new tasks get handed out. Write them all down. This is your “reservation system inventory.” Most teams are shocked by the number.

Third, establish one priority order. This is the hard part. The five restaurant managers have to sit in a room together and agree on one ordered list. Not five lists. One list. The conversation is uncomfortable because it forces trade-offs that were previously invisible. “Your priority #1 and their priority #1 can’t both be the team’s priority #1.”

Fourth, protect the kitchen. Work in progress limits aren’t just a Kanban thing — they’re a sanity thing. If your team has 5 people, they should not have 30 things in flight. Limit the work to what the team can actually finish, and suddenly the food stops dying under heat lamps.

And maybe most importantly: stop blaming the kitchen. If you built five restaurants and funded one kitchen, the kitchen isn’t your problem. Your architecture is your problem.

The Diagnostic Question

Next time you’re in a meeting and someone says “why is the dev team so slow,” try this:

“How many systems does work arrive through for this team?”

Count them. Then ask:

“Is there a single place where we can see all of it?”

If people start listing three tools and two email threads and a shared spreadsheet… you’ve found your Pentagonal Restaurant Group.

The team isn’t slow. The team is the only thing that’s not lying about reality.

-Ben