Rules Are Where Drive Goes to Die

I had a fight with my cofounder today. Not the productive kind where you emerge with clarity — the kind where two people who respect each other walk away frustrated, each convinced the other is missing something obvious.

We’d spent an hour and a half on a call — me, Sahil, and one of our best engineers — going through the credit appraisal process in detail. The engineer was taking notes and was supposed to log the tasks on Plane (our ticket tracker) afterward. Then Sahil had a scheduling conflict, so we cut the call short. I was already irritated. I’d wanted to finish in one sitting.

The engineer didn’t post the tasks that day. He’d just come off a large migration — one he’d worked through the weekend on — and the migration support was still ongoing. The next day, Sahil brought it up. He should have posted it yesterday. I said sure, but he was probably dealing with migration fallout. Sahil gave me this look — not anger, disappointment — like I was making excuses for someone. I said he had the notes, he’d get to it. Sahil said the expectation should always be that they post on the same day.

I lost it. He lost it. We went back and forth. Then we stopped, because there was nothing left to say that wouldn’t make it worse.

Here’s the thing: Sahil wasn’t wrong.

If the engineer had lost his notes, or half-remembered what we discussed, and posted a garbled version two days later — that’s a real problem. The whole point of logging tasks immediately is that context decays fast. What feels crisp and obvious in the moment becomes fuzzy by the next morning. Sahil wanted to read the tasks and validate that they captured what we’d actually agreed on. That’s not unreasonable. That’s good process.

So why did I push back so hard?

Because I’ve been on the other side of this. I’ve been the person who enforces the rule, watches it land badly, and then spends months dealing with the fallout.

Last Diwali, most of our tech team went WFH. More than eighty percent. Our engineers are mostly migrants — they work in Gurgaon, but their families live in towns and cities hundreds of kilometers away. Diwali is when they go home. So they did, and they worked from there.

I was furious. It felt like the office had been abandoned. I got HR to draft a formal leave and WFH policy — caps on how many people could be remote at once, approval workflows, the whole thing.

It was not well-received. That’s putting it gently. There was real pushback. Some people quit. Not because the policy was draconian in the abstract — plenty of companies have similar rules — but because of what it signaled. It said: I don’t trust you to manage your own time. It said: the appearance of being at your desk matters more than the work you produce. That’s not what I meant by it, but that’s what they heard. And I think they heard it correctly.

I learned something from that episode that I’m still digesting. In creative work — and building software is creative work — the energy that produces great output is not the kind you can schedule or mandate. It comes in bursts. People who build good systems do it by pushing themselves, often at odd hours, often in intense sprints followed by stretches of recovery. That rhythm doesn’t look like compliance. It looks, from the outside, like inconsistency.

Rules are designed to eliminate inconsistency. That’s the whole point of a rule. And in a factory, that’s exactly right — you want every widget to come out the same. But in a startup, you’re not producing widgets. You’re trying to get a small group of people to do the best work of their lives. And the best work doesn’t come from people who are following rules. It comes from people who are so engaged with the problem that they forget about the rules.

This is the tension I keep running into as CTO. My job is to defend my team. Not from hard work — they chose hard work when they joined a startup. I need to defend them from the kind of overhead that makes hard work feel pointless. Every rule you add is a small tax on autonomy. One rule is fine. Ten rules and people stop thinking about what matters and start thinking about what’s required. The gap between those two things is where drive goes to die.

But — and this is the part I didn’t articulate well in the fight — that doesn’t mean expectations don’t exist. It means they should work like guidelines, not laws. The engineer should have posted the tasks that day. That’s the expectation, and it’s a good one. But when someone has just worked a weekend on a migration and is still handling fallout, the right response is: I trust you to get to it. Not: why didn’t you follow the process?

The difference sounds small. It isn’t. One says: I see the work you’re doing, and I trust your judgment about priorities. The other says: the process is more important than your judgment. Over time, people who hear the second message stop exercising judgment at all. They just follow the process. And then you wonder why nobody takes initiative anymore.

Sahil’s instinct is correct: you need accountability. Without it, things slip through cracks, context gets lost, and decisions dissolve into half-memories. The engineer should have posted. If he’d forgotten entirely, that would have been a real failure.

My instinct is also correct: you need slack in the system. People who just killed themselves on a migration need to know that you noticed, and that you’re not going to come after them for a late ticket post on the same day they shipped.

The mistake I keep making — the one I made during Diwali, the one Sahil thinks I’m making now — is that I swing too far. I either enforce rigidly and watch morale crater, or I defend too loosely and let things slip. The right answer is probably boring: hold the expectation, but hold it with context. “Yes, you should post same-day. Also, I know you were buried in migration work, so thank you.”

That’s not a rule. It’s not the absence of a rule either. It’s judgment.

I think running a startup well — at least the people side of it — is mostly about judgment. Rules are a substitute for judgment, useful when you have too many people for any one person to know what’s going on. We’re not there yet. And I’d like to stay in the judgment phase as long as possible, because I think that’s where the best work happens.

I don’t know if I’m right about this. I might be the cofounder who’s too soft, who lets things slide until something breaks badly enough to prove Sahil’s point. That’s a real possibility and I try to hold it honestly.

But I keep coming back to those people who quit after Diwali. They didn’t quit because the work was too hard. They quit because the rules made the hard work feel like it didn’t count.

I don’t want to build that kind of company.