Yuri Gadow

Negative constraints may be a bureaucracy, but positive constraints foster continuous improvement. What’s the difference? A positive constraint exists only to force the question of how it can be improved. A budget can be a great example of this. By taking stock of what we have and planning how to spend it, we can better see efficiencies, opportunities, and waste. Other examples include product development processes and engineering practices. When people meet a positive constraint that limits them, they should feel compelled and empowered to improve it—not circumvent it. A negative constraint exists only to limit variation. The policies HR creates to limit litigation exposure are a classic example; improvement is out of the question. Other examples are IT security policies, database development procedures, and bedtime rules. None of these are inherently negative—they could easily be positive—but are usually enforced with no thought to improvement. A lack of constraints limits decision making to whim and guesswork. Without a budget, we cannot decide what to buy today because we can’t say whether we’ll run out of money tomorrow or next year. Without standardized development process, we can’t see wasteful action and remove it. People avoid constraints or attempt to perfect them before implementation because they think constraints must be rigid to be effective. But, a good constraint is only a starting point. We should build what we can today, knowing that we can, we must, improve it tomorrow.