In distributed systems, a write ahead log is used to ensure data can get stored fast. It makes the writes faster, but reading from the write ahead log is relatively inefficient.

Similarly, for engineering teams, acquiring processes, code, systems, decisions-made quickly is like using a write ahead log to prevent falling behind and keeping up with the demands.

In distributed systems, compaction optimizes storage and retrieval of data. If you used Windows (OS) in the 90's, then you'd be a big fan of "defragmentation" that makes your hard disk faster after a few hours of work.

Similarly, for engineering teams, going through a period of compaction periodically - identifies inefficiencies, and prunes them. This helps improve the scalability and long-term success. It's a hedge against always increasing entropy.

It's important to note that the algorithm for compaction may need to be adapted to fit the specific needs of the startup and the market it operates in. No one has a crystal ball, and you shouldn't trust a shaman to hand you this algorithm.

In my experience, making decisions quickly and going through a period of compaction is a strategy that's very hard to beat.

Time is the only true denominator, and optimising for velocity comes at the cost of compaction later. Given enough disorder induced by velocity, fast teams will often find come to a grinding halt. Much like how any storage layer without compaction has an upper limit grinds to a halt.