The words matter

From Chapter 4: Aristocracy, Democracy, and System Design

Excerpt

By the architecture of a system, I mean the complete and detailed specification of the user interface... As Blaauw has said, "Where architecture tells what happens, implementation tells how it is made to happen." He gives as a simple example a clock, whose architecture consists of the face, the hands, and the winding knob. When a child has learned this architecture, he can tell time as easily from a wristwatch as from a church tower. The implementation, however, and its realization, describe what goes on inside the case—powering by any of many mechanisms and accuracy control by any of many. (Ch 4. p. 45)

From Slaughterhouse Five

Excerpt

Now, when I myself hear that somebody is dead, I simply shrug and say what the Tralfamadorians say about dead people, which is "so it goes."' (Kurt Vonnegut)

In this chapter, Brooks asserts that the conceptual integrity of a design is of signal importance and insists on the need for an architect who has been imbued with the authority necessary to preserve that integrity.

While I've had many quibbles with this visionary book, I find more object to in this particular passage than any that I've previously discussed.

---

Brooks begins this chapter with a description of the Rheims cathedral. He holds Rheims up as a premier example of conceptual integrity and he contrasts it with other cathedrals whose design suffers because "later builders were tempted to 'improve' upon the designs of the earlier ones." There's an implied warning to programmers in this rather strained analogy: don't get too inventive or you'll screw things up.

Sketch of flying buttress at Amiens Cathedral
(constructed 1220-1270 AD)

To my ear, this admonition is as archaic as the flying buttress. It probably made sense back when programmers coded with a mechanical pencils on graph paper. Back then algorithms were brained out, checked and rechecked and only then keypunched for a batch run. Using all that mental muscle was a lot more efficient that re-punching a card deck and queueing up for a batch run. With the arrival of workstations interactive compilers and linkers in the 70's, that changed. Programmers started working iteratively. Today developers think nothing of compiling and linking dozens or more of times a day. It's efficient. It's flexible. Change is easy.

That's a good thing. Despite Brooks admonition, programmers must be inventive. Why?

Unlike the good-old-days of the 13th century when tools and techniques changed on a geologic timescale, architects had no need to engineer change in their designs. Tomorrow would be like today. No worries about game changing innovations in the the next year or even the next century.

Arch C has a tas-de-charge

Nowadays tools and techniques change with the seasons. Hardware changes. Operating systems change. Programming languages change. It's enough to make your present-day software architect wish she'd lived in another era. So, asking programmers to build a system "without design improvements" would be like asking the Reim's architects to design a structure that begins construction with tas-de-charge columns and finishes with steel-beam cantilevers. But, don't forget to maintain "conceptual integrity!" And, by the way, steel-beam construction was a mid-19th-century concept, so the architects would had to have been clairvoyant, and as Yogi reminds us, "it's tough to make predictions, especially about the future." More to the point, each construction method urges a very different aesthetic. A very tall order. So tall that it suggests a serious challenge to Brooks' warning against 'improving' a design.

And, as if that wasn't enough to raise doubts about Brooks' advise, there's a bigger problem: requirements for a software systems will always be in state of flux. It's inevitable. Users will need more. Broader applications will be imagined. Infrastructures will change. If the architect did not plan for improvement, the system will become brittle and break with the smallest change. Maintenance costs will soar. And then infrastructure and culture will grow to address the inadequacies of the system. Organizations will sprout with budgets and personnel to address the shortcomings. With the budgets come the bureaucracies who will guard their very existence by setting up political ramparts to 'protect' the very system shortcomings that justify their existence. Is it any wonder that large software systems, like the NASA ground systems, live for decades and are nearly impossible to replace?

In this regard, the example of the Reimian architects fails badly. Imagine the fix they would have been in if they had to specify a building that could host both an Easter Mass and a Superbowl! Yet this is pretty much the lot of your contemporary software architect who must embrace those who would 'improve their designs,' because they hold the key to a system's long term viability. An architect who resists the need for improvement invites a high cost of ownership and widespread user resistance and antipathy.²

---

Perhaps the observation with the greatest potential for an adverse consequence is Brooks' invocation of the Blaauw's claim, "...where architecture tells what happens, implementation tells how it is made to happen." Here's what worries me.

