I don’t really read business books, mostly because I vastly prefer spending time on science fiction. But every now and then an idea sticks, and one I keep coming back to lately is from Good to Great by Jim Collins, where he contrasts two leadership styles:
The Time-tellers are charismatic, visionary people who can point to the hour and rally everyone around the problem in front of them. The Clock-builders, on the other hand, are people who focus on building culture and designing systems that let the organization run itself.
Here’s a little scene that’s becoming familiar across tech companies: a designer opens a pull request. The diff is surprisingly clean and readable. It also touches twelve files and introduces a new dependency. The title says “Updated spacing,” and Claude’s thumbprints are all over it.
An engineer shows up in the comments with a specific kind of kindness that comes only from someone who’s been on-call before: Love this. Can we add tests? Can we scope it down? Also… why are we changing the build pipeline?
If you’ve been on either side of that, you know what’s up. Nobody is being unreasonable. Designers are trying to ship, engineers are trying to keep the system standing while the ground moves under it. The response is usually documents with careful definitions of who’s allowed to do what. That can work, but it also feels like a time-teller approach.
The opportunity isn’t to argue about who gets to touch what, but to tune the thing doing the touching. If AI is writing the code, then the “clock” is the code-writing system itself: the tools it reaches for, the tests it’s required to generate, the guardrails that keep a small tweak from quietly wandering into twelve files. It’s a clock worth building.