Korva is a scroll of the internet’s best ideas.
Solve problems faster than they multiply
Written as math, the rate of problem solving must always be greater than or equal to the rate of problem creation. Problems themselves are good, the way an interesting problem is good for a math professor, so a company should create them on purpose.
A problem created today doesn't show up right away. It comes ashore months later, sometimes six months or longer, and often looks different from what was expected. The founder has to predict the nature of the problem and whether the team has the management capacity to solve it.
Taking Uber to China was a created problem. Starting there meant starting over, since everything from the GPS system to the phones differs, and that was one of a hundred differences. When the equation tips out of balance, creating new problems stops until solving catches up, so the team stops drowning.
The same reasoning ties imagination to people. With few problem-solvers, only a small slice of what a founder imagines can become real, and with lots of management capacity, that limit unwinds.
Why do problems arrive months after their cause?
Systems with delays between an action and its result tend to overshoot and swing. Jay Forrester of MIT founded system dynamics in the 1950s to study exactly this behavior in companies. His team's Beer Game, played with ordering and shipping delays, shows how well-meaning players create large swings in inventory. A decision made today can look fine for months before its effect arrives.
How do startups outgrow their management?
Larry Greiner described a pattern of company growth in a 1972 Harvard Business Review article, "Evolution and Revolution as Organizations Grow." He proposed five phases of growth, and each ends in a crisis that the existing management style cannot handle. A founder-led company, for example, reaches a point where informal decisions no longer scale. The crisis forces a new structure before growth can continue.
Why does unsolved work pile up like debt?
The programmer Ward Cunningham coined the term technical debt in 1992 at a software conference. He compared shipping imperfect code to borrowing money: the shortcut speeds delivery now, but interest accrues every time someone must work around it. The longer the debt goes unpaid, the more each later change costs. The metaphor has since spread to describe unfinished work in many kinds of organizations.
More from David Senra
