The Soul Ofa New Machine

The Soul of a New Machine by TracyKidder, winner of a PulitzerPrize (1981)

A very fine book about a team building a new computer for DataGeneral. It is quite readable to the non-specialist and won a PulitzerPrize, but is particularly poignant to ComputerPeople?.

Better than most other books, it captures the intense thrill of creating something new, the agony of debugging, and the sadness that the system into which you've poured your HeartAndSoul? will eventually be obsolete and forgotten.

Somewhat similar to MicroSerfs?, but the style is more like journalism and less like a novel. -- Unsurprisingly - MicroSerfs? is a novel, TheSoulOfaNewMachine is NonFiction?.

A recent (2000) edition of Wired caught up with the team. Interesting to see photos of the team and match names with faces. Some interesting insights from team members on career development over twenty years. The biggest surprise for fans of the book is that Tom West stayed with Data General.

http://www.wired.com/wired/archive/8.12/soul.html

Ahh. This is *the* book solely responsible for my becoming an engineer. I read it over and over and it just fascinated me. I wanted to be that. So I went to school and instead of DG I ended up at DEC. To this day, this book holds dear fond memories for me and I read it every once in a while. -- sg

I think one of the most powerful ideas I remember from this book is the concept of team members SigningUp, a major step of commitment to the project. Once a team member "signed up", it was understood that they would do whatever it took to do their part; food, sleep, and life became secondary considerations. (Am I remembering this correctly; it's been a while since I've read it?)

I see this as an extreme version of ownership, which I look for on my teams. I want to do more than just assign a task to a developer; I want to discuss it with them and have them choose to own the task. If they own it, I can assume it will probably get done. If they don't own it, I'm going to have to coax and prod them along. Same thing when I'm the worker bee...

This is one of my AlarmBellPhrases. To date, the only time I've been asked to own a problem, it translated to we want to dump this problem on you, and not have to worry about allocating other resources to it. I was handed the problem when another team decided it was my problem, but was unable to hand it off [over?] when I discovered it was a hardware problem in a device yet another team was responsible for. If I'm going to be asked to move mountains if necessary, I want the power to requisition bulldozers. -- PeteHardie

No doubt, any phrase or concept can be misused. I once had a boss who tried to use more modern or "enlightened" management terms in old ways: "I'm empowering you to do this." (translation: "I'm telling you to do this.")

When I use own, I mean it to avoid bureaucratic stagnation, as in...

manager: "Have you done X yet?" worker: "Well, I did the Y part of it, but I'm waiting for Smith in accounting to give me a Z." manager: "When will he get that to you?" worker: "I dunno. I sent him an email two days ago, and he hasn't replied." manager: "I want you to call him today. Give me an update by 5pm." worker: "Okay..."

In my (contrived) example, worker obviously does NOT own task X. He's just bouncing it around, trying to keep it off his "plate." He doesn't care when or whether it ever gets done. Managers have to care, they're responsible for the ultimate success or failure of their project(s) and/or team(s). But managers shouldn't own everything, and personally follow up/through on every single task.

There are two broad ways of managers and workers to work together: (1) the manager can "drive" the worker, tell them specific steps to do a task; or (2) the manager can assign a problem or task to a worker, who then "owns" that task and drives himself or herself to get it done to the best of their ability. This doesn't mean doing the impossible, it just means taking responsibility for the ultimate solving of a problem or completion of a task (including handling special cases, organizational resistance, doing things that may not be "my job," etc.)

I think (2) is preferable, not just for the manager, but also for the worker. I personally prefer to be given a moderately sized "chunk" of a project, and then be left alone while I solve it my way. I'm happy to give my manager updates as I work on it, but I don't want or need micromanagement. I own the task, it is mine, and I will see it through. If I run into obstacles or difficulties, I'll let my manager know, especially if I need more resources.

"Never tell someone how to do something. Tell then what to do and let them surprise you with their ingenuity." - George S. Patton

To bring this back to TheSoulOfaNewMachine, I see SigningUp as an extreme degree of (2). It isn't always going to happen, and it isn't a personal failing if someone doesn't care enough about a given task to "sign up." Maybe there's a spectrum of caring, with "signing up" at one extreme, "don't care at all" at the other, and "owning it" somewhere in the middle...

The DataGeneral (and ExtremeProgramming) concept of SigningUp is superior to your "ownership", because it is voluntary. Getting people to want to do a good job is the best way to get things done. Your (2) imposes ownership of tasks on people who don't want them. That's likely to be ineffective in the long run. People are a lot more likely to shirk their duties, and maybe even to quit. Managers certainly do have to assign unpleasant tasks to people, but they should acknowledge the fact that they are unpleasant, and should not use euphemistic terms like "ownership" or "empowerment" to describe the process.

(I think we're editing in parallel, because I just tried to add this, which addresses some of your points. Please note that "ownership" is not mine, and doesn't have to be a euphemism. But I agree completely with your overall point, and I didn't intend (2) to be forced ownership.)

Okay, now that I think about it, there is a very fine line here. I just added the SigningUp page, and used the phrase "do whatever it takes." That is now a major AlarmBellPhrase to me, because I had a manager use it when I was already mired deep in a pit of despair over an impossible task (see NoSecondChance). I had thought this was a very good manager, but when she said that I lost all respect for her, because she was ignoring the reality of the situation and asking me to perform some superhuman leap.

I think a VERY important aspect to the "proper" way to ask somebody to own or "sign up" to a task is allowing them to say "No", and making sure they understand that you want to hear the truth. I recently tried this with a developer on my team, but I don't think he "got it." I even explicitly said that if he didn't want to own the problem, I would. He said, "No, I want to own it," but since then he has not REALLY owned it; I have to drive him... Oh well...

For some, when they seek ownership of a task, what they mean is "I want the PointyHairedBoss to get off my back about how to do it; however I don't want to take full responsibility if it doesn't get done in a timely and correct fashion". Of course, for some PointyHairedBosses, the opposite meaning is used--"I want Jones to take responsibility for X if it isn't done; however, I still reserve the right to micro-manage Jones' performance of X." In both cases, the party wants to have AuthorityWithoutResponsibility.

I had just started working on the DG AOS/VS platform (1985) when I encountered this book, by no coincidence. After reading it, I had deep suspicions that anything DG could be part of a robust and reliable solution. I was assured by my contemporaries that the Eagle of the book was many many DG generations ago, and that things were quite stable now. A bit of a hard sell, that was.

The most important thing I got out of "Soul" was an example of the difficulties caused by seriously postponed attention to integration. Those guys may have been extreme in many of their practices, including the sign-up-style commitment referenced above on this page, but one thing they certainly didn't do was test early. Not in the big picture, anyway.

-- WaldenMathews

See also TheSoulOfComputerScience. --jmh

CategoryBook