Mark Cuban's 12 Rules for Startups

I’ve been meaning to write this for a while.

Eight-plus years into my career now, and if I’m being honest, the first three were the wild ones. I cut my teeth in startups — bounced from an entertainment-tech company that was basically three people and a dream, into a BFSI (banking, financial services, insurance) startup that was trying to disrupt lending with half a compliance team and a lot of nerve. Two completely different worlds. One was building for attention. The other was building for trust. Both taught me more than any MBA case study could.

Today I sit on the other side of the table — deep in DevOps, MLOps, and increasingly AIOps, inside multinational companies with layers of process, security reviews that take longer than the actual sprint, and Slack channels named things like #platform-governance-sync. It’s a different life. Slower in some ways, infinitely more scalable in others.

Recently I came across an old graphic floating around LinkedIn — Mark Cuban’s 12 Rules for Startups. I remember reading these rules for the first time back when I was 23, fresh into my first startup job, nodding along like it was gospel. Reading them again now, with a decade of scar tissue and a very different vantage point, hit differently. Some of these rules I’d defend to the death. A few I’d quietly rewrite. So I figured I’d go rule by rule and tell you what actually held up in the real world — startup and enterprise both.

Rule 1: Don’t start a company unless it’s an obsession and something you love

This one is true, but it’s incomplete.

Obsession gets you through month one. It does not get you through month fourteen, when your co-founder is fighting with a vendor, your best engineer just got poached, and the investor update is due at midnight. What actually gets you through month fourteen is a slightly boring cousin of obsession: discipline.

I loved the entertainment startup I joined. Genuinely loved it — the product, the chaos, the feeling that we were building something people would actually enjoy using. That love bought me eighteen months of enthusiasm. It did not, however, teach me how to write a proper incident postmortem, or how to say no to a feature request from a founder who “just had an idea in the shower.” Obsession is the entry fee. Discipline is what keeps you solvent.

Rule 2: If you have an exit strategy, it’s not an obsession

I want to push back on this one a little, especially coming from BFSI.

In fintech and banking-adjacent startups, “no exit strategy” is almost naive. Regulators want to know your continuity plan. Investors want to know your path to liquidity. Customers — especially enterprise banking customers — want to know you won’t vanish in eighteen months holding their compliance data hostage. Having a clear-eyed view of where the company could end up isn’t the opposite of obsession. It’s what lets obsessive people sleep at night.

What I think Cuban actually means, and what I’d rewrite this as: don’t build with one eye already on the door. That’s fair. But pretending you have no exit thinking at all, especially in regulated industries, is a good way to get burned by your own investors later.

Rule 3: Hire people who you think will love working there

Absolutely true, and this is the one thing I miss most about startup life.

In my BFSI startup, we hired an ops person who had zero fintech background but loved solving messy operational puzzles. She ended up building our entire reconciliation process from scratch because she was into it, not because her job description said so. You don’t get that kind of ownership by matching keywords on a resume.

Now, in a large multinational, hiring is a different animal entirely. We hire for role fit, competency matrices, and “culture add” surveys that get filled out by five interviewers who barely coordinate with each other. It’s more rigorous. It’s also colder. The best engineers I work with today are the ones who, despite the process, still clearly want to be building the thing — not just collecting the paycheck. That instinct Cuban is pointing at doesn’t go away just because the company has 40,000 employees. It just gets harder to detect.

Rule 4: Sales cure all

This is the one rule I’d tattoo on the wall of every startup founder’s office.

I watched the entertainment startup nearly die twice — not because the product was bad, but because we obsessed over feature polish while revenue quietly starved. Sales cured every argument in that company. The moment revenue came in, morale improved, technical debt got forgiven, and investors stopped asking uncomfortable questions.

Here’s the twist from the enterprise side: in a big company, “sales” gets abstracted away from most engineers. You don’t feel the revenue pulse day to day. But I’ve started applying this rule internally too — in DevOps and MLOps, the equivalent of “sales” is adoption. If your internal platform, your CI/CD pipeline, your MLOps tooling isn’t being adopted by other teams, no amount of elegant architecture matters. Adoption cures all, the same way sales cures all. If nobody’s using what you built, you’re just maintaining an expensive hobby.

Rule 5: Know your core competencies and focus on being great at them

This rule aged incredibly well for me personally.

In my startup years, I tried to be a full-stack everything — infra, backend, a bit of frontend, some data work, whatever the day demanded. It was necessary at the time, but it also meant I was mediocre at five things instead of excellent at one. The pivot into DevOps and then MLOps happened because I finally admitted my core competency was systems thinking — reliability, automation, the plumbing that lets other people’s work actually reach users. Not building beautiful UIs. Not designing ML models from scratch.

The same logic applies at the org level. I’ve seen enterprise teams try to build their own Kubernetes distribution, their own feature store, their own everything — when three off-the-shelf tools would’ve done 90% of the job. Know what you’re actually good at. Buy or borrow the rest.

Rule 6: Lunch is a chance to get out of the office and talk

I laughed reading this one, not because it’s wrong, but because of how differently it plays out depending on company size.

