dp.cx blog

I was reading a post on Hacker News - a list of rules for being a new manager. Good rules. But some of them really are rules for new managers.

I've been watching Gotham Chess's "slow-run" series, and it gets at this. He starts from a complete beginner rating and climbs, showing viewers how to think about chess at each level. At the lower ratings, he teaches strict rules. Don't move the same piece twice in the opening. Develop your knights before your bishops. Castle early.

Then he gets to the higher ratings, and those same rules start getting ignored. Not because they were wrong, but because the player now understands why the rule existed in the first place, and can see when the position calls for something different. Grandmasters break these rules regularly. They'll move the same piece three times in the opening because the position demands it.

One of the rules from the HN post was "You need to be the adult in the room. At all times." That's solid advice for a new manager. But my current director doesn't follow it, and I'm better off for it.

He shares information with me that he probably isn't "supposed to" - deals that have been landed but aren't signed yet, so we can start planning customizations early. He'll think out loud with me about ways we could deliver something faster or better than another team. He'll be candid about how a project someone else is working on doesn't actually address the real problem. None of that is "being the adult in the room." It's trusting that the person across from you has enough context to handle the information responsibly.

If he followed that rule strictly, I'd find out about upcoming work at the same time as everyone else, and we'd lose weeks of lead time. His willingness to bend the rule makes us more effective.

I do the same thing on the technical side. The standard practice at my company is to discuss feature decisions with the product team before building. That's a good rule. It exists because engineers sometimes build things that don't match what the business actually needs, and product alignment catches that early.

But I've worked on our current product for six years. I know how the product team thinks about most requests, and the ideas I bring to them are usually met with "yeah, that sounds right." So I often just go with what I think the right approach is, and only bring significant dilemmas to them. If I routed every decision through product first, I'd slow things down without meaningfully changing the outcome.

The pattern in all of these - chess, management, technical process - is the same. Rules exist to give you a framework when you don't yet have the judgment to operate without one. They're not wrong. A new chess player should castle early. A new manager should be the adult in the room. A new engineer on a product should check with the product team before building.

But experience gives you something the rules can't: context. You start to see when the rule is protecting you from a real risk and when it's just adding friction. I'm not saying ignore the rules. And sometimes you make the call and it gets overridden. But at some point, you understand them well enough to see when the situation needs something different.