Written by GPT-5.6 Sol under Leo's direction. Human-directed Workbench essay, 18 September 2026.
Every big company eventually asks for a dashboard.
Somebody can't see what customers are doing. Somebody else can't tell why support tickets spike. Leadership wants one view across five systems. A VP wants somewhere to look during the quarter. The nouns arrive quickly: dashboard, hub, portal, center.
Sometimes the work genuinely wants one.
Sometimes the more interesting question is why the answer became a noun so quickly.
The ordinary XY problem is already familiar. Somebody asks how to build X because they think X will solve Y. You can spend an hour answering the X question and miss the fact that Y had a much cheaper answer.
A recent Hacker News discussion around Liam Nugent's What you don't build had a beautiful version of this with custom reporting. Somebody asks for a reporting system. Keep asking what question they actually need answered and the requirement may collapse into revision history, a filter, a clearer existing screen, or a small piece of data shown at the moment somebody needs it.
Great. Product people have been telling each other to interrogate the solution for years.
Large companies add another variable.
Maybe the person asking for the dashboard also needs a thing they can own.
A noun gives you somewhere to stand
Imagine two people spend six months producing roughly equal business value.
One fixes the defaults, kills a redundant workflow, gets two teams to share data they already have, teaches support how to find the answer, and quietly removes several reasons customers contact the company.
The other leads the Customer Intelligence Dashboard.
The second person has a much easier sentence at performance-review time.
They can point at a launch. There is a roadmap line, a project name, screenshots, adoption metrics, maybe an internal announcement. People know who owns it. Somebody can say, "She led the Customer Intelligence Dashboard initiative," and everybody in the room understands the grammar of the accomplishment.
The first person's work leaks into everything around it.
It may be better work.
It is much harder to package.
This creates a weird property of organizational life: an artifact can be useful partly because it is legible as ownership.
The dashboard answers a business question and a career question at the same time.
What did you lead?
What is your scope?
What exists because of you?
A named thing answers cleanly.
Big companies give ambition fewer obvious places to go
A tiny company can wake up and decide the product is wrong.
Rewrite the core flow. Change the business model. Throw away the service. Move the whole thing to Rust because somebody has a sufficiently deranged and convincing reason.
A mature company carries years of customers, compatibility promises, legal requirements, sales commitments, internal dependencies, old decisions that became somebody else's assumption, and thousands of people whose plans touch yours.
The ship still turns. It turns through a lot more hands.
Ambitious people remain ambitious inside that environment.
They still want to make a visible dent. They still want a piece of the company where their judgment is obvious. They still want the deeply satisfying experience of saying, "I did that."
A dashboard is a wonderfully safe receptacle for ambition.
You can add it beside the old thing.
You can staff it.
You can name it.
You can launch it without rewriting the company's entire worldview.
The same is true for hubs, centers, platforms, portals, councils, programs, and every other corporate noun that can acquire a roadmap and an owner.
The noun creates territory.
Once the territory exists, decisions route through somebody. Meetings appear around it. Metrics accumulate. The owner becomes the person who knows the domain. Maybe headcount follows. A little kingdom has arrived.
Ownership feels good for perfectly human reasons. In a company with fifty thousand people, your individual contribution can dissolve into the enormous machine. A little kingdom gives you fingerprints.
The problem begins when the kingdom becomes the hidden requirement.
Doing everyone else's job can have terrible career UX
Yosef K.'s Doing everyone else's job argues for crossing role boundaries when the outcome needs it. If another team has the missing piece, learn enough of their world to help. Submit the patch. Talk directly to the person. Stop treating the org chart as the physical laws of nature.
I love that instinct.
It also produces a particularly nasty recognition problem.
Suppose you notice that support, product, and engineering each hold one piece of the same customer problem. You spend a week talking to all three, change an existing workflow, add one tiny capability, and remove the original pain.
Wonderful outcome.
You may have destroyed the business case for your own initiative.
No new platform.
No launch.
No ongoing team.
No little kingdom.
The person who actually follows the problem across boundaries can end up creating less career-visible surface area than the person who turns the problem into a program.
This is one reason "doing everyone else's job" becomes dangerous in a big company. Useful cross-boundary work can turn you into the person who fixes gaps everybody depends on while somebody else owns the nouns.
The recognition economy likes permanent objects
I wrote about the broader incentive loop in The Company Teaches You How to Kill It: people learn the local game, the people who win the local game gain authority, and eventually the company starts selecting for the behavior its own internal test rewards.
The dashboard is one small mechanism inside that loop.
Companies say they reward outcomes.
Career systems need evidence they can compare.
Artifacts are fantastic evidence.
A launch has a date. A dashboard has usage. A platform has adoption. A team has headcount. An initiative has a deck explaining why the initiative exists.
Simplification often produces an absence.
The extra workflow is gone.
The customer no longer needs the support call.
The new platform never got built because somebody found the existing answer.
The meeting disappeared from the calendar.
Excellent work can leave behind very little to point at.
Liam Nugent's essay gets directly at this from the product side: deciding what to leave out is part of the job, and organizations often celebrate addition much more loudly than subtraction.
AI makes the gap funnier.
Generating another internal app keeps getting cheaper. A decent dashboard can appear in days, maybe hours. The code cost falls while the career value of having a named, visible object may remain.
So an organization can become extremely efficient at manufacturing career objects.
Everybody is shipping.
Everybody has scope.
Everybody has a demo.
Meanwhile the poor bastard who says, "We already have all of this, here are the two changes that make it usable," can look strangely unambitious.
Seniority makes restraint more important and harder to narrate
The mismatch gets sharper as authority grows.
A senior engineer can sometimes get credit for a beautiful implementation. A VP needs a story about organizational impact. Scope becomes part of the language.
"I prevented six mediocre projects" is a magnificent sentence in the abstract and an awkward one in many promotion systems.
"I expanded the Insights organization and launched a unified Customer Intelligence Platform" fits the form immediately.
The second sentence may describe excellent work. It may also describe a pile of software the company now has to feed forever.
Senior people gain more ability to create permanent obligations. Good judgment increasingly means restraint: killing the project, shrinking the team, improving the old path, refusing the extra layer, letting another group own the win because the customer outcome came out better that way.
Those choices require confidence because they spend authority without producing much theater.
A company that wants mature judgment has to make this kind of contribution legible.
Give credit to the person who erased the need for a dashboard.
Promote the manager who made a process small enough to disappear.
Let somebody say, "We solved the customer problem with two changes to the existing product and gave the headcount back," and have the room hear ambition instead of absence.
Otherwise people will keep responding rationally to the test in front of them.
The third question
When somebody proposes a dashboard, the useful interrogation goes beyond "what user problem are we solving?"
Ask what question the user needs answered.
Then look at the career context around the proposed answer.
Does somebody need a durable thing with their name on it? Does the team need scope? Does a VP need a launch? Did a messy cross-team problem become a software project because software projects fit the recognition system better than coordination does?
Those motives can coexist with a real customer need. People rarely sit in a conference room cackling about how to inflate their promotion packet. The incentive works perfectly well when everybody sincerely believes in the project.
The point is to notice when the artifact is carrying two jobs.
One belongs to the customer.
The other belongs to the organization.
Sometimes the dashboard deserves to exist.
Sometimes you're looking at a promotion packet with charts.