Managing up to a non-technical founder without losing your integrity
Business-outcome framing for every technical decision. Risk quantified in dollars, not story points. Never say "technical debt" without a customer impact number.
Our CEO is brilliant at product vision, fundraising, and customer relationships. He does not know what Kubernetes is. He should not need to. His job is to build a business. My job is to translate engineering reality into business language without lying, simplifying to the point of dishonesty, or giving up on technical quality to avoid a difficult conversation.
This translation is the hardest part of my role. Harder than architecture. Harder than hiring. Harder than incident response. Because the failure mode is invisible: you either oversimplify until you are making promises engineering cannot keep, or you over-explain until the founder stops listening and makes decisions without you.
Most of the leadership posts in this phase are me compressing scar tissue into defaults. It also builds on what I learned earlier in “The one-on-one framework I use after fifteen years of getting one-on-ones wrong.” I am less interested in performative management language now and more interested in the boring mechanisms that keep teams aligned when nobody is in a heroic mood.
The Translation Layer
After two years of getting this wrong in various ways, I have three rules that govern how I communicate technical decisions to our non-technical founder:
Rule 1: Every technical decision gets framed as a business outcome. I never walk into a meeting and say “we need to migrate to a new ORM.” I say “we can cut feature delivery time by 20% if we invest two sprints in modernizing our database layer.” The founder does not care about the ORM. He cares about feature delivery speed. The business outcome is the reason. The technical implementation is the mechanism.
Rule 2: Risk is quantified in dollars, not story points. When I need to argue for infrastructure investment, I do not say “this migration is 40 story points of tech debt reduction.” I say “if this system fails during peak load, we lose approximately $50,000 in transaction processing per hour of downtime, and the current architecture has a single point of failure that we have been lucky about for six months.” Dollars focus the conversation. Story points confuse it.
Rule 3: Never say “technical debt” without attaching a customer impact number. Technical debt is an abstraction that non-technical founders have learned to tune out. It sounds like engineers complaining. Instead, I say: “Our payment processing latency has degraded from 200ms to 800ms over the last quarter because of accumulated shortcuts in the transaction pipeline. Three enterprise customers have mentioned it. If it crosses 1 second, we risk triggering SLA penalties.” That is the same technical debt, framed as a business problem with customer evidence.
Where Most Engineering Leaders Get This Wrong
I watch engineering leaders make two predictable mistakes with non-technical founders:
- They treat the founder as someone who needs to be educated about technology. The founder does not need to understand microservices. They need to understand the tradeoff: this technical choice costs X and delivers Y. Education is not your job. Translation is.
- They treat pushback as a sign the founder does not respect engineering. Usually the pushback means the engineering leader has not made the business case. If you cannot explain why a technical investment matters in terms the business cares about, the investment probably does not matter as much as you think, or you have not done the work to connect the technical improvement to a business outcome.
The Integrity Line
The danger of becoming good at translation is that you start translating in bad faith. You learn to frame technical preferences as business necessities. You learn to make incremental infrastructure improvements sound urgent. You learn to use the language of business outcomes to justify engineering decisions that are really about technical elegance.
The integrity line is simple: never frame a technical preference as a business necessity unless you can point to specific customer impact or measurable risk. I want to migrate to a new monitoring stack because it is better. That is not a business necessity. Our current monitoring missed a payment processing outage for 20 minutes last month, and a better stack would have caught it in 30 seconds. That is a business necessity.
The moment you cross that line and start using business framing to sell technical preferences, you erode the trust that makes the translation work. The founder will eventually realize that not every “urgent” technical investment was actually urgent. And once that trust is gone, you lose your ability to advocate for the investments that genuinely matter.
What a Healthy Relationship Looks Like
This is the phase where individual scars finally turned into repeatable operating principles. I cared less about sounding clever and more about leaving behind a system that stayed sane without me in the room. That is how I build lifeos and bisen-apps too.
The founder tells me the business constraint. I tell him the engineering constraint. We find the overlap. Neither of us gets everything we want. Both of us get enough.
Our CEO and I disagree frequently. That is healthy. He pushes for faster delivery. I push for sustainable quality. The tension between those two forces produces better decisions than either of us would make alone. The key is that we both trust the other’s expertise. He trusts that when I say something is risky, it is actually risky. I trust that when he says a deal depends on a timeline, the timeline is real.
That trust was not automatic. It was built through dozens of conversations where I told the truth even when the truth was inconvenient, delivered on the commitments I made, and admitted when I was wrong about a technical prediction. Managing up is not about winning arguments. It is about building the credibility that lets you win the arguments that matter.