Why a Technical Team That Never Disagrees With the Founder Is a Warning Sign
Research from McKinsey and Bain shows that leaders overestimate their own decision-making table. For tech founders, mistaking silence for alignment leads to wrong and costly technical decisions.
- Reading
- 6 min
- Tables
- 1
Research from McKinsey and Bain shows that leaders overestimate their own decision-making table. For tech founders, mistaking silence for alignment leads to wrong and costly technical decisions.
Editor's note: this article uses as an analogy the caricature of the "Zorro manager," by Pedro Mandelli, and the phrase "disagree and commit" to describe the post-decision phase of a technical debate. The original source (Exame, a Brazilian business magazine) describes Zorro as someone who "shows up only when there's a problem, scares it off, but doesn't solve it," and does not literally use the phrase "disagree and commit." We kept the text as produced, but note here that these two points are formulations and interpretations by the article's author, not exact quotes from the source, so that the reader can take this into account when evaluating the examples.
Research from McKinsey and Bain shows that leaders overestimate their own decision-making table. For tech founders, mistaking silence for alignment leads to wrong and costly technical decisions.
A Table That Agrees Quickly Doesn't Prove You're Right
Every founder walks into an architecture, hiring, or scope-cutting meeting expecting alignment. The problem appears when alignment comes too fast, every time. A recent article by advisor and former executive Jean Klaumann (with stints at Neogrid, Linx, TOTVS, and Oracle) in Exame sums up the point in a sentence that applies to any board, including the technical one.
A table that agrees quickly doesn't prove the CEO is right. It proves that no one there is paid to say he's wrong.
Jean Klaumann, advisor and former technology executive, in an article for Exame
Swap CEO for CTO, board for engineering staff, and the sentence doesn't lose a comma of validity. The question every technical founder should ask isn't whether the team agrees with him. It's whether someone there is paid, protected, and heard when they disagree with data in hand.
What McKinsey and Bain Measured, and What It Means for Those Who Lead Code
The article cites two data points that deserve the attention of anyone building an engineering team, not just a C-level. McKinsey, in 2025, measured senior leadership teams at 28 large companies and found a pattern: CEOs consistently rate their own team's effectiveness more favorably than the members of that team rate themselves. Bain, in a 2026 survey of one hundred CEOs, found fewer than half confident they had the right people in the right roles, and listed ownership, curiosity, and willingness to take risks as precisely the scarce traits.
In tech startups, this bias has a specific practical effect: the technical founder tends to judge their own architecture, stack, and roadmap more generously than the team that lives with the code every day. If no one in the technical decision meeting has the budget, title, and psychological safety to say "this design doesn't scale" or "this hire is the wrong person," the founder's optimistic assessment is never tested before it turns into a loss in production or in runway.
The Three Types of Senior Engineer at Your Table
Klaumann describes three profiles that make up any leadership table: those who follow, those who approve, and those who develop the leader. Translating this to a technical team helps you see your own org chart with different eyes.
| Profile | What They Deliver | Risk If They're the Majority |
|---|---|---|
| Those who follow | Execute well what was decided, without questioning the premise | Wrong technical decisions reach production intact |
| Those who approve | Confirm what the founder already thought, create a sense of consensus | Lack of real pressure on architecture, security, and cloud cost |
| Those who develop | Bring the missing data, the alternative hypothesis, the disagreement that's costly to hear | Short-term friction, but decisions tested before going live |
No team functions with only the third group. The problem, as the article points out, isn't the existence of the first two profiles: it's when the team's contribution ends there. A staff engineer who never questions the choice of database, a head of security who never blocks a deploy over risk, a data lead who never discusses pipeline quality before feeding a production model, all of these are signs of a table that only follows and approves.
The Zorro Manager of Infrastructure
The article revisits a caricature by Pedro Mandelli, from his book Muito Além da Hierarquia (loosely, "Far Beyond Hierarchy"): the Zorro manager, who shows up only when there's a fire, solves it alone, and teaches the team that waiting for the boss is the safest option. In engineering, this figure is the tech lead or technical founder who only gets involved in architectural decisions once something has already broken, and who resolves the incident alone instead of making room for the team to propose the fix. Each heroic rescue reinforces the habit of not disagreeing before the problem happens.
Deborah Ancona and colleagues at MIT wrote about the "incomplete leader": whoever hires and promotes only people who think like them ends up with an organization that leans entirely to one side. A product founder who only hires engineers who agree with their own UX vision builds a team blind to the same angle they are blind to. Diversity of technical disagreement isn't an abstract cultural value: it's the mechanism that catches the blind spot before the customer does.
The Counterargument: Disagreement Without an Owner Becomes Paralysis
Not every founder who reads this should leave the meeting throwing open unrestricted space for endless technical debate. That's the real risk on the other side: engineering teams are famous for endless discussions about language, framework, or architecture pattern that never converge into a decision, classic bikeshedding. Disagreement that never ends in an owner and a deadline is just as costly as silence, only slower to notice.
The answer that Klaumann's own article points to, summarized in the principle of "disagree and commit," is to separate two phases. In the debate phase, technical disagreement backed by data is welcome and should be actively demanded of whoever is closest to the code. Once the decision is made, someone owns it and the whole team owns the execution, even those who disagreed. That's what separates a team that develops the founder from a team that only produces noise.
Four Questions for the Founder to Ask Their Own Technical Team
Adapting the mirror proposed in the original article for an engineering table, four questions are worth more than any climate survey:
- For each senior person on the technical team, what predominates: following, approving, or developing your decision?
- Who changed a technical decision of yours with concrete data this quarter, and what happened to that person afterward?
- Does your engineering team jointly own the production outcome, or does it wait for you to resolve what happens between backend, data, and security?
- Is there someone at your table whose explicit job is to disagree with you before the customer, the regulator, or the press disagree on your behalf?
The composition of the technical team reveals the founder's own standard. The way it contributes reveals the real space the founder offers for being contradicted. Both deserve review before the startup needs to scale beyond the answers already sitting at the table.
Translated from the Brazilian Portuguese original · Read the original
YC's post-money SAFE: the cap stacking that dilutes the founder without them noticing
Y Combinator documentation shows how the post-money SAFE, the standard since 2018, promises cap-by-cap transparency, but that clarity vanishes in practice when founders stack several bridge rounds without recalculating the total sold.
