-----
title: "Book Review: Reflections on Management"
content-type: article
subtitle: "The key to becoming a true leader"
timestamp: 1296942685
tags: "review|books|software"
pdf: true
-----

<section class="section">
	<p>When I was offered to review this book, I was a bit skeptical: a book on <em>management</em>? I normally read and
		review books on programming and software development methodologies. However, I work as a Documentation Technical
		Leader, and while I don't technically <em>manage</em> a whole team yet (damn economic crisis!), someday I
		may end up doing just that, so I gave <a
			href="http://www.informit.com/store/product.aspx?isbn=032171153X">Reflections on Management</a> a try.</p>
	<p><em>It's short, after all, I'll probably read it in a couple of weeks and move on</em> &mdash; I
		thought. Well, beware of short books: I thought exactly the same thing when I picked up <a
			href="http://en.wikipedia.org/wiki/The_Elements_of_Style">The Elements of Style</a>, and it still follows me
		around everywhere, so that I can re-read bits of it whenever I need to.</p>
	<p>This short but dense masterpiece by Watts S. Humphrey and William R. Thomas is one those books you always end up
		carrying around in your pocket (or stored in your favorite ebook reader). It's a short but very dense
		collection of tips and tricks to succeed as a leader and a manager &mdash; of <em>anything</em>: <q>Your
			Software Projects, Your Teams, Your Boss, and Yourself</q>, as the book subtitle says. It doesn't
		&#8220;just&#8221; help forging great managers and leaders, it also explains, with practical examples and
		no-nonsense explanations, how to deal with those annoying people in suits who constantly keep asking you for
		impossible things&#8230;</p>



	<section class="section">
		<header>
			<h1 id="h_1" class="toc">About Watts S. Humphrey</h1>
		</header>
		<p>Generally, I don't bother writing anything about the authors in my reviews: you can easily find this
			kind of information online if you want to. I'll make an exception in this case, you'll
			understand why as you read along.</p>
		<p><a href="http://www.sei.cmu.edu/watts/index.cfm?WT.ac=watts">Watts S. Humphrey</a> was a true legend in
			Software Engineering, he's often referred to as <em>The Father of Software Quality</em>. He worked at
			<span class="caps">IBM</span> for 27 years and eventually became Vice President of Technical Development. In
			the 80s, he arrived at the <a href="http://www.sei.cmu.edu/">Software Engineering Institute (<span
					class="caps">SEI</span>)</a> where he developed some key development processes of our time: the
			Software Capability Maturity Model (<span class="caps">CMM</span>), the Personal Software Process (<span
				class="caps">PSP</span>), and the Team Software Process (<span class="caps">TSP</span>). He received
			many awards, culminating with the <em>National Medal of Technology</em> in 2005.
		</p>
		<p>He wrote several books focusing mainly on software development and managing software projects through his
			<span class="caps">PSP</span> and <span class="caps">TSP</span> methodologies. <em>Reflections on Management
				&mdash; How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself</em> was the last book
			published while he was alive. <a href="http://www.informit.com/title/0321624505">Leadership, Teamwork, and
				Trust: Building a Competitive Software Capability</a>, co-authored with James W. Over, was published
			posthumously.
		</p>
		<p>Watts S. Humphrey <a href="http://www.sei.cmu.edu/newsitems/Humphrey_obituary.cfm">died</a> on October 28,
			2010.</p>

	</section>
	<section class="section">
		<header>
			<h1 id="h_2" class="toc">Structure and Organization</h1>
		</header>
		<p>In many ways, <em>Reflections on Management</em> can be seen as the <em>summa</em> of Humphrey's work
			on <span class="caps">PSP</span>, <span class="caps">TSP</span> and management of software projects,
			condensed in a very readable 288-page-book, co-written with <a
				href="http://www.sei.cmu.edu/about/people/wrt.cfm">William R. Thomas</a>, Senior Technical Writer and
			manager of SEI's Technical Publications Team.</p>
		<p><img src="/images/pictures/books/reflmgmt.jpg" style="float:right" /></p>
		<p>I noticed the tech writer's touch simply by flicking through the pages of the book when I first got it:
			its structure is impeccable.</p>
		<p>Organized into four parts, totalling 8 chapters, an Epilogue and an Appendix, this book is a prime example of
			order and readability: pick any section title (just the title) of any section in any chapter, and you get a
			clear idea of their content and purpose, and a key principle of management. Examples? Sure:</p>
		<ul>
			<li>Chapter 8: Learning to Lead
				<ul>
					<li>8.1 How You Behave Affects Your Team</li>
					<li>8.2 Leaders Set an Example for Their Teams</li>
					<li>8.3 Learn to Avoid the Symptoms of Poor Leadership</li>
					<li>[&#8230;]</li>
				</ul>
			</li>
		</ul>
		<p>If you print the Table of Contents alone you get a priceless cheat sheet on management and leadership. If you
			want slightly more detail, each chapter contains a summary table of all its sections, with a two-line
			summary of its contents. There are no subsections, only first-level sections, which make the book much
			easier to understand and &#8220;digest&#8221;.</p>
		<p>You can read it all at once, then you should keep it readily available for consultation. It will take you
			only a few seconds to look through the contents and pick the most relevant section in a time of need.</p>

	</section>
	<section class="section">
		<header>
			<h1 id="h_3" class="toc">Writing Style</h1>
		</header>
		<p>The book is very clear and simple to read, always. Each section is self-contained, and always aims to make a
			point, usually expressed right in its title. If I were to find a common pattern in most of the chapters of
			this book, it would be the following:</p>
		<ol>
			<li>Identification of the problem &ndash; a particular situation or aspect is described in a way that
				problems are self-esplanatory.</li>
			<li>Labeling and classification &ndash; the situation is analized and often a set of causes are presented to
				the reader, often labeled or classified.</li>
			<li>List of possible solutions &ndash; a list possible solutions is presented to the reader, often as a
				definition list.</li>
			<li>Solution details &ndash; more details are provided to prove the effectiveness of the solution, often
				including personal anecdotes.</li>
		</ol>
		<p>By doing so, the author makes sure that everything he writes about can be easily understood and accepted,
			because proven by personal experience.</p>

	</section>
	<section class="section">
		<header>
			<h1 id="h_4" class="toc">Contents</h1>
		</header>
		<section class="section">
			<header>
				<h1 id="h_5" class="toc">Part I: Managing Your Projects</h1>
			</header>
			<p>The book starts with a general introduction on Software Quality. If you are new to the subject (and you
				<em>shouldn't</em> be), this is probably one of the best and to-the-point overviews you'll
				ever find, written by the man who almost came up with the concept.
			</p>
			<p>The second chapter is about planning. Actually, the whole book is about planning at different levels, so
				no, you should not dismiss this part. <em>Good</em> plans are important, and they are your best weapon
				against management, if you excuse the expression.</p>
			<p>Someone may object that if you're working in an <em>agile</em> team, you shouldn't spend a
				lot of energy in long-term planning, but rather focus on dealing with frequent requirement changes and
				deliver often and regularly. While this can be true, planning is still important: you won't
				produce any rigorous schedule or design documents, but you still have to be able to provide accurate
				estimates and very often!</p>

		</section>

		<section class="section">
			<header>
				<h1 id="h_6" class="toc">Part II: Managing Your Teams</h1>
			</header>
			<p>The second part of the book focuses the <em>Team</em>, the people in it, their roles, their
				responsability and its leadership. Chapter 3 introduces Tom DeMarco's concept of <em>Jelled
					Team</em>, i.e. a team that is more than the sum of its parts, and is characterized by cohesion,
				challenging goals, frequent feedback, a common working framework and good communication.</p>
			<p>The Holy Grail. The dream of every team leader and its members. The good news is, it can be done. Any
				team can jell, and teams <em>like to jell</em> furthermore, if the proper conditions exist, and the
				three chapter in this third part will teach you everything from being a good team member to becoming a
				great team leader.</p>
			<p>In many ways, this was my favorite part of the book. It's amazing how a lifetime of experience is
				distilled in just a few pages. Chapter 5 (Leading and Coaching your Teams) is very, very inspiring and
				very helpful in understanding how to become a good team leader, how to motivate and involve people, and
				how to manage them rationally.</p>
			<p>The story of Humphrey's high school wrestling coach Umbach is a classic example of a truly
				dedicated, inspiring, and successful leader:</p>
			<blockquote>&#8220;The workouts were so tough that the matches seemed easy. By the end of the year, several
				of us were undefeated, the team took the 13-state championship, and we were campus heroes. All of this
				from a ragtag bunch of inexperienced recruits. It was Coach Umbach who made the team.<br />
				<br />
				Our coach's dedication, commitment and energy were amazing, but what I found most inspiring was
				that he really cared about how each of us did. I have always remembered how he made a small band of raw
				recruits into a championship team and how he fostered the kind of cohesive team spirit that made losing
				simply unthinkable.&quot;
			</blockquote>

		</section>

		<section class="section">
			<header>
				<h1 id="h_7" class="toc">Part III: Managing Your Boss</h1>
			</header>
			<p>The third part consists of a single chapter: <em>Negotiation your projects and defending your plans</em>.
				It doesn't matter if you want to pretend otherwise: as soon as you become a team leader and you
				have to deal with management, you'll have to deal with complex internal politics.</p>
			<p>This chapter is about learing to be pragmatically diplomatic and deal with management. It's about
				creating good plans that can survive confrontation with your managers, no matter what their demands are.
			</p>
			<p>There's no silver bullet: I appreciated the honesty of the author when providing solutions. Section
				6.6 (What to do when a project is doomed) is an example of this:</p>
			<blockquote>
				<p>You're on a project and it's headeing south. While everubody is trying their hardest, and
					you're doing your level best to help, you can feel it in your bones: the project is doomed to
					fail. What can you do? You have three choices.</p>
				<ol>
					<li>Keep plugging away and hope things will improve.</li>
					<li>Look for another job.</li>
					<li>Try to fix the problems.</li>
				</ol>
			</blockquote>
			<p>That's right. Look for another job. That almost made me laugh, but it made me understand that in
				some extreme situation that may just be the best solution.</p>

		</section>

		<section class="section">
			<header>
				<h1 id="h_8" class="toc">Part IV: Managing Yourself</h1>
			</header>
			<p>The last part of the book is about you. I would probably have moved it earlier on in the book, maybe
				right after the first part, but it serves as a good ending for the book. Chapter 7 (Taking Control of
				Your Work) is a must-read for anyone. It teaches you how to manage your working life, from time
				management (The 18 Hour Work Week) to psychological aspects (What Do You Want From Life?).</p>
			<p>Chapter 8 (Learning to Lead), is a nice writeup on the essence of Leadership, and what it measn to be a
				good leader rather than a manager. A great read.</p>

		</section>

	</section>
	<section class="section">
		<header>
			<h1 id="h_9" class="toc">Final Thoughts</h1>
		</header>
		<p>Reading certain sections of this book felt a little bit weird at first. <span class="caps">TSP</span>, <span
				class="caps">PSP</span>, heavy planning and documents&#8230; are they still relevant in a &#8220;real
			world&#8221; now dominated by <em>agile</em> practices, Scrum, Kanban and similar? Do you really have to
			provide detailed plans and documentation to convince management?</p>
		<ul>
			<li>You may not have detailed design documents, but you still have user stories.</li>
			<li>You may not be required to plan ahead of 6 months, but you still have to plan frequently and provide
				accurate estimates.</li>
			<li>You may not be required to trace and track everything you do, but at the very least you have to monitor
				your <em>velocity</em> and produce <em>burndown charts</em>.</li>
		</ul>
		<p>Yes, you read &#8220;<span class="caps">PSP</span>&#8221; and &#8220;<span class="caps">TSP</span>&#8221;
			everywhere in the book, but they are just labels. The methodologies and processes may change, but <em>the
				principles</em> will always remain true. This book is about understanding the very essence of management
			and leadership, and it will remain an invaluable resource for anyone who wants to build a career in the
			Software Industry.</p>

	</section>

</section>