Promoting your best engineer to manager without preparation is the most expensive decision a founder can make

The wrong merit becomes a P&L cost

A report from Exame, a Brazilian business magazine, published today, November 12, describes a pattern I repeatedly see on the boards of Brazilian startups: the most technical person on the team becomes the manager, and months later the company discovers it lost its best engineer and gained a mediocre leader.

The report treats this as an individual gap, a lack of holistic business vision. I partly disagree. The problem isn't only with the promoted professional: it lies with whoever designed the promotion without a career path, without criteria, and without a plan B. This is a misallocated-capital decision, and it's up to the founder, not just HR, to fix it.

The Peter Principle is no office joke

The so-called Peter Principle, a concept widely discussed in management literature, describes this pattern well: professionals rise to the level at which they stop being competent, because the evaluation yardstick is performance in the previous role, not the next one.

In tech this has a specific variant. The engineer is promoted for solving architecture, latency, or technical-debt problems well. None of those metrics predict whether they can negotiate priority with the sales team, cut scope under cash pressure, or give hard feedback without freezing the team.

What actually changes in the senior leadership seat

Exame correctly points out that executive roles require reading financial statements, assessing project profitability, and understanding cross-departmental effects. That's a direct P&L translation: the technical manager who doesn't see that interplay approves an operating-cost cut that looks great on his spreadsheet and wrecks the customer experience three months later.

The article's most concrete example is the decision about AI. An automation project isn't evaluated only by the productivity gain for the technical team: it involves technology investment, staff retraining, sensitive-data exposure, and impact on other departments. That's exactly the kind of decision that today lands on the desk of any founder deciding where to bet AI budget, and one that a manager trained only in code doesn't have the repertoire to discuss alone.

The dual ladder Silicon Valley tested and Brazil still underrates

The most common mistake I see on boards is treating "becoming a manager" as the only way to recognize technical excellence. For fifteen years part of the industry has solved this differently: the dual ladder, a senior specialist career track (staff, principal) that keeps growing in technical scope and compensation without requiring people management, running parallel to the management track.

Part of the tech industry argues that many failed transitions from engineer to manager happen because the company offers no alternative: either you manage people, or your career stalls. Some tech companies maintain staff-engineer tracks with no direct reports, precisely to avoid forcing that binary choice. In Brazil, this dual-ladder design also appears, less publicly, at companies seeking to retain senior technical talent without forcing them into people management: the tech lead deepens architecture and technical decisions, the engineering manager takes on people, budget, and delivery, distinct tracks, comparable pay.

The counterargument: early-stage startups don't have the cash for two ladders

The strongest objection I've heard from a founder on a board is fair: with eight or ten engineers, building a formal dual ladder is too much structure for the team's size, and the cost of designing it early competes with runway.

I agree, to a point. A formal dual ladder, with levels, pay bands, and a promotion committee, makes sense from a scale most seed-stage startups don't yet have. But that doesn't let the founder off the hook for the cheap part: exposing the candidate to business metrics, budget, and customer decisions before giving them the title, not after. The cost of testing this informally for three months is far lower than the cost of losing your team's best engineer and discovering, six months later, that the replacement couldn't handle the seat either.

What I'd ask before approving the promotion

On a board, the questions I'd raise before the decision, not after:

• Does this person already influence roadmap and priority without formal authority, or do they just execute well what's handed to them?
• Have they already discussed business trade-offs (cost, timeline, customer experience) with another department, or only defended the technical solution?
• Is there a plan B if the promotion doesn't work out in six months, can they return to the technical role without losing status or pay?
• Is the company promoting them because it's the only way to retain this person, or because they genuinely want to and have the profile to manage people?

My position

The mistake that Exame's report describes well, but doesn't name as such, is treating technical competence and management competence as the same learning curve. They aren't. And so far, the most tested answer the tech industry has found wasn't sending everyone to an MBA before promoting them, it was to stop forcing the best technical person to choose between growing and managing people.

For the founder, the right question isn't "does this engineer deserve the promotion." It's "does this role require managing people, and does this person want to and can do that, or am I using the only title I have to recognize someone I don't want to lose." Confusing the two is the most expensive and quietest way to destroy a good technical team.