What Engineers Don't Know About Running a Company

The Skills That Got You Here Won't Get You There

Engineers love clear problems. You get a bug report, you find the bug, you fix it. There's a right answer, and you can prove it.

Running a company is almost nothing like that. And if you're an engineer who's thinking about starting or leading a company, that gap is probably bigger than you think.

Jay Kreps learned this firsthand. He built Apache Kafka as an engineer at LinkedIn—one of the most widely used data infrastructure tools in the world. Then he co-founded Confluent, the company built around it. Today, Confluent is publicly traded. But getting there meant rewiring how Kreps thought about almost everything.

His story isn't unique. It's a pattern that plays out across the startup world. And the engineers who make the leap successfully are the ones who understand what's actually changing—before it's too late.

Engineering Decisions Have Right Answers. Leadership Decisions Often Don't.

Here's what makes engineering feel safe: feedback loops are tight. You write code, it runs or it doesn't. You test a hypothesis, you get data. The truth is usually findable.

CEO decisions don't work that way. You're choosing between options where the outcome won't be clear for months or years. You're making calls based on incomplete information, shifting markets, and people you're still learning to read.

Kreps describes this as operating in a "fog of partial understanding." That phrase is worth sitting with. It's not that leaders are confused or incompetent. It's that the job itself requires making high-stakes calls without the luxury of certainty.

Engineers who become founders often struggle with this at first. They want more data before deciding. They want to be sure. But waiting for certainty in a startup usually means waiting too long.

The mindset shift isn't about becoming comfortable with being wrong. It's about becoming comfortable with moving forward anyway—and building systems that help you course-correct quickly when you are wrong.

You Can't Know Everything, So Stop Trying

Early-stage founders often try to stay close to every decision. That works when you have ten people. It breaks down fast when you have a hundred.

As Confluent grew, Kreps had to accept something that goes against most engineers' instincts: you will never fully understand every part of your business. And that's okay. What matters is knowing enough about the most important things—and knowing what you don't know about the rest.

His benchmark? Aim to understand about 80% of what each of your executives knows about their function. Not enough to do their job, but enough to know if they're doing it well.

That's a practical and honest target. It means you can ask sharp questions in a finance review without being a CFO. You can spot a weak marketing strategy without being a CMO. You can tell when an engineering team is building the wrong thing, even if you're not writing code anymore.

This is different from micromanaging. It's about staying calibrated. Leaders who fall below that 80% threshold often get misled—not out of bad intent, but because they can't tell the difference between a good plan and a plausible-sounding one.

Go-to-Market Is Where Most Technical Founders Stumble

Ask most engineers what they think about sales and marketing, and you'll get a shrug. It feels soft. Fuzzy. Hard to measure. Not their problem.

That attitude is expensive.

Kreps is direct about this: go-to-market is one of the areas where early companies go most wrong. And the mistake isn't usually laziness—it's copy-pasting.

Founders hire experienced sales or marketing leaders who bring a playbook from their last company. The playbook gets implemented. And then it doesn't quite work, because the customer journey for this product, in this market, with this buyer, is actually different from wherever that playbook came from.

Every company's go-to-market path is specific to them. Who makes the buying decision? How long does it take? What does the customer need to understand before they'll pay? What builds trust? These questions have different answers for every product.

The only way to figure out your specific answers is to do the selling yourself first—even if you're bad at it. Especially if you're bad at it. Because the friction you experience tells you something real about where the customer gets stuck.

Kreps put it simply: "The founders have to figure out how to sell the thing, maybe poorly." That's not self-deprecation. It's a strategy. You can't hand off something you don't understand yet.

What a Blog Post Can Do That Features Can't

Here's something most engineers don't want to hear: communication is a product.

Confluent's early growth wasn't driven primarily by the technical superiority of Kafka. It was driven, in large part, by a blog post. A well-written piece that explained why data streaming mattered and why Kafka was the right approach did more for adoption than months of engineering work.

That's not a knock on the engineering. Kafka is genuinely excellent technology. But excellent technology that nobody understands doesn't spread. Excellent technology with a clear, compelling explanation behind it does.

Kreps frames this as a test: if you can't explain why your project is exciting, it probably won't succeed as an open source effort. The same logic applies to any product. If your best users can't describe why they love it, you'll struggle to find more of them.

For engineers turned founders, this is often the hardest lesson. You've spent years being rewarded for building things. Now you have to spend real energy explaining them—not just to customers, but to employees, investors, and partners. That communication work isn't a distraction from building the company. It is building the company.

The Gap Between What You Can Do and What You Must Do

One of the most underrated strategic questions any startup leader can ask is this: of all the things we could do, what do we actually have to do?

Confluent faced this directly with its cloud product. Moving to the cloud was the right long-term call. But it was also expensive, risky, and unpopular—with investors, with parts of the team, and with some early customers who quit during the transition.

They pushed through anyway. Not because it was easy, but because Kreps believed it was necessary. The company could survive without a cloud product for a while. But it couldn't thrive long-term without one.

That distinction—between what's possible and what's required—is a forcing function for strategic clarity. Startups often have more options than they realize. The trap is treating all options as equal. Some things are nice to have. Some things are existential.

Leaders who can tell the difference tend to make better resource decisions. They don't spread their teams thin across a dozen initiatives. They find the two or three things the company genuinely must do and protect those above everything else.

This is harder than it sounds. There's always pressure to do more, to chase more opportunities, to say yes to more customers. The discipline to say "not yet" or "not us" is rare—and valuable.

The Transition Is a Process, Not a Moment

There's no day when an engineer becomes a CEO. It happens gradually, through a series of uncomfortable situations that force you to operate differently.

You stop being the person who knows the most about the technical details. You start being the person who sets the direction and builds the team that figures out the details. You trade certainty for speed. You trade depth for breadth.

None of this means engineering skills become useless. They don't. The ability to think rigorously, to spot bad logic, to understand systems—these transfer. But they're no longer the main thing. They become one tool in a much larger kit.

The engineers who make this transition well are the ones who stay curious about the parts of the business they don't understand yet. They treat marketing, finance, and sales the way they'd treat a new programming language: something to learn, not something to dismiss.

They also get comfortable with a different kind of success metric. In engineering, you ship and you know if it worked. In leadership, you make decisions and you wait. Sometimes a long time. That waiting—and staying confident through it—is its own skill.

Jay Kreps built one of the most important data infrastructure companies of the last decade. He did it by learning to lead the way he once learned to code: by accepting that he didn't know everything, finding the right people to fill the gaps, and being willing to push through when the path wasn't clear. That's not a formula. But it's as close to one as this kind of work gets.