The Engineering Tax
Revealing the Invisible Costs That Destroy Software Product Margins.
Every line of code your team ships carries a hidden cost, and most companies don't see it until it's eating their margins. This book gives you the language to find that cost and the framework to eliminate it.
The Cost Of Complexity
When your company was small, shipping was fast. You had one team, one codebase, and clear ownership. Then you grew, teams multiplied, and dependencies tangled. What used to take a week now takes a month, and nobody can explain why because the problem isn't the people but your business strategy.
Every cross-team coordination point adds a hidden cost to every feature, every bug fix, every deployment. That cost compounds. The business side sees slower delivery and higher burn rates but can't name the cause. The technical side sees architecture problems but can't translate them into financial language.
"There's a real challenge, not only in making the cost of complexity visible, but also closing the gap of communication between tech leaders and non-tech business leaders."
This book builds that necessary bridge and gives both sides a framework to find the cost, name it, and start removing it.
Remove everything that has no demand
Your team used to deliver fast. Now every feature takes longer and costs more than it should. Companies respond by hiring more people and adding more process. That just adds cost without solving the problem. The right move is to find what's slowing you down and remove it. This book shows you how in three steps.
Map your cost curve
Every change your team makes costs time and money, but that cost is rarely visible. This step makes it visible so you stop spending on things that don't pay off.
Decide what to remove
Everything you run costs money to maintain. When a piece of your system costs more than it produces, it needs to go. This step shows you exactly which parts to remove.
Remove it safely
Removing something from a running system is risky, so many approaches skip this step. This one doesn't, and you get a clear process to take out what you identified without downtime or extra work.
Subtraction only works when the organization can negotiate it
Removing what has no demand and knowing when to restructure are not opposing ideas. They are two halves of the same discipline. The gap between them is cultural: who speaks up, what language they use, and whether leaders treat subtraction as a business decision or a technical complaint.
The book spends substantial space on that human layer because most efficiency programs fail there, not in the diagram. When interfaces stay fuzzy, teams stop negotiating contracts. When heroes get celebrated for firefighting, cleanup never gets funded. When experts nod through a cheap path they know is destructive, the Sync Tax compounds in silence.
Speak the language leadership manages
Tech and product must stop trading in story points and start presenting time, budget, margin, risk, and growth. Scenario simulations compare the fast sync path against the modular path so the CEO can decide with numbers, not frustration. That is the organizational and executive protocol in practice.
Negotiate before you say yes
Engineering managers are hired to disagree when an initiative is a bad idea, not to rubber-stamp urgency. Negotiation is a core duty: feasibility checks, repayment plans for quick paths, and incentives that reward low complexity instead of heroic incident response.
Lead up and down at the same time
Middle management is the bridge protocol. Upward, translate drift and structural friction into economic packaging the C-suite can act on. Downward, protect teams from top-down work that would add sync without demand. That double leadership role connects timing to removal.
Align communication with architecture
Conway's Law still applies: meeting-heavy coordination is a signal that boundaries are wrong. Clear domain interface contracts and module ownership turn subtraction from a debate into an operating norm, so the organization and the codebase move toward independence together.
Related chapters include The Organizational Protocol, The Executive Protocol, The Human Protocol, The Architecture of Communication, and The Double Leadership Role.
Know when to subtract
The right time to restructure depends on where you are in the cycle. Move too early and you burn cash on assumptions you haven't proven. Wait too long and your costs compound while competitors move faster. The right timing follows a repeating cycle. Find what works for your customers, deliver it efficiently, then go back to discovery when their needs change. This book shows you how in three steps.
Find what people want
Before the product is proven, the goal is making it perform for real customers. Stay flexible and keep testing what works. Restructuring too early locks in decisions you haven't validated yet. This step shows you when to hold off.
Know when to restructure
Once the product works and demand grows beyond what your current setup can handle, you need to change. More customers, more competitors, more feature demands all signal it's time to move to a more modular structure. This step shows you how to read those signals.
Make it efficient
Once you know what works, switch your focus from discovery to delivery. The market will shift eventually, and when it does, you go back to discovery. This step helps you recognize when to make that call.
Who this book is for
CEOs and founders who watch delivery slow down and costs climb, but nothing in their reports explains why.
CTOs and engineering leaders who see the structural problems but can't translate them into numbers the board takes seriously.
The book is being written now
The Engineering Tax is actively in development. Join the waitlist for early access when chapters are ready to share, and read a free article drawn from the first chapter while you wait.
About the Author
David Vartanian is the founder of Beamer and the author of The Engineering Tax. He works with software companies that struggle to stay profitable because their systems have gotten too complex. His approach is straightforward: if it doesn't satisfy demand, remove it. He focuses on teams that have achieved product market fit.
This book gives you the same methodology he uses with those teams. It shows you how to find the expensive parts of your system, decide what to remove, and do it without breaking the things that actually work.
Learn more about Beamer
David Vartanian
Author & Founder
Read a free excerpt from Chapter 1
Download an article based on The Sync Tax, the opening chapter of The Engineering Tax. You will also receive updates when the book is ready for early access.
We'll email your download link immediately. No spam, unsubscribe anytime.
You're all set!
Check your inbox for your personal download link.
Get early access to The Engineering Tax
The book is in progress. Leave your email and we will notify you when new chapters and early access are available.
No spam, ever. You can unsubscribe at any time.
You're on the list!
You are on the list. We will reach out when there is news about the book and Beamer releases.