In contemporary aerospace parlance, the system engineering effort defines what the system should do. The implementation effort defines how the system is to be built. The "what" is described in a requirements document. The "how" is described in a design document. So, if we take Brooks and Blaauw literally, the architect's role is to merely produce requirements and not design.

That's a bit disingenuous. Brooks also says architecture is a "specification of the user interface." Note the contradiction—a specification is a design artifact, a realization of, a specific way to meet a requirement. In other words, a specification is a how, not a what. So in that respect, Brooks is calling on the architect to designate a design and be part of the implementation effort. Note the contradiction.

This in no mere mincing of words. Remember "what is is?"³ Sometimes words matter. Underneath this seemingly pointless contradiction lies one of the biggest challenges facing the development of a new system. Countless hours have been expended in NASA debating what is a 'what' and what is a 'how'. (The answer will always be relative to context and never absolute.) Why the concern? The determination of whether a statement describes a 'what' or 'how' determines budget and decisional authority.

In the traditional view, the architect is a system engineer, pure and simple. Any attempt to designate a novel role is considered a power grab.

In the reformist view, where reformist implies that software design and development is a first order concern for space system development, the role of an architect is considered a new role. One with authority to reach across both the system engineering and design efforts. The reformist architect connects the 'how' to the 'what' and the 'what' to the 'how'. This is especially important for non-functional requirements like exensibility, maintainability and testability. Aside from a specification, those words will always be empty.

The lack of implementation authority is a severe shortcoming of the the traditional view. If an architect does not need to be responsible for the 'how', the role may be awarded to an individual who lacks the software development talent and experience required to meet the challenge of designing a software system for change. Sadly, that is the rule and not the exception.

"Liver of Piancenza" by LokilechTool
for divining from entrails 

And then there's the matter of defining architecture as "the complete and detailed specification of the user interface." If only that were a sufficient description of architecture, the world of software development would be a better place. Sadly, this kind of guidance promises more than it can deliver. In much the same way sheep entrails offer only the slightest hint to the soothsayer who must offer sage advice, an architecture described only as an interface relies more on the interpreter than the description.

What could go wrong? How might a "complete and detailed specification" of a user interface be inadequate?

Assume that Brooks' concept of a "user interface" is the same as we think of it today, i.e. a description of how you put data into and get data out of a functional box without looking inside. In contemporary parlance, that's a black box description.

Black boxes are wonderful because they hide the internals from a user. No need to bother with those niggling internal details. Just plug in a value and the right answer magically appears.

At least that's the theory. In practice, if something goes wrong, there is no visibility into what might be going wrong. I've seen programmers spend nerve-wracking, costly weeks debugging a problem only to find it buried in some 3rd-party library. And black boxes can also be a nightmare for testers. Consider the poor soul who trips an infrequent, non-repeatable error as the launch date nears. Was there a defect? Was it tester error? One thing's for sure, if an error can't be repeated, it can't be fixed.

As a practical matter, black box use if fine for application users, and a recipe for trouble during development. What kind of trouble? Here's a few examples that come to mind (especially for a realtime, safety-critical space applications):

• Consider an interface that specifies an integer input and an integer output. It says nothing about what happens behind the scenes. Internally that function might be optimized by using a type with fewer bits. The result could be a value that ends up rounding off to the wrong value. In many cases that's fine, but in other cases it may produce errors. Costly errors. A related issue was cause of the Ariane V disaster.
• Consider the complete interface specification for a library of functions. It includes a list of all inputs and outputs. But what happens if there's a loop where one function call another? How will these functions interact? Is an output affected by the order of execution? An interface specification limited to inputs and outputs will be silent about interactions.
• Consider a application that is reused as part of another larger system. Is the reused system being used in ways that are consistent with its design? Can new interfaces be safely added to the reused system? Will the new interfaces affect existing users? How will the deployment process affect existing users? An architecture that only defines the user interface will be silent on the many design consideration for reuse and modification.

What should an architecture do? It should provide design guidance in the form of constraints for programmers. The constraints that allow for change. The architecture should also describe the semantics of the system both in front of and behind the interface. The difficulty of the task cannot be overstated, but these are the necessary keys to conceptual integrity.

