I'm not sure I do either, but the first analogy that popped in my head when I read about Mr. Adams' approach was one of weight loss. I don't think it's a particularly good analogy, but it's the best I can come up with as an illustration of his "system-oriented" approach.

In a goal-oriented system, someone might choose to lose 30 pounds as their goal, then they'll work toward that goal through exercise or diet. Upon achieving it, they'll either continue (setting another goal) or fall off the wagon (going back to previous habits and gaining the weight right back). I've known enough people who have tried to diet repeatedly--and have succeeded in their weight loss--only to fail miserably and gain the weight back within a few weeks.

In a system-oriented approach (or maybe you could call it a habit-oriented system?), you focus on building up or improving your habits so that they meet whatever goals you set. Using the example of losing weight, you'd focus on diet and exercise by making fundamental lifestyle changes to your behavior and eating habits that simply happens to produce weight loss as a byproduct. People who exploit this system by changing their habits consistently keep the weight off because their day to day behavior has fundamentally changed. To put it another way, their habits would have to be dramatically altered in order to go back to putting on the weight they lost as a consequence of this approach.

Now, what I'm at a loss on is how this might apply to businesses, software development, or the likes other than to suggest it's a matter of developing good habits. To use his restaurant example: Instead of focusing on income goals, focus on making the best food in town and serving customers quickly. On second thought, maybe there isn't anything more to it other than habits? Maybe there's no "secret?" Develop good habits and plod along until something falls into your lap as a byproduct.

I think for software development, the system can be simple such as "I'm going to get a lot done every day." And then for each day, figure out what "a lot" means. When you finish a small goal, immediately reorient yourself to figure out the next goal.

I still think that's goal-oriented, or at the very least a hybrid approach. I wonder if the better term might be "objectives," e.g. each day, I have an objective to fix at least X bugs and make Y commits. But then that seems to increase the relative danger of encouraging yourself to do more make-work just to reach some slated goal at the end of the day.

That does give me some insight. To translate this to a habit-oriented system, you could improve or streamline your commit process, reorganize things to deal more readily with possible distractions (or deal with distractions in a single chunk of the day, such as the morning, to leave more time available for coding in the afternoon), and work on honing your habits. By doing so, getting certain goals done each day--and increasing the number of goals reached--would be a side effect of improved habits.

I guess I've been stumped because I'm looking at it from the wrong perspective (and I'm not especially prone to insight). Dumping goals entirely and focusing on the tools and techniques to get there seems more pertinent than establishing some baseline to work toward for a tangible reward. In some ways, it's like the football team example: If the team focuses on improving their fitness and practice habits (making progression itself a habit, such as the mile run by 5 seconds every few days), their competitiveness will improve as a consequence and become more predictable.

Another analogy:

relativity theory (goal-oriented - macro solutions) vs quantum theory (system/process-oriented - micro solutions)

I like that one.