Using the Dreyfus Model Effectively

By the late 1970s or so, the nursing profession was in dire straits. In a nutshell, these were their problems, which I’ve drawn from several case studies and narratives:^[18]

• Nurses themselves were often disregarded as a mere commodity; they just carried out the highly trained doctor’s orders and weren’t expected to have any input on patient care.

• Because of pay-scale inequities, expert nurses were leaving direct patient care in droves. There was more money to be made in management, teaching, or the lecture circuit.

• Nursing education began to falter; many thought that formal models of practice were the best way to teach. An overreliance on formal methods and tools eroded real experience in practice.

• Finally, they had lost sight of the real goal—patient outcomes. Despite whatever process and methodology you followed, despite who worked on this patient, what was the outcome? Did the patient live and thrive? Or not?

If you read that list carefully, you may have noticed that these problems sound eerily familiar. Allow me to slightly edit this bullet list to reflect software development:

• Coders themselves were often disregarded as a mere commodity; they just carried out the highly trained analysts’ orders and weren’t expected to have any input on the design and architecture of the project.

• Because of pay-scale inequities, expert programmers were leaving hands-on coding in droves. There was more money to be made in management, teaching, or the lecture circuit.

• Software engineering education began to falter; many thought that formal models of practice were the best way to teach. An overreliance on formal methods and tools eroded real experience in practice.

• Finally, they had lost sight of the real goal—project outcomes. Despite whatever process and methodology you followed, despite who worked on this project, what was the outcome? Did the project succeed and thrive? Or not?

Huh. It sounds a little more familiar that way; indeed, these are serious problems that our industry now faces.

Back in the early 1980s, nursing professionals began to apply the lessons of the Dreyfus model to their industry with remarkable results. Dr. Benner’s landmark book exposed and explained the Dreyfus model so that all involved parties had a better understanding of their own skills and roles and those of their co-workers. It laid out specific guidelines to try to improve the profession as a whole.

Over the course of the next twenty-five years or so, Benner and subsequent authors and researchers turned their profession around.

So in the best spirit of R&D (which stands for “Rip off and Duplicate”), we can borrow many lessons from their work and apply them to software development. Let’s take a closer look at how they did it and what we can do in our own profession.

Accepting Responsibility

Twenty-five years ago, nurses were expected to follow orders without question, even vehemently—and proudly—maintaining that they “never veer from doctor’s orders,” despite obvious changes in patients’ needs or conditions.

This attitude was enculturated in part by the doctors, who weren’t in a position to see the constant, low-level changes in patients’ conditions, and in part by the nurses themselves, who willingly abdicated responsibility for decision making in the course of practice to the authority of the doctors. It was professionally safer for them that way, and indeed there is some psychological basis for their position.

In one experiment,^[19] a researcher calls a hospital ward posing as a doctor and orders the nurse to give a particular medication to a given patient. The order was rigged to trigger several alarm bells:

• The prescription was given over the phone, not in writing.

• The particular medication was not on the ward’s usual approved list.

• According to labels on the medication itself, the prescribed dosage was double the maximum amount.

• The “doctor” on the phone was a stranger, not known to the nurse or staff.

But despite these clear warning signs, 95 percent of the nurses fell for it and went straight to the medicine cabinet, en route to the patient’s room to dose ’em up.

Fortunately, they were stopped by an accomplice who explained the experiment—and stopped them from carrying out the bogus order.^[20]

We see very much the same problems with programmers and their project managers or project architects. Feedback from coders to those who define architecture, requirements, and even business process has traditionally been either lacking entirely, brutally rejected, or simply lost in the noise of the project. Programmers often implement something they know is wrong, ignoring the obvious warning signs much as the nurses did in this example. Agile methods help promote feedback from all members of the team and utilize it effectively, but that’s only half the battle.

Individual nurses had to accept responsibility in order to make in-the-field decisions according to the unfolding dynamics of a particular situation; individual programmers must accept the same responsibility. The Nuremberg-style defense “I was only following orders” did not work in WWII, it did not work for the nursing profession, and it does not work in software development.