---

I suppose all this sounds like a mere tempest in a teapot. Perhaps this short anecdote will convince you otherwise.

On my last NASA assignment, I worked for a senior manager who was responsible for the ground systems used on nearly a dozen NASA missions. It was (and is) an out of date and extremely costly system to maintain.

A few years ago, headquarters allocated better than $10 million dollars for a multi-year upgrade. It was a rare opportunity to introduce a better ground system. Our team was especially smart and experienced. We analyzed the current requirement set and developed a simple, but powerful information architecture and structural architecture. We were optimistic. We prepared an architecture description document that described how we would build the system and presented it to the management team for review.

Remarkably we were stopped dead in our tracks. Our manager withdrew the funds for our design. His reason was simple: we had wasted our time defining more than the system interface. He was convinced that you can say all that's necessary with only an interface document. No example, no amount explaination could convince him otherwise. Despite his years of experience, he had no notion of what was required to successfully architect a new system. All progress on the new system immediately ground to a halt.

Today, those modernization funds have been exhausted without a single major improvement to the system. That's how it goes in NASA. That's how it is in a large bureaucracy.

"So it goes."

---

^1. Trevelyn, G.O., The American Revolution, Part III, Saratoga and Brandywine, Valley Forge, England and France at War. Longmans, Green, and Co. 1907.
^2. Brooks will acknowledge the problem of "changeability" in a later chapter (written for the 2nd edition), but he does not address the challenge it poses for conceptual integrity.
^3. Nod to Bill Clinton's statement to the grand jury in 1998. 
"It depends on what the meaning of the word 'is' is. If the--if he--if 'is' means is and never has been, that is not--that is one thing. If it means there is none, that was a completely true statement....."

I will return

The Sierra hiking season is over—for me at least.  I'm not one of  those hearty souls who think little of marching over the passes in all conditions. It's good to know your limitations.

I'm looking forward to wending my way through " Aristocracy, Democracy, and System Design,"the next chapter of the M-MM, but not before trying to tackle a couple other projects including a blog of this summer's Sierra hiking adventures. Till then...

Smart guys

From Chapter 3: The Surgical Team

Excerpt

The success of the scaling-up process depends upon the fact that the conceptual integrity of each piece has been radically improved — that the number of minds determining the design has been divided by seven. So it is possible to put 200 people on a problem and face the problem of coordinating only 20 minds, those of the surgeons...Let it suffice here to say that the entire system also must have conceptual integrity, and that requires a system architect to design it all, from the top down. (Ch 3. p. 36-7)

...Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds.(Ch 4. p. 44)

From The Republic¹

Excerpt
...neither cities nor States nor individuals will ever attain perfection until the small class of philosophers..are providentially compelled, whether they will or not, to take care of the State, and until a like necessity be laid on the State to obey them...
— Plato, around 380 BC, Book VI. (499b)²

Building a large-scale-software system, like a spacecraft, requires a lot of people. That's a problem. According to Brooks' Law the number of communication paths grows exponentially with the number of programmers. Hence the project manager's grand challenge: ensure that hundreds of engineers from different disciplines are all working with the same principal goals in mind. Good luck. Nothing is more dismaying than another-vague-management-mandate while the clocking is ticking and the schedule is evaporating. Fact is, most engineers don't grok the deep concerns outside of their domain and don't care so long as they have sufficient guidance and schedule to meet their deadlines.

Brooks has a plan to remedy the imminent communication ills prescribed by Brooks' Law. Put a smart guy in charge. (See Surgical Team.) Why? Because a smart guy becomes the sole decision maker and the system becomes the "product of one mind." Except for the odd case of a multiple personality, this simple reduction declaws the exponent.

There's a long standing precedent for putting a smart guy in charge. Ancient Greece has it's Archons³ and the Roman Republic had it's Dictators⁴. Consolidation of power has its place; it also had its risks.

Plato witnessed consolidation of power at its worst. He was a student of Socrates during the rule of the 30. The 30 were a group of aristocrats installed by the Spartan general Lysander after he defeated of the Athenian Navy (404 BC); a defeat the finally ended the Peloponnesian wars. The 30 were charged with dismantling the Athenian democracy and replacing it with an oligarchy. They were brutal, merciless and corrupt. They confiscated property, they exiled opponents and executed others. By some accounts the 30 executed 5% of the Athenian population.

