The Product Manager Is Dead. Long Live the Product Developer
The person who walks into the room with Figma mockups and says 'build this' has run out of runway.
Why Electricians Have Authority and Developers Don't
7 min read
When the Light Turns On, the Argument Ends
03.03.2026, By Stephan Schwab
Electricians work with objective pass/fail states, codified standards, and inspectable outcomes. Software developers work with fuzzy requirements, subjective success criteria, and invisible complexity. This difference explains why everyone has opinions about software but nobody argues with the electrician.
"Nobody hires consultants to transform how the electrician terminates connections."
A friend recently asked me why electricians don’t suffer the same problems software developers face. An electrician does an installation, it either works or it doesn’t, and that’s the end of the story. Nobody tries to control narratives about electrical work. Nobody schedules meetings to discuss whether the wiring is “aligned with business objectives.” Nobody hires consultants to transform how the electrician terminates connections.
When it comes to software, everyone has opinions. Project managers, executives, stakeholders three levels removed from the work, that guy in marketing who once built a WordPress site. They all feel qualified to weigh in on how the work should be done.
Why the difference?
The Gift of Objectivity
"The light turns on or it doesn't. There's no meeting to discuss whether it's 'on enough.'"
Electrical work enjoys something software development desperately lacks: objective pass/fail states.
Either the circuit is wired correctly or it isn’t. Either the light turns on or it doesn’t. Either the breaker trips when it should or it doesn’t. There’s no meeting to discuss whether the light is “on enough” or whether the circuit is “aligned with the strategic vision.”
Standards are codified in law. Color codes, cable types, breaker sizes, grounding requirements, protection schemes — all written down, tested, and enforced. Inspectors check compliance against explicit criteria. The variability of requirements is small. A 20-amp circuit feeding kitchen outlets is a 20-amp circuit feeding kitchen outlets. The electrician doesn’t get halfway through the job and hear “actually, we’ve decided it should also make coffee.”
This objectivity gives electricians something precious: authority. When the electrician says “that’s not up to code,” the conversation ends. There’s no negotiation, no alternative interpretation, no stakeholder alignment session. The code is the code.
The Curse of Subjectivity
"Fast enough for whom? Good enough compared to what?"
Software development operates in a different universe. Requirements are fuzzy, constantly changing, and often internally contradictory. One stakeholder wants speed, another wants stability, a third wants features that conflict with both. The requirements document — if one exists — was outdated before the ink dried.
What does success even mean? “Fast enough.” Fast enough for whom? Under what load? On what hardware? “Good enough.” Good enough compared to what? “Maintainable.” By what future team with what unknown skills?
There’s no universally enforced codebook. Sure, there are standards — coding conventions, security guidelines, architectural patterns — but none carry legal weight. Nobody inspects your repository and issues citations.
"Using an app makes people think they understand how it's built."
Here’s where it gets worse: everyone uses software daily. Your CEO uses an iPhone. Your marketing director uses Slack. Your board members use email. This familiarity creates an illusion of understanding. Using an app makes people think they understand how it’s built. It’s like believing you understand automotive engineering because you drive a car.
The cost of software mistakes is often delayed, invisible, or shifted. That architectural shortcut taken to hit a deadline? It won’t hurt until eighteen months from now when the team tries to add a feature. The security vulnerability? Silent until exploited. The technical debt? Accruing interest in the background, payable by some future developer who wasn’t in the room when the decisions were made.
The Visibility Problem
"You can't point to code the way you can point to a junction box."
When an electrician finishes work, you can see it. Wires terminate at boxes. Conduit runs along walls. Breakers sit in panels with labels. A non-electrician might not understand the details, but they can observe that work happened and roughly grasp what it does.
Software development produces invisible artifacts. Code lives in repositories that stakeholders never visit. Architecture exists as boxes and arrows on diagrams that approximate reality. The actual work — the logic, the data structures, the error handling, the edge cases — is hidden from view.
This invisibility creates a vacuum that narratives fill. When you can’t see the work, you need someone to tell you about it. And once you need stories about the work, you’ve opened the door to competing stories. Suddenly everyone has a narrative. The deadline narrative. The technical debt narrative. The “we just need to try harder” narrative. The “developers are too slow” narrative.
You can’t point to code the way you can point to a junction box and say “look, that’s what we built, that’s where we are.” Software status is always mediated through interpretation.
The Power Vacuum
"If nobody can verify whether software is 'good,' then whoever controls the narrative controls the perception of quality."
The combination of subjectivity and invisibility creates a power vacuum — and power vacuums get filled.
If nobody can objectively verify whether software is “good,” then whoever controls the narrative controls the perception of quality. Stakeholders want control because software affects their domain. Marketing wants features that support campaigns. Sales wants features that close deals. Finance wants predictability. Operations wants stability.
None of these stakeholders can evaluate the technical work directly. But they can evaluate narratives. They can judge whether the project “feels” on track. They can assess whether developers seem “responsive” to business needs.
This is why so much software development becomes performance. Status meetings aren’t about status — they’re about controlling perception. Demos aren’t about functionality — they’re about creating confidence. Velocity metrics aren’t about measuring productivity — they’re about providing something countable to put in slides.
What Electricians Don’t Face
"Nobody asks the electrician to estimate how many outlets they can install in a two-week sprint."
Electricians don’t face management frameworks. Nobody implements Scrum for electrical installations. Nobody asks the electrician to estimate how many outlets they can install in a two-week sprint and then tracks velocity over time. Nobody restructures the electrical contracting company into tribes and squads.
Electricians don’t face fashion cycles. There’s no thought leader circuit advocating that we fundamentally rethink how wires connect to terminals. Nobody sells certifications in the latest breakthrough approach to running conduit. The work changes when technology changes — when LED replaced incandescent, when smart home systems emerged — not because someone needed a book deal. As I explored in Management Frameworks and the Proximity to Snake Oil, the incentive structures in software consulting favor selling process over verifiable outcomes.
Electricians don’t face the assumption that speed requires shortcuts. When a building needs electrical work faster, you hire more electricians or pay overtime. You don’t ask the existing electricians to skip the grounding or use thinner wire. The code won’t allow it. The inspector won’t pass it. The building won’t function safely without it.
The Escape Route
"Objective signals that don't require interpretation."
So what can software development learn from electrical work? Not everything transfers — software genuinely is more complex and variable — but some things do.
Create objective signals. Continuous integration that passes or fails. Automated tests that execute or break. Deployment pipelines that either deliver working software or don’t. These aren’t perfect — they still require judgment about what to test and measure — but they’re more objective than status meetings and confidence votes.
Make work visible. Not through slides and reports — through working software. Deploy frequently so stakeholders can see what exists, not just hear about it. When the feature runs in production, the narrative competition ends. Either users can do the thing or they can’t.
Codify standards. Internal coding standards, architectural decision records, security requirements with automated enforcement. These won’t carry legal weight, but they establish expectations that reduce the space for interpretation.
Acknowledge what can’t be fixed. Some subjectivity is inherent to software. Requirements will change because the world changes. Success criteria will stay fuzzy because businesses operate in fuzzy environments. You can’t eliminate this — you can only stop pretending it doesn’t exist. Honest uncertainty is better than false precision.
The Core Difference
"Electrical work is fact-driven. Software development becomes narrative-driven."
Electrical work stays fact-driven, inspectable, and unaffected by fashion or management frameworks. The light turns on. The circuit is protected. The code compliance sticker goes on the panel.
Software development becomes narrative-driven because the work is invisible. Opinion-ridden because quality is hard to judge early. Management-controlled because measurable engineering discipline is often missing.
The next time someone asks why developers face interference that electricians don’t, you have the answer: electricians work with objective reality. Developers work in a narrative vacuum that everyone wants to fill.
The solution isn’t to become electricians — software genuinely is different. The solution is to create enough objective signals that the narrative vacuum shrinks. When the deployment pipeline is green, when production metrics show users completing their tasks, when the code passes every automated check — those become the facts that limit how much opinion can intrude.
Not every argument will end. But some will. And that’s a start.
Contact
Let's talk about your real situation. Want to accelerate delivery, remove technical blockers, or validate whether an idea deserves more investment? I listen to your context and give 1-2 practical recommendations. No pitch, no obligation. Confidential and direct.
Need help? Practical advice, no pitch.
Let's Work Together🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
Al Borde del Abismo
Valentina's mother needs emergency surgery — 1.2 million pesos they don't have. Bruno offers a devil's bargain: work exclusively for him on a 'spec...
The Backlog Explosion
The product backlog explodes to 147 items with 89 marked high priority. Ayşe Demir, the product manager, tries to impose order but Lukas keeps addi...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- Authentication Methods That Work in 2026 (03.04.2026)
- Developer, Not Engineer. And Why It Matters (30.03.2026)
- The Product Manager Is Dead. Long Live the Product Developer (27.03.2026)
- Building Products in the Age of AI (23.03.2026)
- When AI Becomes Your Thinking Partner (20.03.2026)