You've seen this happen before, probably more than once. Two architecture proposals on the table. One is cheaper, simpler to operate, with fewer points of failure and less dependency on a single specialist. The other costs more, needs more people, more time, more meetings. The committee approves the second one.
Nobody in the room will say "we picked the worse option because its author has lunch with the VP every Thursday." What comes out is always technically respectable: "the other solution scales better long-term," "this one reduces technical debt," "it's better aligned with the data governance the platform team has been pushing for." Sentence by sentence, none of it is a lie. And yet none of it is the real reason for the decision.
You leave the meeting knowing, with an uncomfortable certainty in your gut, that you lost for a reason that wasn't on any slide. Then comes the worse part: you can't name that reason without sounding paranoid, or bitter, or "too political" — exactly the label the person who won will never get, because they were careful never to say the word "power" out loud.
This pattern isn't a rare accident of a broken process. It is the process. It repeats in architecture decisions, in roadmap priorities, in who signs the RFC, in who gets the credit for the project that worked and who gets the blame for the one that didn't. It's frequent and regular enough to become a law. This pattern is what became the book "As Leis do Poder em Projetos" (The Laws of Power in Projects).
The mechanism: power wearing a competence badge
Every tech company runs two operating systems in parallel. One is documented: architecture, metrics, OKRs, post-mortems, security committees, RFCs, promotion criteria. The other never shows up in the minutes, but decides just as much as the first one: who gains territory, who gets spared when the project blows up, who's allowed to disagree in public, and who's only allowed to disagree "later, in private."
The reason this second system is nearly impossible to point a finger at is simple: it speaks the exact same language as the first one. "Technical debt" is a real engineering category — and also the perfect label for any old decision someone wants to revisit for reasons that have nothing to do with actual debt. "That service doesn't scale" might be a fact about capacity — or it might be the sentence that kills a rival team's project without anyone having to admit the problem was never scale. Metrics, security, compliance, governance: each of these words has the same property. From the outside, they're indistinguishable from pure technical competence. That's exactly why they work so well as weapons — and why no one is ever held accountable for using them that way.
Questioning a security veto in public, for instance, doesn't look like technical rigor. It looks reckless. So nobody questions it, and the veto becomes the most efficient power instrument in the company — protected by the simple fact that disagreeing with it is socially expensive, even when it's being used for the wrong reasons.
None of this requires a closed-door conspiracy. It's structure, not a plot: any hierarchy that distributes budget, prestige, and career survival unevenly will generate competition for those resources. What's particular about tech is that this competition is almost never called by its name. It's called architecture.
The book: 34 laws, six parts, from diagnosis to defense
"As Leis do Poder em Projetos" organizes this pattern into 34 laws, split into six parts that go from "this is happening to you right now, nobody just used that word" to "what to do about it without becoming the next person who does it to others."
I · Manufacturing the Problem
Before any power struggle has a winner, someone first needs to convince everyone that a problem exists — and, preferably, that only one specific solution solves it. This part maps how crisis narratives are manufactured, inflated, and timed before any actual technical decision reaches the table.
- Some people light fires to sell extinguishers
- "Technical debt" is a rhetorical weapon, not just an engineering concept
II · Owning the Narrative
Whoever decides which version of events survives into next quarter holds more power than whoever actually solved the problem. This part is about how a project's story gets written — and rewritten — by whoever controls the documents, the channels, and, above all, the vocabulary used to describe what happened.
- Whoever writes the post-mortem writes history
- Whoever controls the vocabulary controls the debate
III · Capturing Territory
Technical merit and upward mobility inside a company rarely follow the same ruler, and pretending otherwise only delays the moment you realize it. This part is about how territory — scope, headcount, visibility, access — gets won and defended, and why being in the right place at the right time usually beats having done the right work.
- Credit goes to whoever is on stage on demo day
- Turtles don't climb trees on their own: merit and promotion are not the same thing
IV · The Executive's Game
At the top, the rules change again. Decisions that look purely strategic are, with uncomfortable frequency, about the executive's personal survival within their own tenure — which usually lasts less than any three-year roadmap. This part looks at the board from the perspective of someone who only has a few quarters to show results before the next reorg.
- The CIO doesn't pick the best technology; they pick the one that survives the next change of command
- Decide which fires to let burn
V · Security, Risk, and Compliance as Power
When a dispute can't be won on technical merit, it tends to migrate to the one terrain where questioning looks reckless instead of rigorous: security, risk, compliance. This part exposes how these domains — created to protect the company — also work as the most efficient veto available to anyone willing to use it.
- Security is the one veto nobody dares challenge in public
- Every exception becomes a precedent — and every precedent becomes power
VI · Surviving Without Being Naive (the defense)
The last part switches sides. After mapping the game, the book turns to how to play it without becoming what it describes — how to protect good work, allies, and reputation without resorting to the same dirty tactics the rest of the book spent five parts documenting.
- Don't win arguments; win before them
- Being right is necessary; having narrative, timing, and allies is what makes being right count
This is not a manipulation manual
It's worth repeating, because it's easy to read the list above and conclude the opposite: this isn't a book about manipulating people to win internal disputes. The same tools that run through all 34 laws — controlling the narrative, choosing the timing, building allies, naming the problem before someone else names it for you — don't inherently belong to whoever acts in bad faith. They belong to whoever uses them first and uses them best.
The difference between using these tools to defend honest work and using the same tools to sabotage someone else's isn't in the tool. It's in who decides what to load into it. You can write a rigorous post-mortem and still write the story. You can build allies to protect the right decision, not to bury the right person. The book doesn't pretend that line doesn't exist — it just argues that pretending the whole game doesn't exist is the fastest way to lose to whoever plays without that hesitation.
Political clarity isn't the same thing as cynicism. It's the difference between being blindsided by the game and choosing, eyes open, what to do with the cards it deals you.
Launch
As Leis do Poder em Projetos (The Laws of Power in Projects) is currently in presale on Amazon, with launch expected for July 9, 2026.
The book is currently available in Portuguese, but I'm considering an English edition if there is enough interest from the international software engineering community.
Top comments (0)