The 30 lasted but a year. Democracy was restored to Athens (403 BC) , but there were scores to settle. No one was immune. Socrates, who had quarreled with nearly everyone, had his enemies⁵. Every Athenian citizen had the right to initiate criminal proceedings. A poet named Meletus brought the charge of 'corrupting youth' against Socrates. Socrates would be tried by a jury of 500 farmers and receive a death sentence.

Title page from oldest
manuscript of The Republic

These tragic events would stick with Plato. 20 years later, he would write The Republic, his sweeping treatise describing a just and virtuous utopian state ruled by a philosopher-king who "loved truth above all things."

Until philosophers are kings, or the kings and princes of this world have the spirit and power of philosophy, and political greatness and wisdom meet in one, and those commoner natures who pursue either to the exclusion of the other are compelled to stand aside, cities will never have rest from their evils, nor the human race, as I believe, and then only will this our State have a possibility of life and behold the light of day.Plato, The Republic, Book V. (473c)

Plato saw these philosopher kings as the product of new, improved society. They would be the offspring of carefully selected parents. They would be sent away from their families at an early age to be rigorously educated in all the arts and sciences. They would learn to resist temptation and stand firm. They would hold military office. They would serve out of duty, not glory, and distinguish themselves in all things. They would be fully dedicated to the well-being of the state and the public good. Above all, they would be guided by philosophy. If they should survive to 50, they would be ready to govern.

The idea of the philosopher king has animated the thinking of political theorists from Cicero to Nietzsche. For good reason. Concentrated authority tends to be efficient, effective, focused. Dispersed authority tends to vacillate and respond to crises without conviction.

That's the theory. In practice the utopian-minded governments tend to be the cruelest of the cruel. A line up of 20th century tyrants could man a parade of evils. Back in the days before political correctness, when I studied the Republic, philosopher kings were out of favor. Oh yea, there was the amazing Marcus Aurelius, but his accomplishments pale in comparison with idealist tyrrants like Franco, Lennin and Mao. I was coached in the admonitions of Karl Popper.

Consider this passage:

Karl Popper, Viennese Philosopher (1902-1994)

From The Open Society and Its Enemies

Excerpt
What a monument of human smallness is this idea of the philosopher king. What a contrast between it and the simplicity of humaneness of Socrates, who warned the statesmen against the danger of being dazzled by his own power, excellence, and wisdom, and who tried to teach him what matters most — that we are all frail human beings. What a decline from ...Plato's kingdom of the sage whose magical powers raise him high above ordinary men; although not quite high enough to forgo the use of lies, or to neglect the sorry trade of every shaman — the selling of spells, of breeding spells, in exchange for power over his fellow-men.—Karl Popper, Chapter 8, "The Philosopher King."

So why all this high minded Plato and Popper? They point to a signal failure in Brooks' remedy. He grossly underestimates the challenge of preparing and selecting the right sort of person in a position of leadership. Of the dozen of engineering leaders I met and worked for in NASA, I can count on one hand, with a couple fingers left over, those who had the wisdom and maturity for the positions they held. But that will always be the case when the politics of "selling spells" governs the allocation of authority.

So what then might we hope for in chiefs equipped with the magical powers of enlightened leadership and worthy of the surgeon's scrub? Here's my short list:

• They are versed in history and philosophy. They've internalized the biographies of famous leaders. (OK, this is a strong personal bias.)
• They trust their team.
• They operate from a deeply understood set of first principles. They do not have to look in the book to decide what they think.
• They have an intuition about the implication of a decision without requiring a detailed understanding.
• They are not constrained by convention
• They selectively muck around in the details. i.e. they are highly selective, preferring to a small set of key concepts to the scrutiny of minutiae.
• They inspire the best talent.
• They create an atmosphere of the possible, not the impossible.

