Embracing Risk, Reward, Success, and Failure

One of the biggest things you’re looking for in these growth goals is the learning that comes from achieving a growth goal. Note that when I use the term “learning,” I’m not just suggesting “problem solving” (as in, identifying and correcting errors in the external environment), I’m suggesting that people need to reflect critically on their own behavior, identify the ways that they’re inadvertently contributing to the problem, and then change that behavior. Part of the larger goal (the meta-goal, if you will) is for your directs to learn how the way they go about defining and solving problems can be a source of problems in its own right.

Consider the humble thermostat: When set to 68 degrees, it checks the current ambient temperature, and turns on the heat or AC to adjust the temperature accordingly. This is a simple, “single-looped” feedback loop. If the thermostat could be taught to ask, “Why am I set at 68 degrees?”, and then explore whether a different temperature would actually accomplish the deeper goals of the household—keeping warm in winter and cool in summer, relative to the outside temperatures—the thermostat would now have a second feedback loop in place, which would influence the first feedback loop, and more importantly, require less human interaction to find the optimal spot between comfort and energy conservation.

Most developers are very good at single-looped feedback—tell me what the bug is, or what the missing feature is, and I’ll go build it or fix it. Many developers, however, are not great at that second level of feedback—we often defer the question of “why” and that associated abstract thinking to the product owner or business analyst. “Just tell me what you want and I’ll build it,” they’ll demand. “I can’t tell you what you want.”

And yet, when the developer becomes a manager, much of the role is to do exactly that—help the client (the members of the team) figure out exactly what it is ...