Picking the Archetypes for the Surgical Team

From Chapter 3: The Surgical Team

Excerpt
...each segment of a large job be tackled by a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.(p. 32)

From The Good Soldier Švejk¹

Excerpt
When Švejk subsequently described life in the lunatic asylum, he did so in exceptionally eulogistic terms: 'I really don't know why those loonies get so angry when they're kept there. You can crawl naked on the floor, howl like a jackal, rage and bite. If anyone did this anywhere on the promenade people would be astonished, but there it's the most common or garden thing to do. There's a freedom there which not even Socialists have ever dreamed of.―Opening sentences of Chapter 4,

At the beginning of chapter 3, Brooks argues convincingly that you can not do a big job with a small team. He explains that when the team is big, a raft of inefficiencies are introduced. In fact, unless care is taken, the inefficiencies will soon outweigh, and even nullify, the added productivity that motivated hiring additional staff in the first place.

The large team problem is relevant to the space biz because developing a space system is an inherently large job. (see Small is beautiful, but not applicable)

Brooks recommends a solution that was originally proposed by Harlan Mills². During the 70's and 80's, Dr. Mills is one most influential figures in computer science. Among other things, he was chairman the NSF Computer Science Research Panel, editor of IEEE Transactions in software Engineering, governor of the IEEE Computer Society, chairman of the Air Force Computer Science Panel and an IBM Fellow. In addition to these most impressive credentials, Dr. Mills was the originator of the Cleanroom software development process. By all accounts he was a true visionary.

Mills suggests that each part of a job be assigned to a team that's organized like a surgical team.³ This team would be organized according to the driving principle that there be "well differentiated and specialize roles."

Here's a rehearsal of the Mills/Brooks surgical team roles with a few observations of how they play out in NASA.

The Surgical Team

Chief Programmer

In keeping with the surgical team metaphor, Brooks calls the chief programmer the surgeon. The surgeon is responsible for the design. She or he also codes, tests and writes the documentation. On top of that, the chief is also responsible for code management and process tools.⁴

 

Brooks recommends that the chief have at least 10 years in the saddle and plenty of systems and application knowledge. He doesn't mention that this doyen will need to have the endurance of a sled dog because he or she will be facing the prospect of a 100 hour work week.

Copilot

Number 2 on the surgical team is the co-pilot (the surgical team has lifted off.) The co-pilot is the chief programmer's "alter ego." He or she shares the same responsibilities and skills as the chief. However the co-pilot's responsibility is restricted to that of a sidekick, "thinker discussant" who knows all the code and, maybe even, writes some. In some cases the co-pilot serves with plenipotentiary powers when the chief is otherwise occupied. Finally the co-pilot is a hedge against any rogue bus that might flatten the chief.

 

Brooks suggests the co-pilot need not be as experienced as the chief. He doesn't mention that the co-pilot will most likely be a cypher since a dissenting voice in NASA is likely to be traded to another team.

Administrator

The administrator handles the money" and other duties that make up 95% of the typical management responsibilities found in a large bureaucracy. But, Brooks is emphatic, the "surgeon is boss."

 

Brooks skips lightly over the what it means to handle the money. If he means writing proposals, writing budgets, allocating funds, hiring staff, and lobbying with funding sources, he's described a full time role that preempts any technical work. What's more he's allocated the source of all political power to the administrator, including the ability to hire a new surgeon. Perhaps this role should really be called manager.

Editor

Brooks recognizes that engineering team must document how the system is built and how it should be used. For unity of conception, many of these documents must be written by the chief, who is one horrendously busy person. Hence, the editor is needed to gather the recorded wisdoms of the chief and turn them into a thing of beauty and devotion.

Two secretaries

In Brooks' world of the 1970's, documents were not generated automatically. Someone had to type them. As a practical matter, he suggests that the editor and the administrator get secretaries.

 

