Managing up: how I learned to give a founder bad technical news
The hardest conversation I had as a CTO was not reporting a failure. It was making a recommendation the founder did not want to hear.
The product was a regulated product. The mobile apps were the heart of it: a few years of native development, two separate codebases. I walked into the founder’s office to tell him we should throw most of that away and rewrite both apps as a single cross-platform codebase.
I want to write about that conversation, because it taught me the part of engineering leadership that no one prepares you for. Managing up is mostly translation. People assume it is about softening bad news or picking the right moment. The real work is making a technical call legible to someone who cannot read the code. A founder does not need the architecture. A founder needs to know what a technical call costs them in time, money, and risk, and what their choices are. The day I learned to lead with that instead of the technical explanation was the day these conversations started going well.
“It’s complicated” is where translation stops
The instinct, when you are about to recommend something painful, is to explain the complexity. I felt it that day. I wanted to walk the founder through why maintaining two native codebases had become a tax on everything we did: the divergence between the Android and iOS implementations, the way a feature meant two builds, two review cycles, two sets of bugs. All of that was true. None of it was the point.
If I had led with the architecture, I would have handed him “it’s complicated” dressed up in detail. And “it’s complicated” is not an answer. It is a choice to stop translating. The complexity is real. The decision to make the founder carry it, in its raw technical form, is mine to avoid or commit. When a technical leader hands a founder the unsimplified version, it can look like transparency. It is actually an abdication of the one job the founder cannot do themselves.
Kim Scott’s Radical Candor frames the two ways this goes wrong, and they are mirror images. You can sugarcoat, telling the founder everything is fine when it is not. Or you can stonewall, burying the call under so much technical context that the founder nods along and understands nothing. Both feel like communication. Neither is. The version that works sits between them: say the hard thing plainly, in terms the listener can act on.
So I did not start with the codebase. I started with the one fact that made the whole problem legible to someone who had never written a line of code.
Make the founder feel the problem, not just hear it
Here is the thing I needed the founder to actually feel, not just hear: with two separate codebases, fixing a bug once was not enough. A fix on iOS did not carry over to Android. Every fix had to be done twice. Every feature had to be built twice. Every regression could show up on one platform and not the other, which meant we were also testing everything twice and still missing things.
That is not an architecture lecture. That is a sentence a non-technical founder can hold in their head and reason about. Two of everything, forever, for the life of the product. Once he could see that, the rewrite stopped sounding like engineers wanting to play with a new framework and started sounding like what it was: a way to stop paying for the same work twice.
This is the move I wish someone had taught me earlier. Good translation finds the one true thing that makes the consequence visible. Dumbing the problem down does the reverse, and it was never the goal. “The dependency graph between the two clients has diverged” is accurate and useless. “We fix every bug twice and still miss half of them on one platform” is also accurate, and it changes the conversation.
Lead with the outcome, then walk into the hard parts
When I finally made the case, I did it in reverse order from how the problem lived in my head. I led with the outcome, the thing the founder would want, and only then walked into the parts that would hurt.
The outcome I opened with: one codebase to maintain instead of two. Unified behavior across iOS and Android. Better code quality and something we could actually keep clean over time. And a meaningful annual salary savings. I put the payoff on the table first, in his terms, because I wanted him reasoning about the decision from the upside before he had to sit with the cost.
Then I told him the cost, honestly, because the upside is worthless if the person hears later that I buried the hard parts. There were three.
The first was the heaviest, and it was heavy on me, not just on him. The rewrite meant restructuring the mobile team. I had hired every one of those engineers. I had coached them for years. Recommending the call that ended their roles was the worst part of the job that week, and I was not going to pretend otherwise in the room. But I believed the responsibility I had to the company required the call anyway, and part of leading is carrying both of those truths at once.
The second: we would need to hire a small number of senior engineers with cross-platform experience to do the rewrite well.
The third: the rewrite would take several months, and during that window new feature work would slow or pause. For a product company, that is the sentence that makes a founder’s stomach drop, and I said it plainly rather than letting him discover it later.
The founder ranks the tradeoffs in his own order
I had walked in expecting the fight to be about the money. The meaningful annual salary savings, the new hires, whether the savings justified the disruption. That was my headline, so I assumed it would be his. It was not. He barely argued the economics. The two things he pushed hardest on were the team and the freeze.
The team was the heaviest, heavier even than the freeze. These were people he knew. He had watched me hire and coach them over the years, and ending their roles was not a cost on a spreadsheet to him. It was a decision about people he felt responsible for, and he was not going to wave it through because the math was good. I did not try to argue him out of that weight. It was the right thing to feel, and I felt it too.
The freeze was the other one, and it was specific in a way I had not anticipated. There were upcoming customer commitments and what he needed was confidence that the team could service those customers on time. To him the freeze was concrete: a promise he might have to make to specific people, and he could not make it until he believed the timeline.
That reframed the whole conversation for me. I had translated the problem into time, money, and risk, which was right. But I had ranked those categories in my order, not his. For me the headline was the meaningful annual salary savings and the long-term maintainability. For him the headlines were the people he would lose and the clients he might fail. Framing tradeoffs in the founder’s terms goes beyond translating out of technical language. It means figuring out which of those terms the founder actually weighs most, and meeting them there. The freeze we could problem-solve together: how to protect the customer work, where the real edges of the several months window were. The team was not a problem to solve. It was a cost to sit with, and the most I could do was be honest that it was a real one instead of pretending the spreadsheet made it painless.
The trust you build by bringing hard news early and with options
He approved it. Not easily, and mostly because of the human weight of changing a team he knew I had built. But he came around to it being the right business decision.
I have thought a lot since about why that conversation worked when earlier versions of me would have botched it. It was not that the news was good. The news included team changes and a feature freeze. It worked because I brought it as a decision with a path through it, not as a problem dropped on his desk. A founder does not get blindsided by bad news so much as by the silence that came before it, the weeks where their CTO knew something and sat on it. Bringing the hard call early, with the cost named and a path attached, is what lets a founder make a real choice instead of inheriting a fact.
This is the same lesson I keep relearning from a different angle. I wrote a while back about the first 90 days as a startup CTO, and how the work that actually matters is understanding the people and the business before you touch the architecture. The rewrite conversation was the far side of that. I could only frame the freeze in terms of customer commitments because I understood how the business made money. I could only carry the weight of the team decision honestly because I had hired and coached those people myself. The decision was good because the context came first. The conversation went well because I translated that context into the founder’s terms instead of mine.
What I try to do now
The practice I took from this is simple to state and hard to hold under pressure:
- Lead with the outcome in the founder’s terms, then walk into the cost with a path attached. Bury neither the upside nor the hard part.
- Find the one sentence that makes the technical consequence legible. “We fix every bug twice” did more than any diagram.
- Translate the problem into time, money, and risk, then learn which one the founder actually weighs most. Meet them there.
- Carry your own weight out loud. If the call costs you something too, say so. It makes you believable, not weak.
The engineers a founder trusts most are rarely the ones who deliver the cleanest news. They are the ones who deliver it early, in terms the founder can act on, with the hard parts named out loud and a way forward attached.
If you have had to make a call like this, the recommendation a founder did not want to hear, I would genuinely like to know how you delivered it and what you would do differently now. That conversation is where most of us learned this, and almost none of us learned it the easy way.