It's a tall order, but people of this caliber exist. I've met them. They worked for DOD-related projects. But the DOD culture has an element of candor—lives depend on it. On the other hand NASA is an underfunded bureaucracy with a 'failure is not an option' ethos. Risk takers and free thinkers are dangerous to a fragile status quo and they don't thrive in NASA. Over the years I saw the most talented engineers pushed to the sidelines while the competent-but-unimaginative and politically-focused soared to positions of technical leadership. Plato's suggestion that "commoner natures...stand aside" is long lost to history.

I prefer to think of it this way... It's NASA! Isn't NASA the very emblem of of what's good and forward thinking of the US? Is it out of line to have aspirations for the US space agency that run contrary to those of a conventional bureaucracy?

While there is no utopias, there are times, accidents really, when talented and right minded people are elevated to positions of authority. Perhaps we should take a page from Plato and contemplate how would we train leaders of this stature. DoD trains soldiers to be leaders. NASA trains engineers to be bureaucrats. Universities train business management skills don't bother with technical leadership. Perhaps it time.

Before heading off to the next chapter (after a lengthy interlude traipsing in the Sierras), I've got a final knock on Brooks' assertion that the Surgical team enables scaling: it doesn't. It merely pushes the scaling problem up a level. For if you have 20 tasks, each lead by a Surgeon, these Surgeons will ultimately have to coordinate and the communication paths will, according to Brooks' Law, proliferate.

The way I see it, you won't succeed on a large project by attempting to reduce the number of communication paths. They come and go as the nature of the work demands. A system that limits communication is worse than no system at all. A different concept is needed.

For my nickel, the solution lies in an architectural approach (or style as Garlan⁶ puts it) that provides a common language that facilitates genuine communication and provides a set of constraints that gives each member of the team the direction they need without constant, direct consultation. It's a high order, but not without precedent.⁷

Perhaps the real challenge is to find a means of raising standards in an organization that prizes the status quo.

---