Those were the days. On my last job at NASA, a secretary (now called an administrator) was shared by 20 engineers. They were our experts on the bureaucracy; they instructed us on how we needed to complete those endless administrative tasks. And while a trip to the secretary usually resulted in another work assignment, their instruction was necessary for survival in the maze of institutional rules.

Program clerk

Any programming effort produces a mountain of artifacts. Managing all the programming products is not for the faint-hearted. Consequently Brooks adds a Program clerk to his team. Nowadays, the job is almost entirely handled by software.⁵

Toothsmith

Brooks knows that just because you have tools, it doesn't mean that they will always work or that the team will know how to work with them. As a matter of necessity, Brooks recommends the team include a toolsmith.

 

The need for a toolsmith is as great as ever. Ironically, this position is seldom funded and usually lands as an extra duty for one of the better programmers. As a practical matter, this means one of you best team members is making a small contribution to the actual product.

Tester

Brooks know that it's not going to be right just because the programmer said so. He recommends that a team include a tester. Nowadays we'd call this an independent tester. The role is now considered de rigueur.

Language lawyer

From the earliest days, high-level programming languages have been as vague and suggestive as a sacred text. If a team is to work against a common understanding, official interpreters are necessary. Brooks calls them language lawyers.

 

The term is now derisive. Nobody likes being told what to think, but most everyone recognizes commonality is better than anarchy.

Over the years the Surgical Team has been the target of pejorative commentary. However, it is still considered a viable team organization—no doubt because no suggestion by Brooks is to be taken lightly. But, the surgical team is now archaic, except for one thing: the existence of a chief programmer. In my experience, most of the better functioning teams have their most talented engineer working as chief programmer. NASA is a notable exception. Believe it or not, I was prohibited from naming a chief programmer because such a role did not appear in the institutional rules. Perhaps this is typical of a large bureaucracy.

Brooks does not provide all the guidance that's needed to staff the Surgical Team. He has failed to account for personal proclivities and career ambitions. This is especially important for a NASA software manager because the Agency is not your typical workplace. For despite its recent lackluster record, NASA remains the object of adoration for talented space romantics who imagine their own greatness and are eager to make a mark in the annals of space history. In particular, a manager must be wary that, by the modest exercise of authority, he might convert a team member, one destined rise to levels of influence and power, into an adversary. What's a manager needs is a scale that helps predict if a team member is destined for bureaucratic glory.

I've never been one to pass up the chance to remedy this sort of omission. After weeks of undisciplined research, I found inspiration in Jaroslav Hasek's classic study of the Austrian military⁶ and pulled together a new qualitative measure: Team Archetypes Scaled for Potential Glory (TASPG). It appears here for the first time.

TASPG seeks to predict how individual Surgical Team members will fare. The scale establishes a set of archetypes and the predicts likely ascension of each. (see Figure 1 below.)

The Archetypes

Straight-shooter

The straight-shooter is tone deaf or indifferent to the impact that actions have of the keepers of the treasury. Blessed with a clear and constant vision of what could and should be, the straight shooter lacks the ability to see that in reality the organization cares little for the end result. While there is little risk that the straight shooter can hit a political target, there is a genuine risk of ricochet which adds a creative aspect to management since a fertile imagination is needed to keep the monthly reports sounding worry-free.

Techno-purist

The techno-purist lives in isolation, always purported to be close, but never-ever reaching, a holy grail. She rhapsodizes on the object of her quest in an incomprehensible language. And, despite never seeing the work used in actual practise, the techno-purist has an undaunted, irrepressible, laser-like determination. She is convinced that funding is a birthright and the hereditary responsibility of management. While her babbling⁷ will never be understood by those who pose a threat in upper management, this fundamental bond of dependency ensures neither the techno-purist or the manager will ever be lonely.

Pollyanna

The Pollyanna has suffered many setback, but has confidence that this time things are different. At core he is an irrepressible and persistent optimist who eagerly brightens the day with hope despite all evidence to the contrary. This enviable trust in good things stems from a perennial inability to derive the future from the past. And, "since those without hope are wretched,"⁸ he makes an important contribution. There is little risk from the Pollyanna because, to paraphrase Prospero, hope is not the stuff that funding is made on.

