↓ Skip to main content
Brian Swiger

The Show Pony and the Workhorse: The Visibility Tax in the Age of AI

·15 mins
Engineering Culture Career Leadership Visibility Workplace Culture Software Engineering Artificial Intelligence Cloud Architecture Leadership Recognition Engineering Culture
Brian Swiger
Author
Brian Swiger
Passionate Geek • Proud Father • Devoted Husband
Table of Contents

The Show Pony and the Workhorse: The Visibility Tax in the Age of AI
#

There is something about workplace culture that has been bothering me more and more.

Visibility matters. I know that. After more than 30 years in software, I have learned that doing great work and having people understand that great work are two very different things.

Somewhere along the way, though, we have blurred the line between making valuable work visible and performing visibility as work. That distinction matters…to careers, to teams, and to how leaders allocate resources. And I think it matters even more now that AI has made it dramatically easier to produce things that look impressive.

I keep coming back to a simple analogy: the workhorse and the show pony.

I’ve always been a builder
#

I am a builder at heart. That has been true for more than three decades. I like taking a messy business problem and turning it into something real. I like architecture, I like code, and I like figuring out why something does not work and then making it work. I like solving problems where the answer is not obvious. Most of all, I like seeing business impact.

That combination of technology, problem solving, and business value is what has kept me excited about this industry for so long. And, frankly, I like making good money doing it. There is nothing wrong with that either.

Some of the projects I am most proud of are not the ones that generated the most applause. Years ago, while working in the Midwest, my team and I built a loan and lease processing platform for agricultural equipment. That platform became part of a business processing more than $4 billion in financing, and it is still running today through AgDirect. I also had the opportunity to help build early pay-at-your-table technology for restaurants before that experience became commonplace.

Those systems were not built for a conference keynote; they had to work. They had to survive the ugly parts of technology that never make the demo reel: network failures, data integrity, security boundaries, concurrency, operational hurdles, edge cases, customer expectations, and ongoing production support.

That is the stuff I remember. Not because it was glamorous, but because it was real.

The workhorse
#

The workhorse is the person who pulls the heavy wagon. They solve the difficult problems, worry about security boundaries, think through failure modes, care about maintainability, optimize the architecture, make systems observable, test the ugly edge cases, keep cloud costs in check, mentor other people, and stick around long after the exciting kickoff is over.

And when the workhorse does the job exceptionally well, something funny happens: nothing happens.

The system stays up. The customer gets what they need. The transaction completes. The deployment works. The security controls hold. The cloud bill stays under control. The business keeps moving forward.

There may not be a standing ovation for that. There may not even be a meeting about it. Sometimes the best engineering is almost invisible precisely because it prevented problems nobody ever saw.

The show pony
#

Then there is the show pony.

Now, I want to be fair here: being good at presenting is not a bad thing. Being charismatic is not a bad thing. Being able to explain technology to executives is absolutely valuable…someone has to tell the story.

The problem starts when the story becomes more important than the substance.

The show pony knows how to get attention. They know how to package an idea, make a demo look magical, get into the right meetings, and ensure leadership hears about the accomplishment. And sometimes, unfortunately, they also know how to make someone else’s work sound like their own.

That last part is where things get ugly. Because now we are not talking about communication; we are talking about broken incentives.

The visibility tax
#

One of the most exhausting things about modern knowledge work is the expectation that every contributor must continually market their own impact. The message is often some variation of:

“Your work won’t speak for itself.”

There is some truth to that. People are busy, executives cannot see everything, and managers cannot observe every contribution…especially in remote and hybrid environments.

There is good research behind the basic idea that visibility matters. Harvard Business Review recently described visibility as an expected part of senior leadership and recommended a simple “we-then-me” approach: acknowledge the team’s contribution first, then explain your own.

That is a distinction I really like: We first. Me second.

The problem is when reasonable visibility turns into unreasonable self-marketing. Now the engineer is expected to build the product, document the product, demo the product, market the product internally, create the executive summary, schedule the roadshow, write the impact statement, and make sure the right five leaders know exactly who did what.

At some point, the builder has accidentally become their own internal marketing department. That is the visibility tax. And it is real work…work that consumes time, attention, and energy that could have been spent building.

When visibility becomes the metric
#

This is where Goodhart’s Law becomes relevant:

“When a measure becomes a target, it ceases to be a good measure.”

Visibility is useful as a signal. But if an organization starts rewarding visibility itself, people naturally optimize for it: more executive updates, more demos, more internal posts, more polished narratives, more “impact” decks, more appearances, and more evidence that something is happening. Pretty soon, the organization ends up measuring the appearance of progress instead of actual progress.