^1. Lectio Divina provides four links for the entire text of the Republic: Part 1, Part 2, Part 3, Part 4.
^2. For over a century, the Loeb Library has provided English translations of the original text for amateur readers. Plato, The Republic. Loeb Classical Library, Books 1-5 (#237) and Books 6-10 (#276). 1935.
^3. The word anarchy meaning 'no ruler' is derived from archon.
^4. In dire time, like the Hannibal lurking on the outskirts of Rome, the Senate appointed a Dictator to a 1 year term. In peace time, Rome was ruled by two Consuls in a power sharing arrangement that required consensus. This power sharing arrangement lead to the one of Rome's worst military disasters at the battle of Cannae where Hannibal crushed a vastly superior Roman army.
^5. Critias, a key leader of the 30, had once been a student of Socrates.
^6. See An Introduction to Software Architecture
^7. I worked once on a architecture and software framework that established a viable multi-discipline taxonomy and architecture. See Mission Data System.

The peculiar arrangement

From Chapter 3: The Surgical Team

Excerpt
In the surgical team, there are no differences of interest, and differences of judgment are settled by the surgeon unilaterally. These two differences—lack of division of the problem and the superior-subordinate relationship—make it possible for the surgical team to act uno animo. (p. 35)

It's summer; at least for all practical purposes. My attention has drifted north to the trails, cirques and passes of Sierra's. The thought of alpine air and mountain vistas reminds me of the exalting promise I once felt when developing software for space applications before realizing that the actual work takes place behind communication barriers in a bureaucratic miasma. So today, my thoughts have returned to Brooks' Law and the Mythical Man-month.

Brooks has a solution for the communication problem: the "Surgical Team." (See "A fly in the ointment" for a description of the communication problem described by Brooks' Law.)


If you've been reading along, you'll remember there are just two technical contributors on the 10-person "Surgical Team": The "Surgeon and the "Co-pilot." (If not, see "Picking the Archetypes for the Surgical Team".) The Surgeon is the chief. The Co-pilot is #2. The Surgeon's "alter ego." As #2, he or she shares the same responsibilities and skills as the Chief. However #2's responsibility is restricted to that of a sidekick, "thinker discussant" who knows all the code and, maybe even, writes some.

This strikes me as a peculiar arrangement. What exactly is #2 authorized to do on the Surgical Team? In Brooks' scheme: nothing.

For example, what if #2 meanders over to the Editor's cubicle and drops off a few changes to an ICD (i.e. Interface Control Document). Would it be prudent for the Editor to make alterations without being confident they meet the Chief's approval?   Hardly.

The co-pilot is only supposed to tap into team communications
From Mythical Man-Month p. 38 (1975 version)

And what if the Editor has questions? Should she rest easy that #2 has the authoritative answers? Only at her own hazard. And, possibly, the task's since without a clear line of technical authority there is a risk that each team member will develop to an independent concept of the interface. Same goes for the Administrator, Programming Clerk and the rest of crew.

So, in fact, if #2 talks to anyone, his presence probably increases the number of communication paths by N-squared and defeats the very intent of the Surgical Team. That was certainly my experience—I can't recall a time when a reliable decision came out of an audience with a #2.

So, what could reasonably expected from #2?

It's a relevant question for NASA.  There is a pandemic of #2's. Typically, they go by names like "Deputy," "Assistant," or "Associate." There are "Deputy Section Managers", "Deputy Architects" and "Assistant Division Managers." That's not to mention "Deputy Division Chiefs", "Assistant Project Managers", "Deputy Directors", and "Associate Administrators". There are even "Deputy Associates" and "Associate Deputies." The list goes on. Any Chief with a scintilla of actual authority is likely to get a #2.

Some chiefs have limited authority

However, the provisioning of authority does not always rest with the Chief. In fact the relationship between the Chief and his #2 may be the best indicator of the Chief's standing in the woof and warp of power and organizational influence.

For example, a chief may get stuck with a #2 whose real job is to guard the interests of a higher authority and ensure the chief steers the party line. Or, he may be stuck with a fallen  manager who can no longer land a portfolio and must be parked in a desk job. Or, worse, he may be assigned an-anointed-young-turk who carpools with an executive VP.

On the the other hand, the chief may be a "made man" and have actually authority. In this case he may select his own #2 and use him as he sees fit. Here's a few examples:

Some chiefs have clout
(Meyer Lansky did)

Attack dog
The best defense is a good offense, preferably one that preserves the appearance of impartiality. #2 can keep anyone with an opposing view safely on the defensive. For example, just as a Vice Presidential candidate is expected to relentlessly hector the opposition, a worthy #2 will undercut technical initiatives that threaten the Chief.
Henchman
Every job has its dirty deeds. For example, since the Agency does not tolerate failure (see "Failure is not an option"), remedial measures, like blame displacement, are frequently needed. #2 can do that dirty work so that the Chief's hands remain bloodless.
Parade sweeper
Leadership is not merely a matter of opining with one's feet on the desk — especially in a a paperwork hungry bureaucracy. Someone must take on the stultifying job of feeding the beast meaningless paper. Here's where #2 may make his most meaningful contribution.
Spy
Knowledge is power. A smart Chief must know what the troops are thinking. But, a Chief can have no real friends; unfiltered information seldom penetrates the management bubble. There's too much to be gained by flattery and it's too tempting to rail against leadership. #2 can help. She can be a friend, a trusted advocate for the working stiff, and a reliable reporter of the sentiments that lie beneath the surface.
Hand holder
Two heads is better than one; at least when it comes propping up the boss. With #2 at his side, a Chief makes a much more commanding presence. Best of all the Chief can be assured of close support should he be faced with dissent. There's no better hedge against those unsettling moments of insecurity.
Note to Chief: Effective hand-holding requires occasional dissention to preserve the appearance of honest and considered support. Don't be alarmed.

---

Gaius Gracchus, tribune of the people,
presiding over the Plebeian Council

A short digression
It was different once. Back in the Roman Republic¹ Tribunes² could only exercise their authority in person.

Tribunes were the elected representatives of the plebeians (i.e. non-aristocrats that held property). They were charged with protecting plebian interests. However, a Tribune was not a magistrate. A Tribune could not create laws, render judicial decisions or have any of the other powers of a government official.

Rather, Tribunes had the peculiar power of being able to veto any magisterial decision, including decisions made by Rome's highest elected official, the Consul. No one could stop a Tribune. But there was a rub. The Tribune had to physically present while the act was occurring. For example if Marius ordered the execution a political opponent, a Tribune could step in and stop the process. But the intervention had to be in person. No deputy. No Associate Administrator. No house guards. No #2 of any label. Only the Tribune's physical presence would do!

In recognition of the threat to life and limb, Tribunes were sacrosanct. Sacrosanctity meant that no one was allowed to touch a Tribune. Any interference was punishable by death. But there was a rub. The minute the tribune left, the act could be completed. The veto had no legally lasting effect.

Imagine how that might change things today.

---

And then there's the politically motivated selection of #2. This was the case when Napoleon appointed General Jean Victor Marie Moreau to command his Rhine Army.

General Jean Victor Moreau
(1763-1813)

Moreau was a popular member of the French aristocracy and a distinguished general of proven merit. In 1799, the Directory removed Moreau from his command—Moreau's loyalty had been unfairly questioned. It was a period of political instability and guillotine-fueled paranoia. But, the French armies were suffering defeats in the Austrian war; the Directory was desperate for talented field commanders. Moreau was re-appointed, but ill feelings and mutual distrust persisted.

Enter Napoleon. On his return from Egypt in 1799, Napoleon staged a succesful coup d'état that overthrew the Directory.³ Moreau played a key role. As a reward Napoleon named Moreau commander of the Army of the Rhine which lent credibility to Napoleon's fledging reign as First Consul.⁴

The good feelings would not last. Just months after his receiving his commission, Moreau refused to execute Napoleon's brilliant plan to invade Italy by crossing the Alps.⁵ Moreau told Napoleon that he should "follow the routes of earlier campaigns." Bad mistake. Napoleon would later write, "It was impossible to overcome the obstinacy of Moreau...He at first refused to command under me...he objected to my plans, pretending that passage of Schaffhausen was dangerous." For the moment, Napoleon did nothing in response to Moreau's insubordination. According to Napoleon, "I was not yet sufficiently firm in my position to come to an open rupture."

Three years later, Napoleon would find the opportunity to dispose of Moreau, but associating him with a Royalist plot. Moreau was forced to flee to the United States, but returned 10 years later to help the Swedes and Russians defeat Napoleon.⁶

Note to Chief: Don't forget that #2 might reappear as part of antithetical cause. Be nice or be merciless.

Louis Alexandre Berthier
(1753-1815)

The tale of Moreau contrasts sharply with Louis Alexandre Berthier. Berthier was also a highly respected member of the aristocracy who served with Napoleon from the initial campaigns in Italy till the 1813 defeat. Berthier was brilliant, a quick study of military necessity and a master of detail. He was by far, Napoleon's most able staff member. No one was surpassed him for understanding and executing the Emperor's commands.

After Napoleon was shipped off to Elba (1814), Berthier retired. When Napoleon returned for the 100 days, Berthier was refused to rejoin the Grande Armee. Two weeks before the Battle of Waterloo, Berthier died by fall from a window.^7,8

Note to #2: Your fate may depend on your chief. Enlist with care.

---

Being #2 is no picnic. For some it's a rite of passage. For others a last resort. But, whether a deputy is motivated by ambition or self preservation, he is not his own master. So observe your #2. Read the tea leaves. There's a lot that can learned about the real politics of your organization. If you aspire to be Chief, your future may depend on it.

Speaking of the future, I see an indigo sky and a few Sierra mountain passes up ahead.

---

^1. The Roman Republic is traditionally dates from ~500-27 BCE when August founded the Empire.
^2. Tribune is derived from tribe.
^3. Napoleon's coup was a close call that required a good bit of intrigue.
^4. In the beginning Napoleon shared power with two other men: Jean-Jacques-Régis de Cambacérès and Charles-François Lebrun. Within a year, there was a new constitution that consolidated all power in hands of the First Consul. In 1804, Napoleon would declare himself Emperor.
^5. The strategy would lead to the victory at Marengo, one of Napoleon's greatest achievments.
^6. He died at the Battle of Dresden.
^7. Many historians surmise that Berthier was assassinated. Throwing someone out a window is called Defenestration and is a time honored form of execution.
^8. Chandler's "The Campaigns of Napoleon was the source for these anecdotes. Chandler, D. "The Campaigns of Napoleon. The Mind and Method of History's Greatest Soldier." Scribner. 1966. p. 269, 308.