Steffen Uhlig

On the Impedance Mismatch between Agile and Classical Business Management

2026-05-25T17:50:00+02:00

I have long tried to understand why</em> management insists on fixed-time, cost, and scope when planning software development projects. This article is an attempt to explain why this pattern occurs, and what organizational change may be able to fix it. While I was experimenting with some audio equipment, it came to me that what we call an impedence mismatch in electrical engineering is actually a common problem in software development, too. Perhaps we can learn about the solution from a domain that has this problem solved?</p> </blockquote>
Whenever two systems speak different languages, connecting them requires more than a simple cable. Without a proper adapter, energy dissipates as heat, signals distort, and eventually something burns out. Engineers have a precise term for this: impedance mismatch</strong>. It describes what happens when the internal resistance of a source does not match the load it drives.</p>
This concept is not limited to physics. The same pattern appears in software architecture, and most critically in the relationship between agile development and classical business management. Understanding the pattern across all three domains makes it easier to see why the organizational version is so destructive, and what kind of "transformer" is needed to fix it.</p>
Amplifiers and Speakers</h2>
In audio engineering, an amplifier is designed for a specific load impedance, typically 8 ohms. Connect a 4-ohm speaker, and the resistance drops by half. Ohm's law dictates that the current doubles. The amplifier's output stage is now pushed beyond its specification.</p>

"A simple source and load circuit</a>" by Cjp24</a> is licensed under the Creative Commons</a> Attribution-Share Alike 4.0 International</a> license. </figcaption> </figure>
The symptoms are immediate and physical:</p>

Overheating. The transistors must carry more current than they were built for, generating excess thermal load. If the heat sinks cannot dissipate it, the device fails.</li>
Clipping. When the amplifier can no longer reproduce the signal cleanly, it cuts off the waveform peaks. The resulting distortion contains DC components that can destroy the speaker's tweeters.</li>
Power-supply collapse. The transformer and capacitors may not deliver the doubled demand, causing voltage sag or blown fuses.</li> </ul>
The solution is not to yell at the amplifier for underperforming. The solution is to match the impedances, either by selecting the right speaker, or by inserting a transformer that adapts the load to the source.</p>
Object-Relational Mappers</h2>
Software engineers use the exact same term, impedance mismatch, to describe the friction between object-oriented programs and relational databases. Object-oriented design thinks in graphs: nested structures, inheritance, encapsulation, and behavior. Relational design thinks in flat tables, foreign keys, and normalized rows. They are fundamentally different logics.</p>

An Object-Relational Mapper (ORM) transforms objects into database rows and back again.</figcaption> </figure>
An Object-Relational Mapper (ORM) such as Hibernate or Entity Framework is the adapter placed between these worlds. It translates objects into rows and back again. But if the mapping is naive or ignored, the system pays a heavy price:</p>

Performance loss (heat). A poorly configured ORM can issue hundreds of queries for a single logical operation, the infamous N+1 problem. The database CPU burns cycles on translation instead of on actual work.</li>
Abstraction leakage. When the relational reality "leaks" into the application code, developers lose the very transparency the ORM was supposed to provide.</li>
Complexity debt. The convenience of automatic mapping often hides what the database is really doing, making optimization impossible until the system chokes.</li> </ul>
A skilled engineer does not blame the database for being relational, nor the code for being object-oriented. She designs the mapping layer carefully, because she understands that the mismatch is real and that ignoring it will eventually degrade the whole system.</p>
Agile Development vs. Deterministic Management</h2>
The same mismatch reappears when classical business management meets agile software development. Only here, the consequences are human rather than thermal.</p>
Management often operates from a deterministic paradigm: fixed budget, fixed deadline, fixed scope. This mindset works well for repeatable, well-understood endeavors such as building a bridge, manufacturing a batch of parts. But software development is not manufacturing; it is empirical learning. Most of the time, the team is solving a complex problem for the first time. The path is unknown, and the map must be drawn while walking.</p>
When deterministic expectations are connected directly to an empirical process, the organizational equivalent of an impedance mismatch occurs:</p>

