My approach: nurturing, with sharp corrective feedback when necessary.

Technological and information processes are difficult to measure even in the best cases. As systems theorist Dennis Meadows notes, there are simple problems, in which solutions track monotonically better, and complex problems, in which the long-run preferred solution presents costs and negative growth in initial phases. We're willing to accept this for short-term projects with well-established trajectories: a new business launch, building or infrastructure construction. It's much more difficult to accept and sell such approaches where the problem space is novel, where there's little experience with it, where progress isn't particularly visible, and/or the timelines are long (Meadows' principle work has been in the area of resource and population limits, which expresses all of these characteristics).

My experience and observations are that:

- People and organizations both prefer stability and predictability. If I don't know from day to day that I'll have a job, that my door badge will work (among the reasons I find them psychically deadening, and I've heard similar views voiced unprompted by others -- "well, I've still got a job" as they entered the building), my productivity will suffer. Much of the shift of pressure in the past 40 years or so has been of risk from organizations onto individuals.

- Consistency in feedback helps. This is difficult with complex systems, and devising good metrics can be difficult. I've often provided harsh feedback for systems I use (of late, Google+, though it's annoying me less, today, GNOME in another H/N story). Though I'm doing so as someone outside the control structure of the organizations providing the service. It's one thing to take criticism from someone who can choose to stay or walk away, it's another when it comes from someone who can tell you to walk. One of the interesting aspects of Free Software development is that it very often divorces the technical criticism and workflow from employment. A kernel developer can hop from job to job, and still do the same work. They can be harshly criticized by Linus or others on LKML, but those people have no ability to fire the developer, only to make a decision to accept or not accept submissions.

- Organizational sanity helps. However (see my first point) organizations which themselves operate in high-risk environments are often poorly structured to be able to shield their employees from those pressures (and if you find yourself with management who succeeds in doing this, you've struck gold). Returning to Meadows' work, one challenge we're all facing are decreasing margins -- there was much more room for error in the 1950s - 1970s, it's vastly thinner now.

- I've had some experience working with children, and one of my observations was that giving them a fair amount of latitude, but very clear boundaries, seemed to maximize engagement, learning, independence, and discipline. The first time I really had to crack the whip I was amazed at how little chastisement went a long way (it was an effort not to slip while delivering my lecture). And it served to establish boundaries.

"Fair but firm" is what guides me. It doesn't work always, but it's a pretty good start.