Control of circumstances

From Chapter 1:

Excerpt
It seems that in all fields, however, the jobs where things get done never have formal authority commensurate with responsibility. (page 8)

In the 'Tar Pit' chapter, Brooks alerts software developers to a few "inherent woes." He points out that a developer does not control the circumstances of his or her work. In practice that means that the management decides what funding, schedule, tools and infrastructure are available to accomplish the goal. The individual contributor must work with what's provided. These management choices may leave much to be desired. Brooks describes the aggravation of working with poor tools, but it would be fair to add inadequate funding and busted infrastructure to the list. Bottom line, a developer will not have the authority to change these circumstances and must live with them.

In my experience, obtaining and maintaining authority is an overarching concern across the Agency. It affects decision making at all levels. In this respect, NASA is anything but unique; authority is a ubiquitous concern in any bureaucracy. However, the methods for exercising authority in NASA plays a significant role in shaping how the software is funded, scheduled, developed, tested and used.

The topic of authority is certain to come up many times in these postings, but I'll start by describing the use of role statements at JPL.

A role statement describes your job. A good role statement will define your responsibilities, the authority you have to meet those responsibilities and the obligation you have to show others that you are getting the job done. A well-structured job description will balance responsibility and authority; otherwise, an engineer may be held responsible for outcomes without the ability to meaningfully influence events. Many large organizations capture allocation of responsibility and authority in a Responsible, Accountable, Consulted, and Informed matrix or RACI. The RACI is sometimes called a linear responsibility chart. My own preference was for the shorter Responsibility, Authority, Accountability chart or RAA which was a 1-slide, bulleted description.

I seldom saw role statements used at JPL. In practice that best job description was often the one used in the hiring requisition. (How many of you actually ended up doing the job described in the want ad?) However, in the rare instances where a manager did prepare a RAA, approval was highly political and time consuming. Inevitably the sticking points were rooted in the authority bullets. Why? Because authority equates to delegation and delegation enables an engineer or middle manager to make decisions. Why the reluctance? In a bureaucracy, a-decision-gone-bad has consequences, and those consequences propagate up the management chain. Someone will end up holding the bag.

There are two standard remedies for the risks associated with making a decision: 1) decision by committee 2) process loading or the piggy-backing of mountains of paperwork on top of each engineering step. If accountability should come knocking, both remedies provide substantial benefit--there will be a room full of people and a warehouse full of paper ready for the defense. Without this protection, the risks to the upwardly-mobile manager or aspiring careerist are grave. And since prevention is better than remediation, delegation is done with the utmost caution and awarded to only the most conventional and predicable members of the community. This is how the select are chosen.

Committees and processes have become an end in themselves. Delivery of the product has become an ancillary goal. Of course, committees and processes drive up costs, however, if a software package is delivered without the imprimaturs of a committee and a stack of process documents, it will not trusted and never be used. More than likely, that code would simply grow stale in some nameless repository. This cultural convention plays a large role in the lack of progress in the Agency.

Obstacles to progress will be a recurring theme in later postings.