Thermal load (burnout). The pressure on the team rises linearly with the unpredictability of the work. People compensate with overtime, and the friction between management and engineering generates heat in the form of conflict and attrition.</li>
Clipping (technical debt). To meet fixed deadlines with fixed scope, quality is sacrificed. The "signal" (the codebase) becomes distorted. Shortcuts accumulate, and eventually the system becomes unstable, just as a clipped signal destroys a tweeter.</li>
Scrum theater (cheap adapter). A team may adopt the rituals of agility (daily standups, sprints, retrospectives) while still being managed to a rigid Gantt chart. This is the organizational equivalent of a cheap adapter that pretends to transform the signal but merely passes the overload through.</li> </ul>
The Transformer</h2>
In electrical engineering, the mismatch is often solved with a transformer. In software architecture, it is solved by a carefully designed ORM. In the organization, the transformer is the Product Owner</strong> (and, by extension, an agile coach or engineering leader).</p>
The product owner's job is not merely to collect requirements and prioritize tickets. The product owner is an active regulator whose primary responsibility is to translate between incompatible paradigms and to protect the system from overload.</p>
This means telling the truth upward: fixed planning parameters in an uncertain environment are not a sign of discipline; they are a short-circuit waiting to happen. When time and cost are fixed, scope must remain variable, or quality will collapse. The product owner must make this physical reality visible to management, using the same clarity an engineer uses when explaining why a 4-ohm speaker will destroy an 8-ohm amplifier.</p>
Practical Techniques</h2>
How does a product owner actually perform this translation? Here are some practical techniques:</p>

Visualize the iron triangle. Show that time, cost, and scope are rigidly coupled. Lock all three, and quality (the central pillar) implodes. A simple diagram is often more effective than a thousand project reports.</p>

Fixing Time, Cost, and Scope forces Quality to absorb all the pressure.</figcaption> </figure> </li>

Use evidence, not opinion. Track velocity and cycle time. If the system demonstrably delivers twenty units per sprint, demanding forty will not double output; it will only double defects. Numbers remove emotion from the conversation.</p> </li>

Replace dates with horizons. Instead of Gantt charts promising delivery on a specific day, use roadmaps organized as Now, Next, and Later. This gives leadership strategic orientation without forcing the team to commit to a cadence it cannot sustain.</p> </li>

Negotiate outcomes, not outputs. Promise the solution of a business problem, not a fixed list of features. This satisfies management's need for return on investment while preserving the team's freedom to discover the best technical path.</p> </li>

Protect the Definition of Done. Treat it as non-negotiable infrastructure, like the insulation on a high-voltage cable. It exists to prevent technical debt from accumulating silently until the system fails.</p> </li> </ul>
Conclusion</h2>
Whether in an audio circuit, a database layer, or an organization, an impedance mismatch signals the same thing: two subsystems with incompatible parameters have been connected without a proper adapter. The result is always loss: of energy, of performance, or of people.</p>
The required adaptation is not a matter of preference or culture, it is structural. Just as a transformer is not optional when impedances differ, a mediating role between deterministic management and empirical development is not optional when the goal is sustainable delivery. The organization must accept that control through fixed plans is an illusion in complex domains, and replace it with control through visibility, feedback, and continuous adjustment.</p>
Only when the impedances are matched can the full energy of the organization flow into the product, cleanly, without distortion, and without burning anything out.</p>

My Top 10 homebrew packages

2024-05-18T00:00:00+00:00

My son Felix recently switched to a Mac and asked me about my Top 10 homebrew</a> packages.</p>
But what is homebrew?</p>