Sycophant

The Sycophant is master of knowing agreement. He knows how to agree in just the right measure. As a patron's fervent protector, he knows with whom he should disagree and when. In ancient Rome, a triumphant general rode in a four-horse chariot past cheering hordes while a slave who whispered, "momento mori".⁹ Today's bureaucratic proconsul is more likely bring the sycophant along to handle the messy business of quarreling with a naysayers. However, like a fickle house cat, he is warm and affectionate, so long as there's tasty fare. But if a neighbor has better table scraps, danger lurks for any creature that resembles a rat or a bug. Be wary of the Sycophant.

Politician

The politician shifts adroitly with the winds of influence and fashion. Look behind your local Grand Poohbah and you will find the politician in his wake. He travels light; unburdened by principle or unneeded loyalties. And he's agile, ready jump Poobahs as the occasion calls. So, be on the lookout, the politician may soon jump into the express lane and pass you on the road to glory.

Foot Dragger

The Foot Dragger is the embodiment of mature engineering judgment. Possessed of a domineering judgement, she will climbed to the rank of senior technical lead as a reward for holding back progress. She can often be recognized by the rendering of a considered technical judgment with the words, "I don't understand." So, if you are stymied and your budget and schedule or evaporating, there is likely a Foot Dragger in the lead.

Perfectionist

The Perfectionist knows the dreaded consequence of compromise. He stands alone as the standard bearer of quality and the last bastion against the tide of disaster. While the perfectionist is unable to bring a task to conclusion, he is able to maintain technical ascendancy by subduing dissenters with disapproval. But you need not worry about the Perfectionist, the tide of events will surge past him.

Awfulizer

In the Awfulizer's assessment, failure lies at every turn. The broken interface, the overlooked requirement, the architectural mismatch, the woeful ignorance of managers all foretell of impending budget or schedule debacles. Success is always a miracle. The Awfulizer poses no direct concern for, like the beeping horns of Manhattan, the warnings are just part of the background. However, pay attention, for a warning may arm a hostile team with budget stealing rhetoric.

Figure 1: Team Archetype scaled for potential greatness

Note that the archetypes are not orthogonal. For example, a single team member, like the chief programmer, may be a combination of the Foot Dragger and Politician archetypes. The NASA data confirms this particular prediction. More sophisticated results that combine weighted assessments are pending. For example, a team member, like the co-pilot, may best be characterized as part Sycophant, part Politician and part Pollyanna with relative weights assigned to each.

Regrettably the TASPG project is unfunded; the results may be slow to reach publication. In the meantime, perhaps this preliminary result will serve as a guide for the harried manager who's trying to assemble just the right team.

---

^1. Hasek, J., "Good Soldier Svejk". Penguin Modern Classics. 1983. p 31.
^2. Mills, H., "Chief programmer teams, principles, and procedures,"IBM Federal Systems Division Report FSC 71-5108, Gaithersburg, Md., 1971.
^3. I'm not certain if the term "surgical team" was from Mills papers or Brooks' description of Mills suggestion. If the former, there's a nice symmetry with Mills use of "Clean Room" for this development methodology. After all, you certainly want you surgical team to work in a clean room.
^4. Brooks was writing in the era before commercial products for configuration management and document generation were widely available. This is an extrapolation that may not reflect his intent.
^5. For projects of a couple of hundred people, there will often be a project librarian who manages an electronic libraries for documents. The programming artifacts are typically multi-tiered, but in the development phase a build manager usually is responsible for the source code repository.
^6. Hasek, J., "Good Soldier Svejk". Penguin Modern Classics. 1983.
^7. The word 'barbarian' was coined by the ancient greeks to describe people who spoke by making the babbling' sounds of a foreign language.
^8. Paraphrase from William Hazlitt, English critic (1778-1830)
^9. "...remember that you will die..." )