{
    Adam Ard
}

Green and Clean: How to Make Programming Assignments

Stephen R. Covey’s famous The 7 Habits of Highly Effective People is full of sound advice on a variety of topics. One section that is not often referenced, but well worth studying, is Covey’s superb explanation of how to use delegation. Here he skillfully lays out a simple framework for how any responsibility can be effectively organized and assigned.

Two Types of Delegation

First, Covey separates delegation into two types: gopher delegation and stewardship delegation. Covey explains:

Gopher delegations means “Go for this, go for that, do this, do that, and tell me when it’s done.”

We have all experienced this type of delegation. It is the default operating mode for the vast majority of us. It is likely the only way you have thought about giving assignments. Give a command; give a new command; and then give five more. Make sure they all get done. It seems reasonable, but this is actually the weaker form of delegation. Covey continues:

[Some managers] don’t know how to set up a full delegation so that another person is committed to achieve results. Because they are focused on methods, they become responsible for results.

At first, this may sound strange. After all, aren’t managers supposed to be responsible for results? Shouldn’t they give direction for achieving these results? Shouldn’t they prescribe the proper methods? The secret of good management is to turn this relationship on its head. If a manager can instead focus on delegating a vision for results, then workers can better engage in achieving them. They will find and deploy the right methods all by themselves. And most importantly, they will be committed and self-motivated. In other words, they will become responsible for their own results. This is called stewardship delegation:

This approach involves an entirely new paradigm of delegation. In effect, it changes the nature of the relationship: the steward becomes his own boss, governed by a conscience that contains the commitment to agreed upon desired results. But it also releases his creative energies toward doing whatever is necessary in harmony with correct principles to achieve those desired results.

Do you see the difference? It’s subtle but powerful. To further illustrate, Covey relates a personal experience delegating yard work to his son.

Green and Clean

Covey, after conducting a family meeting, manages to solicit volunteers for various tasks around the house. Ambitiously, his son volunteers to take over the yard work. Being young and inexperience in such a task, he is in need of some special direction. First, Covey takes him to their neighbor’s house where the yard is well-kept. This puts a positive picture in his son’s mind. Then, Covey settles on a simple phrase to describe what they experienced there: Green and Clean. This becomes the agreed upon result. If the yard can be green and free of debris, then they will consider his son’s efforts a success.

Because he knows his son has little idea of how to make this happen, Covey gives some helpful training but is careful to prefix the instructions with a crucial qualification:

“You’re free to do it any way you want, except paint it. But I’ll tell you how I’d do it if it were up to me.”

After offering to help with the work anytime he is available, Covey finishes by setting up a simple reporting structure:

“Twice a week the two of us will walk around the yard, and you can show me how it’s coming.”

In the end, it was an incredible success:

He took care of that yard. He kept it greener and cleaner then it had ever been under my stewardship. He even reprimanded his brothers and sisters if they left so much as a gum wrapper on the lawn

This story demonstrates Covey’s key areas of “mutual understanding” that must exist in proper stewardship delegation: Desired Results, Guidelines, Resources, Accountability and Consequences. Now, how do they apply to software engineering?

Results not Methods

Covey makes it very clear that delegation is about results not methods. This is an area where modern software methodologies can stand to improve. Many of the most popular systems (XP, Scrum, Kanban) focus more on task creation and assignment than on assigning larger areas of responsibility. It would be better to define architectural pieces and grant ownership of these pieces, “focusing on what, not how.” Individual owners can manage the tasks/methods themselves. In other words, spend collaborative time partitioning and defining roles, not tasks.

Imagine how differently Covey’s lawn delegation example might have gone had he used some of the prevailing agile methods. He would have first sat down at a computer to create task categories defining how the lawn should be maintained. Perhaps creating a mowing category, a watering category, and a trash cleanup category. Then he would have started creating individual tasks. In the mowing category, he would have created a task to buy a gas can. Then a task to go to the gas station and fill it up. Another to put oil in the mower. Upon further contemplation he may have decided that edging should be part of the mowing and then added a task to put gas in the edger and another to actually do the edging. Maybe he would have prioritized both edging tasks above the mowing to assure they were done first. Then he may have decided that the edging task was too big and should be split into edging the front lawn and edging the back lawn. This would have continued until he felt everything was specified.

Additionally, every two weeks, he would have sat down with his son and asked him what tasks he thought he could get done in the next two weeks. To make matters worse, between these planning sessions, he would have likely pulled his son into his office and made him estimate new tasks and asked him to help divide existing tasks even further.

Surely, this would have overwhelmed his son before any real work was accomplished. It is obvious that these are things that any responsible individual could figure out and manage on their own, yet we manage our software projects in precisely this way. Wouldn’t it be better to spend time creating clear, concise expectations of results, and let engineers do the leg work? It would not only reduce the burden on management, but invigorate and engage software developers in the stewardships they have been assigned.

Too Many Constraints

Sadly, many software companies today are highly constrained. Nearly all means and methods are set up from the beginning. Some common mandatory development practices are test driven development, continuous integration/deployment/delivery, pair programming, branching models, approved languages, approved operating systems, approved cloud providers, approved libraries, approved design patterns, mandatory code reviews, deployment checklists and coding standards. While there is nothing inherently wrong with these techniques, there is danger in mandating every perceived best practice. Too many constraints leaves little room for experimentation and innovation. The loss in autonomy comes at a cost in motivation and in productivity.

Keep it Simple

When Covey gave requirements for proper lawn care, he was concise and avoided specifying methods: the yard should be green and clean. Software assignments can be equally concise. Here are some examples.

1. Create a physical simulation system where blocks obey gravity and collide realistically with each other. Allow the blocks to be manipulated with a mouse.
2. Create a cloud based invoicing system that has all the features of the self-hosted one in current use. It should be functioning and available 99.9% of the time.
3. Create an application that renders objects defined by file types A, B, and C, creating realistic lighting, reflections, shadows, and refractions. It should run on Linux, Windows, and OSX.

Even though the above systems are likely to be very complex, the overall vision for the product can be described simply. Details can be worked out by the engineers involved. If needed, product professionals can provide reports or customer availability to help flush out the details.

If managers can focus on the correct principles of delegation, letting trust rather than control be their guide, I am confident the results will be astonishing. In the words of Covey:

Trust is the highest form of motivation. It brings out the very best in people.

One Final Thought

In examining how free and trusting organizations can operate, I have come to believe there is an even higher law of delegation to aspire to. Some organizations (Morning Star, Valve, Buurtzorg, and many others) seem to operate quite well without any managers at all. In these settings, people choose for themselves what to work on and how to evaluate themselves. Many of the same principles described by Covey seem to be in play, but in the form of making and keeping commitments among coworkers, instead of being handed down by a supervisor. In fact, one could look at Covey’s delegation methods as a way to release control to workers and distribute decision making power. Stay tuned for more on these self-managed organizations and how we can apply their practices to the field of Software Engineering.

Sources

• all quotations are from The 7 Habits of Highly Effective People by Stephen R. Covey