“I was just following orders!” doesn’t work.

But in order to accomplish this change in attitude, we do need to raise the bar. Advanced beginners aren’t capable of making these sorts of decision by themselves. We must take the advanced beginners we have and help them raise their skill levels to competent.

A major way to help achieve that is to have good exemplars in the environment; people are natural mimics (see ​Learn About the Inner Game​). We learn best by example. In fact, if you have children, you may have noticed that they rarely do as you say but will always copy what you do.

Trumpeter Clark Terry used to tell students the secret to learning music was to go through three phases:

• Imitate

• Assimilate

• Innovate

That is, first you imitate existing practice and then slowly assimilate the tacit knowledge and experience over time. Finally you’ll be in a position to go beyond imitation and innovate. This echoes the cycle of training in the martial arts known as Shu Ha Ri.

In the Shu phase, the student copies the techniques as taught—from a single instructor—without modifications. In the Ha stage, the student must reflect on the meaning and purpose and come to a deeper understanding. Ri means to go beyond or transcend; no longer a student, the practitioner now offers original thought.

So, among other things, we need to look at ways to keep as much existing expertise as we can in the project itself; none of this progression will help if practitioners don’t stay in the field.

Keeping Expertise in Practice

The nursing profession was losing expertise rapidly; because of the limits of pay scales and career development, nurses with high skill levels would reach a point in their careers where they were forced to move out of direct clinical practice and into areas of management or education or move out of the field entirely.

This largely remains the case in software development as well. Programmers (aka “coders”) are paid only so much; salespeople, consultants, upper management, and so on, might be compensated more than twice the amount of the best programmer on a team.

Companies need to take a much closer, much more informed look at the value that these star developers bring to an organization.

For instance, many project teams use a sports metaphor to describe positive aspects of teamwork, a common goal, and so on. But in reality, our idealized view of teamwork doesn’t match what really happens on professional sports teams.

Winners don’t carry losers.

Two men may both play the position of pitcher for a baseball team, yet one may earn $25 million a year, and the other may earn only $50,000. The question isn’t the position they play, or even their years of experience; the question is, what is the value they bring to the organization?

An article by Geoffrey Colvin^[21] expands on this idea by noting that real teams have stars: not everyone on the team is a star; some are rookies (novices and advanced beginners), and some are merely competent. Rookies move up the ladder, but winners don’t carry losers—losers get cut from the team. Finally, he notes that the top 2 percent isn’t considered world-class. The top 0.2 percent is.

And it’s not just high-pressure sports teams; even churches recognize difference in talent and try to use it effectively. Recently I was shown a national church’s newsletter that offered advice on how to grow and maintain a music program. Their advice sounds very familiar:

• A group is only as good as its weakest link. Put the best performers together to perform for the main service, and create “farm teams” for other services.

• Keep a steady group with the same performers every week. You want the group to jell; rotating players in and out is counterproductive.

• Timing is everything: the drummer (for a band) or accompanist (for choral groups) has to be solid. Better to use a prerecorded accompaniment than a flaky drummer or organist.

• Make your group a safe place for talented musicians, and watch what happens.

That’s exactly the same thing you want on a software team.^[22] This idea of providing the right environment for skilled developers is critical.

Given that the highest-skilled developers are orders of magnitude more productive than the least-skilled developers, the current common salary structures for developers is simply inadequate. Like the nursing profession years ago, we continually face the risk of losing a critical mass of expertise to management, competitors, or other fields.

This tendency is made worse by the recent increases in outsourcing and offshoring development to cheaper countries. It’s an unfortunate development in that it further cements the idea in people’s minds that coding is just a mechanical activity and can be sent away to the lowest bidder. It doesn’t quite work that way, of course.

As in the nursing profession, experts at coding must continue to code and find a meaningful and rewarding career there. Setting a pay scale and a career ladder that reflects a top coder’s value to the organization is the first step toward making this a reality.