The Missing Package Manager for macOS</p> </blockquote>
Installing software (both Open Source and commercial) mostly becomes a single command-line invocation, like brew install jq</code>.</p>
Command-Line Tools</h1> My Top 10</h2>#10: qsv</a></h3> Ultra-fast CSV data-wrangling toolkit</p> </blockquote> CSV is a popular data format. Often I need to manipulate, extract or simply view a CSV file, and qsv</code> ("quicksilver") makes it easy to process even very</em> large files.</p> Example: FragDenStaat.de has published a list of some Resident Registration Offices</a> in CSV format. The file has some problems (not in UTF-8 format, semicolon instead of comma, no headers), but we can use qsv</code> to fix all of that and then display the last 10 addresses:</p> $ curl --location --silent 'https://fragdenstaat.de/files/foi/6128/Anschriften_Meldebehrden.csv.csv?download' \ | iconv --from ISO-8859-1 --to UTF-8 \ | qsv input --delimiter ';' \ | qsv sort --select 3 --numeric --no-headers \ | qsv table \ | tail --lines 10 </code></pre> </p> #9: jq</a></h3> Lightweight and flexible command-line JSON processor</p> </blockquote> JSON</a> has been invented for the web, but it became very popular as a general data exchange format; even for command-line tools.</p> Let's say we want to get some structured information about the jq</code> package in homebrew:</p> $ brew info jq --json </code></pre> If we only want the description, we can use jq to extract just that field:</p> $ brew info jq --json | jq '.[].desc' </code></pre> #8: gh</a></h3> GitHub command-line tool</p> </blockquote> I work with GitHub a lot, and this tool lets me perform most of the daily tasks from the command-line, for example listing the pull requests for a repo:</p> $ gh pr list --repo suhlig/httpspell </code></pre> </p> #7: direnv</a></h3> Load/unload environment variables based on $PWD</p> </blockquote> I organize most non-trivial projects in separate directories. All the project-specific environment variables can go into a .envrc</code> file, and when you enter the directory the variables in that file will be added to your current shell. Leaving the directory unloads them.</p> Example: I have multiple projects that connect to different MQTT brokers (using separate users and passwords). In each project directory, I have a .envrc</code> file that keeps the URL to the broker. cd</code> from one project to another activates the right environment variable for the project:</p> $ cat project-A/.envrc export MQTT_URL=mqtts://alice:s3cret@mqtt.example.com/some-topic $ cat project-B/.envrc export MQTT_URL=mqtts://bob:geh3im@mqtt.example.com/other-topic </code></pre> Now direnv will set the content of $MQTT_URL</code> to the respective value when changing directories:</p> $ cd project-A </code></pre> $ cd ../project-B </code></pre> #6: shellcheck</a></h3> Static analysis and lint tool, for (ba)sh scripts</p> </blockquote> Shell scripting in bash</code> is full of footguns</a>. I try to standardize on zsh</code>, which has way fewer quirks, but bash</code> is still the queen of compatibility. shellcheck</code> prevents the larger disasters from happening.</p> #5: shfmt</a></h3> Autoformat shell script source code</p> </blockquote> Similar to shellcheck</a>, this tool keeps me honest about style and formatting of shellscripts I write.</p> #4: pandoc</a></h3> Swiss-army knife of markup format conversion</p> </blockquote> All text I write starts in Markdown format</a>. The desired output format is generated using pandoc. It can convert from and to many formats</a>; I most often use</p> Markdown => HTML</li> Markdown => PDF</li> Microsoft Word => Markdown</li> </ul> Markdown to reveal.js slides</a> is also great; I wrote all the slides of my Web Services lecture</a> in Markdown and publish them as HTML.</p> #3: ripgrep</a></h3> Search tool like grep and The Silver Searcher</p> </blockquote> This is one of the tools that convinced me that performance is a feature</a>, even more so on the command-line. ripgrep</code> is so fast that I never</em> hesitate trying to find a piece of code on my computer.</p> Example: Searching for the term ansible_managed</code> in 72 GiB of source code took less than three seconds:</p> $ rg ansible_managed ~/workspace </code></pre> There is also ripgrep-all</a>, which understands PDF and other formats.</p> #2: tmux</a></h3> Terminal multiplexer</p> </blockquote> tmux</code> is probably best known for its capability to split a terminal window into separate panels, so that you get two independent "windows" to work in.</p> In this example, I have jekyll serve</code> running in the upper pane, and an interactive shell running in the lower pane, so that I can commit using git</code> while still seeing the output of jekyll</code> in the upper:</p> I also came to appreciate the fast change between different projects in separate terminal windows, jumping back to the recently used session with Ctrl-A, L</code> or to the previously active pane with Ctrl-A, p</code>.</p> #1: atuin</a></h3> Improved shell history for zsh, bash, fish and nushell</p> </blockquote> Shell history is my #2 asset and productivity tool. All commands I execute, together with all arguments, pipelines, indirections, etc. are saved to a local SQLite</a> database. This makes for a great searchable journal of commands. It is not uncommon for me to re-use a command from years ago that I found in my history.</p> Some random bits:</p> My oldest history entry is from June 2020, but that was recorded at the time by zsh_histdb</a> and later imported into atuin</code>.</li> I don't use the sync</code> feature atuin</code> provides, because I mostly work off the same computer.</li> I find atuin</code> so precious that I became a (minor) sponsor for the project</a>.</li> </ul> Honorable Mentions</h2> bat</a></h3> Clone of cat(1) with syntax highlighting and Git integration</p> </blockquote>