At the startup, lunch was a strategy meeting, a therapy session, and a recruiting pitch all in one, usually over cheap biryani. At the multinational, lunch is 45 minutes on your calendar between two back-to-back Zoom calls, often eaten at your desk while triaging a P1 alert.

I’ve had to rebuild this habit intentionally as an adult in corporate life — deliberately blocking lunch with teammates instead of solo-eating while doom-scrolling incident tickets. Cuban’s right that some of the best cross-team alignment I’ve gotten in my current job happened over an actual meal, not a meeting invite. It’s a small rule, but it’s one of the most under-practiced ones in big companies.

Rule 7: No offices. There is nothing private in a startup

Open floor plans were basically the default in both my startups, mostly because we couldn’t afford anything else. And honestly, some good came from it — you overhear a customer support call going sideways and you jump in to help debug in real time. There’s a rawness and speed to it.

But I’ll be the guy who says the loud part quietly: open-office transparency is not the same thing as psychological safety. I’ve seen founders use “transparency” as an excuse to publicly call out mistakes in front of the whole floor. That’s not the spirit of the rule — it’s just bad management wearing a startup costume.

In enterprise DevOps/MLOps work now, I actually value having private spaces for certain conversations — security incidents, performance reviews, sensitive architecture debates before they’re ready for broader visibility. Total transparency is a value. So is knowing when a conversation isn’t ready for an audience yet.

Rule 8: As far as technology, go with what you know

This is the rule I’d defend hardest, especially now that I live in infrastructure and ML pipelines for a living.

Startups die from shiny-object syndrome constantly. I watched a team in my entertainment-startup days rewrite a perfectly functional backend in a trendy new framework purely because a competitor’s engineering blog made it look cool. Six weeks of “rewrite” turned into four months, and the actual product roadmap sat frozen the entire time.

The same trap exists at scale, maybe worse. Right now, everyone wants to bolt an LLM onto everything, spin up a new “AIOps” pipeline because it’s the buzzword of 2026, without asking whether the underlying observability data is even clean enough to make AI-driven decisions useful. Go with what you know, prove it works, then layer in the new thing. Novelty is not a strategy.

Rule 9: Keep the organization flat

True in spirit, harder in practice at scale — and this is where my perspective has shifted the most.

At six people, flat is just… reality. There’s no other option. At 60,000 people, “flat” becomes a slogan on a values page while there are nine layers of approval between an engineer and a production deploy. What I’ve learned is that flatness isn’t really about org charts — it’s about how fast information and decision-making authority move. You can have a hierarchy and still be effectively flat if a junior engineer can flag a production risk and get it acted on the same day, instead of it dying in a backlog for a quarter.

The rule I’d rewrite for enterprise folks: keep decision-making flat, even if the reporting structure isn’t.

Rule 10: Never buy swag

Guilty as charged — I ordered hoodies for a 12-person startup once. In hindsight, that money should’ve gone toward a better staging environment or, honestly, just payroll runway.

That said, I’ll offer a small, hard-earned amendment: swag isn’t the sin. Spending money on morale before you’ve proven the business works is the sin. Once revenue is healthy, a T-shirt for a team that just shipped a brutal migration is fine. The rule isn’t “never celebrate.” It’s “don’t confuse decoration for traction.”

Rule 11: Never hire a PR firm

In the entertainment startup, we actually did hire a small PR consultant for about four months. It taught me exactly why Cuban says this. Nobody can tell your story with the authenticity of the person who lived it building the thing at 2 a.m. The best press we ever got wasn’t from a pitch a PR firm sent out — it was from a founder posting an honest, slightly messy update on his own social feed.

In BFSI, this rule gets tested hardest, because regulated industries genuinely do need comms discipline. But even there, the best communication came from technical leaders explaining, in plain language, what we were actually building and why it mattered — not from a polished press release written by someone who’d never touched the product.

Rule 12: Make the job fun for employees

I’ll close on this one because it’s the rule that’s traveled with me the furthest — from scrappy startups all the way into corporate DevOps and MLOps work.

Fun doesn’t mean ping-pong tables. In my current world, “fun” looks like an engineer getting genuinely excited about automating away a painful manual deployment step, or a team celebrating when an ML model’s drift-detection pipeline catches a real issue before it hits customers. It’s the small dopamine hit of solving something hard and useful. That feeling is identical whether you’re in a five-person entertainment startup or a five-thousand-person MLOps org. If people aren’t getting some version of that joy, retention becomes a constant uphill battle — no compensation package fully compensates for a joyless job.

What I’d actually tell my 23-year-old self

Looking back at all twelve rules together, here’s the honest summary: Cuban’s rules were written for scrappy, resource-constrained startups, and they hold up remarkably well in that context. But having lived through entertainment, BFSI, and now large-scale enterprise infrastructure work, I’ve learned that the underlying principles matter more than the literal instructions.

Obsession without discipline burns out.
Sales (or adoption, internally) really does cure most problems.
Flat decision-making matters more than a flat org chart.
Go with what you know until you’ve earned the right to experiment.
And no matter how big the company gets, if the work stops being fun, something important has been lost.

If you’re early in your career, reading rules like these for the first time — take them seriously, but don’t take them as gospel. Test them against your own experience. The ones that survive contact with reality are the ones worth keeping.

Cheers,

Sim