Humans are remarkably good at optimizing for the metric they are given. Measure lines of code, and you get bloated codebases. Measure meetings, and you get calendar paralysis. Measure visible self-promotion, and eventually you get a stable of show ponies. The measurement system starts changing the behavior it was supposed to observe.

AI just poured gasoline on this
#

This is the part that concerns me the most. AI has changed how quickly we can go from idea to demonstration. That is an incredible capability. A developer can now create a prototype, user interface, API integration, agent workflow, or proof of concept in a fraction of the time it once took.

I love that. I use these tools myself, I write about them, and I build with them. I am incredibly optimistic about what AI can do for engineers. But there is a difference between accelerating engineering and accelerating theater. The former creates leverage; the latter creates noise.

The era of AI demo-ware
#

We now live in a world where someone can produce an impressive AI demo in an afternoon. That demo might genuinely be clever, and it might even demonstrate a valuable idea. But a five-minute demo is not a production system. A prototype is not automatically secure, a model response is not automatically correct, and an agent that completes a happy-path workflow is not automatically ready for enterprise use.

The hard questions still arrive:

  • What happens with prompt injection?
  • What happens when a model is wrong or hallucinates?
  • What happens when the underlying foundation model changes?
  • How is identity enforced and tenant isolation handled?
  • What permissions does the agent actually have, and how do we protect sensitive data?
  • What happens when an API is unavailable?
  • What does the system cost at scale, and who owns it six months from now?
  • How do we monitor, test, and recover when it fails?
  • What happens when real customers actually depend on it?

Those are workhorse questions. They are not always show-pony questions.

AI is an amplifier
#

This is where the current research is particularly interesting. DORA’s 2025 research describes AI primarily as an amplifier: it can magnify the strengths of a high-performing organization, but it can also magnify the weaknesses of a struggling one.

That is a much more nuanced view than simply saying “AI makes developers faster.” DORA’s research emphasizes that the biggest returns come from improving the underlying organizational system, not simply adopting the tools themselves.

That resonates deeply with me. AI can accelerate code generation, but it cannot magically fix a bad architecture, create sound product requirements, establish governance, or replace engineering judgment. And it certainly cannot turn a fragile prototype into a production system just because the demo looked fantastic.

The workslop problem
#

There is another term that belongs in this conversation: workslop.

BetterUp Labs, working with the Stanford Social Media Lab, describes workslop as AI-generated content that looks polished on the surface but lacks the substance needed to actually complete the job. Their research found that 40% of U.S. desk workers surveyed reported receiving workslop in the previous month.

The problem is not simply that low-quality AI output exists. The bigger problem is that somebody else has to clean it up. Someone has to validate it, fix it, add the missing context, and turn the polished output into something genuinely useful.

That creates another visibility problem: the person who generated the impressive artifact looks productive, while the person who quietly makes it usable may never get noticed. That is a remarkably accurate description of the workhorse and show pony dynamic.

A demo can hide a mountain of engineering debt
#

A flashy AI demo can create a very dangerous illusion: it can make a difficult problem look solved before the difficult work has actually happened.

A demo can use mocked data, ignore authorization, assume perfect network connectivity, skip concurrency, run with elevated privileges, avoid monitoring, ignore compute costs, and skip failure handling…all while quietly assuming that someone else will deal with all the hard stuff later.

That “later” person is almost always the workhorse. This is why I get uneasy when a demo is treated as proof that an enterprise solution exists. It proves that something is possible…which is valuable…but it does not prove that something is ready.

The production test
#

A much better test for engineering impact is simple: Do not evaluate only at launch. Look again six months later.

  • Is it actually being used?
  • Is it secure, reliable, and cost-effective?
  • Is anyone actively maintaining it?
  • Did it create measurable business value, increase revenue, reduce cost, or mitigate risk?
  • Did customers adopt it, and did it make people more productive?
  • Did the organization learn something valuable?

Those answers tell you far more than a flashy launch demo ever could. The show pony looks fantastic on launch day, but the workhorse is still pulling the wagon six months later.

The credit problem
#

This is where visibility gets personal for me.

I have worked with many genuinely talented people throughout my career. The best teams I have been part of are full of people who challenge each other…people who tell me when my architecture could be better, who disagree with me, who know things I do not, and who push me to improve. I take enormous pride in that. I do not need to be the smartest person in the room; I want to be on a team where everyone makes everyone else better.

That is why credit matters so much. If someone else solved the hard problem, give them credit. If somebody designed the architecture, say their name. If someone spent three weeks fixing the bug nobody else could figure out, tell that story. If the junior engineer found the issue that saved the release, let them explain how they found it.

Good leadership should make those contributions more visible, not less. That aligns directly with Harvard Business Review’s guidance on amplification and the “we-then-me” model.

When the show pony gets the workhorse’s ribbon
#

This is the failure mode I find most frustrating: someone does the visible part, someone else does the difficult part, and the visible person becomes associated with the result while the builder becomes a footnote…or is omitted entirely.

That creates resentment. Worse, it teaches everyone watching that the microphone is more valuable than the wrench.

Once people internalize that lesson, behavior changes. The people who genuinely care about building things start asking themselves: “Why am I doing this much heavy lifting if someone else gets all the recognition?” That is a toxic organizational incentive.

Visibility should amplify contribution, not replace it
#

I do not want to go back to some fantasy world where great work magically speaks for itself. It doesn’t.

Builders need to communicate. Leaders need context. Projects need advocates. Customers need stories. Organizations need to know where value is being created.

So I am not advocating for hiding in the workshop; I am advocating for better visibility…visibility that explains:

  • What problem did we solve?
  • What business outcome did we create?
  • What did we learn, and what risks did we address?
  • What architectural tradeoffs did we make?
  • Who contributed, and what should happen next?

That kind of visibility helps everyone. It makes good work discoverable without turning the workplace into a perpetual marketing campaign.

Leaders have an important role here
#

This is not just a problem for individual contributors; leadership has enormous influence over the behavior that follows.

If leaders constantly reward the person who presents, people will optimize for presenting. If leaders reward the person who creates measurable impact, people will optimize for impact. If leaders ask “Who built this?” the organization learns that contribution matters. If leaders ask “What did this actually change?” the organization learns that outcomes matter. If leaders ask “What happens six months from now?” the organization learns that durability matters.

And if leaders create enough psychological safety for someone to say:

“This is a cool demo, but it isn’t ready for production.”

…they have done something incredibly valuable.

Google’s Project Aristotle research famously identified psychological safety as a central characteristic of effective teams. Engineers need to be able to challenge the prevailing narrative without fear. Sometimes the most valuable person in the room is the one willing to say: “We should not ship this yet.” That person may not get the applause, but they may be doing the most important work in the building.

Responsible AI is an engineering problem
#

The NIST AI Risk Management Framework is another useful counterweight to demo culture. NIST describes trustworthy AI through characteristics that include being:

  • Valid and reliable
  • Safe
  • Secure and resilient
  • Accountable and transparent
  • Explainable and interpretable
  • Privacy-enhanced
  • Fair

Those are not demo-stage characteristics; they are engineering characteristics. They require architecture, automated testing, governance, monitoring, zero-trust security, operational discipline, and, often, uncomfortable conversations.

Maybe the question is wrong
#

Maybe instead of asking: “How visible is this person?” we should ask: “What becomes better because this person is here?”

That question changes everything:

  • Does the business perform better?
  • Do customers have a better experience?
  • Does revenue increase, do costs decrease, and does risk drop?
  • Does the system become more reliable and maintainable?
  • Does the team become stronger, and do other engineers grow?
  • Did the business actually adopt and scale the solution?

Those are much harder things to fake, and they are infinitely more valuable.

I still want to be a workhorse
#

After more than 30 years in technology, I have no intention of stopping being a builder. That is a core part of who I am. My personal site literally describes me as a “Passionate Geek,” and that feels about right.

I still get excited about architecture, writing software, and taking an idea and turning it into something people can use. The more I work with AI, the more interested I become in the engineering required to make it actually useful at scale. That is why so much of what I write about revolves around production architecture, agentic systems, engineering patterns, and turning AI capabilities into tangible economic value.

I want to build things that matter, and I want to build them with people who make me better.

The workhorse should be visible
#

So perhaps the answer is not to choose between visibility and craftsmanship. Perhaps the answer is to redefine visibility.

The workhorse should absolutely be visible, not because the workhorse learned to prance, but because someone bothered to look at what it has been pulling.

The goal should not be to eliminate the show pony. There is a place for people who communicate, inspire, sell an idea, create enthusiasm, and bring attention to good work. We need those people. The problem is when the show becomes more valuable than the work, especially in an era when AI can help us create the show faster than ever.

I want AI to make builders more powerful, not make theater more efficient. I want us to build things that last, reward people who create durable business value, cultivate teams where credit flows toward those who actually contributed, and allow engineers to spend more time building and less time proving that they are building.

Maybe that sounds a little idealistic. After 30 years, I am okay with that. Because when I look back at the work I am most proud of, I do not remember who got the biggest applause. I remember the things that worked: the systems that kept running, the customers who benefited, the business problems we solved, and the teammates I built them with.

Give the workhorse a ribbon. Absolutely. Just do not make the workhorse spend all day practicing its pose. 🐎

Sources and further reading
#