Peopleware

Kevin Kelly's excellent Cool Tools email reminded me of the classic Peopleware, by Tom DeMarco and Tim Lister. I think my copy is at the office (a foolish place for it), so I have to quote from Kevin today.

Hard-won wisdom fills this small book: How to create a team, place, or company that is productive. First published 20 years ago, and updated once since then, copies of it have quietly served as a guru for many start ups and successful projects in Silicon Valley. Neither academic nor faddish, two veteran consultant authors offer real intelligence. This book has totally informed how I do projects. I learned about the myth of overtime, the need for closure and ceremonies, how teams jell, and why everyone should and can have a window. I first read it decades ago and re-read it every time I embark on anything involving more than one person and several years of my life. Unlike a lot of management lore, it is aimed at the project level (where I want to be) rather than the large organization. The message in the book touts productivity, without ever mentioning the dreary idea of time management. It's more about optimizing people, and thus the title, Peopleware.

I've posted before about teamwork and invisible work, and Peopleware is all over this stuff. Here's an anecdote Kelly cites from the book:

I was teaching an in-house design course some years ago, when one of the upper managers buttonholed me to request that I assess some of the people in the course (his project staff). He was particularly curious about one woman. It was obvious he had his doubts about her: "I don't quite see what she adds to a project -- she's not a great developer or tester or much of anything." With a little investigation, I turned up this intriguing fact: During her twelve years at the company, the woman in question had never worked on a project that had been anything other than a huge success. It wasn't obvious what she was adding, but projects always succeeded when she was around. After watching her in class for a week and talking to some of her co-workers, I came to the conclusion that she was a superb catalyst. Teams naturally jelled better when she was there. She helped people communicate with each other and get along. Projects were more fun when she was part of them. When I tried to explain this idea to the manager, I struck out. He just didn't recognize the role of catalyst as essential to a project.

Which reminds me of the need for root cause analysis of successes. At one of my previous companies, we had a big focus on root cause analysis of problems in order to avoid making them again. In itself this was laudable, but there wasn't quite the same focus on root cause analysis of success. Unless you want it to be accidental, lack of root cause analysis of success might prevent repeat performance of success by not recreating the same conditions that led to it in the first place. Not understanding the role of team members and not understanding how to diagnose team success, except in terms of org charts and job titles, can contribute to this management misstep.

I've concluded over the past few years (and it's the subject of an article I'm supposed to be writing), that project level management requires an anthropological mindset. If you aren't interested in the news from the field, and in forming conclusions from raw data from people doing the actual work, you are more likely to form erroneous or overly "easy" conclusions; you have to instead rely on standard management book guidance and act on previously filtered information that's highly likely to be biased or dangerously incomplete. Sure, every modern anthropologist admits her own biases play a role in terms of what she sees and hears. But wouldn't you, as a manager with sufficient time, rather be filtering the raw data rather than taking in someone else's biased filter? A few design and project train wrecks can be avoided by talking to the right people at the right point, when there's time to be an influence for the good.

Cryptid Hunting: What to Bring Along? at Cryptomundo.com

It's that time of year again: Bigfoot season. Cryptomundo.com posts an article about what extras to bring along on your hunt, to ensure proper scientific, nay, forensic, attention to the evidence. In Cryptid Hunting: What to Bring Along? we are told that today's Bigfoot hunter needs to pack:

1. Paper sacks and envelopes
2. Camera/video recorder (Preferrably with night vision)
3. Tweezer/tongs
4. Rubber gloves
5. Magnifying glass
6. Parabolic mic
7. Plaster of Paris
8. Tape measure
9. Log book
10. a few sterile collecting bottles or containers for fecal material samples and for urine specimens
11. tapes to record from your parabolic mic
12. "For DNA collection, you will want to have sterile latex gloves"
13. "If hair sampling envelopes are not available, place samples into small sealed paper envelope or zip lock bag (no brand recommended). Use a permanent marker or pen, clearly include all sampling information with each sample. This includes name of collector, time, date, assumed cryptid, human, or known species name, field tag number, gender (if known), age (if known), location including lat./long., Universal Transverse Mercator (UTM) or township."

Ok, it only gets weirder and more obsessive. Read at your own OCD risk.

UFO Maps

Alright, this really tickles me: UFO Maps, brought to you by a mash up of Google maps and the National UFO Reporting Center.

Click on a cute little flying saucer graphic and you can find the report associated.

Edited to add: Here's another good one: Real-time satellite tracking over Google maps. Real-time in that the little satellite graphic moves as you watch, and the map shifts under it.

Joel on Being in Control

Excellent post by Joel Spolsky on the latest release of his bug tracking software, with a lot of design observations: FogBugz 4½ and Subjective Well-Being - Joel on Software. Complete with management advice, tying back to the theme that management is design too.

...the most important thing that I learned in Psych 110, the idea that when people are successful at controlling their environment they become happier, and when they can't control their environment, they get grumpy.

How do you achieve delivering a feeling of control to a user in an application? Well, good feedback and speedy response are critical elements, otherwise the user doesn't emotionally connect her action to the resulting behavior of the software. Oh, and predictable outcome from user action, of course.

Also, drat him, he got one of my hobby horse design ideas that I never understood why we didn't do at Adobe (I know that's ungrammatical)... A toggle to reveal to you the keyboard shortcuts for each app buttons so all you have to do is look and then type it. No annoying mouseover in order to find out and then force one to remember it. So simple, so obvious, so NOT DONE ANYWHERE (that I've needed it, anyway).

Brett also snuck in a feature he's been itching for: lots and lots and lots of keyboard shortcuts. There's only one keyboard shortcut you have to memorize, though: Ctrl+; switches FogBugz into keyboard mode and little letters light up reminding you what the shortcuts are for various commands around the screen. It's really pretty cool to be able to work through a bunch of cases, assigning, editing, and reprioritizing, without ever reaching for the mouse.

Mt Auburn Cemetery, Cambridge MA.

Management, Design, Evidence

Another one on Kawasaki's blog impressed me today -- I'm just in the mood for thinking about management, as someone trying to hire now. Kawasaki posted Ten Questions with Bill Sutton, author of Hard Fact, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-Based Management.

My boss and I spend a certain amount of time discussing how to measure what we do and determine success, a particularly difficult problem for a design organization. We aren't, after all, able to conduct experiments like having two teams in isolation working on the same problem, one with design process and deliverables, the other with none. Sutton advises that if you can't do a controlled experiment, at least make sure your supposed cause precedes your supposed effect :-)

Sutton also comments on a few "evidence-based" writers on management and innovation:

I also love Larry Prusak, the knowledge management guy. He is smart, well-read, humble, opinionated, and evidence-based. And much better read in academics than any academic I know. ...

I also like Malcolm Gladwell and Steve Levitt and their models of evidence-based management. Although, I think that Blink is much weaker than The Tipping Point because Gladwell misses that the instant judgments he praises are developed through years of experience. You have to do a lot and think a lot about something before you can do the blink thing.

Finally, a prediction, I think the next big guru, at least if ideas and ability to present them counts, is Chip Heath of the Stanford Graduate School of Business. He has a book coming out with his brother called What Sticks about the kinds of ideas that people remember and what persists. It not only is based on sound research, it is also hugely practical (I’ve seen executives get so excited by his stuff that they immediately grab him for gigs).

Design management is a special kind of management, and requires special kinds of innovation grounded in both evidence and insight. I've been reading and enjoying Managing as Design, another Stanford Business product. It's a great collection of fairly academic and thoughtful pieces on organizations and management especially around design, with a fair amount of thought on architecture in it.

Edited to add: I forgot I meant to talk about evidence in management and the role of conversation and email in decision-making. Scott Berkun reminded me in his post on The Things You Never Hear. There's all sorts of decision-making in organizations that's based on slim or biased reporting from the "ground" and managers often never hear -- or don't want to hear -- the things that would make them more effective. Worse, in a social networking sense, there's diagonal or peer-level information that would be useful, that the relationships or physical proximity or office politics don't support hearing. Gossip can be important in an office, but it does need to be evenly spread to be of a useful evidential nature. There's another whole post in this somewhere, though...

PersonalDNA

There are personality quizzes all over the net, spread as memes via sites like LiveJournal where memes have a long life. PersonalDNA is a next-generation personality quiz, with high quality widgetry that the respondent has to manipulate to set their answers. While fun to take, I am not so sure that all that gadgetry entirely supports the problem at hand and it probably detracts a bit. I found it hard to figure out where in a quadrant of 4 my "dot" should live in a case like this.

On the other hand, it's very fun to take, and you get the results in nice couple of visuals suitable for posting in a blog with the URL; and you can ask other people to rate your own personality and compare the results. It has all the makings of a successful meme, and for once it looks like some serious visual design and engineering went into the site. I wouldn't be surprised if someone like this finally figures out how to make some money off this stuff; there's millions here waiting to be had, given the massive popularity of these quizzes in social sites.

Incidentally: I came out as a "Benevolent Inventor."

PersonalDNA | Your True Self Revealed - Fast Fun Free Personality Tests.

The Top Ten Lies of Engineers

Another good one from Steve at tingilinde, this made me laugh in my coffee: Guy Kawasaki: The Top Ten Lies of Engineers. I already posted Scott Berkun's Things VP's Never Say, and this makes a great complement. Things lots of engineers say... whether intentionally lies or not. A sample:

“Our beta sites loved the software.”In twenty five years of working in technology, I've never heard a company report that its beta sites didn't like its software. There are three reasons for this: first, many beta sites are so honored to get pre-release software that they don't want say anything negative. Second, most beta sites haven't used the software very much. Third, most beta sites don't want to seem cruel by criticizing a company's new product. Doing so is as socially unacceptable as telling someone that his baby is ugly.

“I'll comment the code, so that the next person can understand what I did.” This is a lie of good intentions. Really, the engineer did intend to comment the code but as the schedule slipped, priorities changed. The question put to management became: “Do you want me to comment the code or finish it sooner?” Guess what the answer was. Luckily, the lack of comments usually doesn't matter because the code is so crappy that a total rewrite is necessary in a year.

Watercolor Angel, Mt Auburn Cemetery.

Mt. Auburn Cemetery, Cambridge, MA.

Cloaking Device

Guardian Unlimited: Now you see it, now you don't: cloaking device is not just sci-fi:

The cloaking device relies on recently discovered materials used to make superlenses that make light behave in a highly unusual way. Instead of having a positive refractive index - the property which makes light bend as it passes through a prism or water - the materials have a negative refractive index, which effectively makes light travel backwards. It's light, but not as we know it.

Prof Milton's team calculated that when certain objects are placed next to superlenses, the light bouncing off them is essentially erased by light reflecting off the superlens, making the object invisible.

The calculations show that while the device could be used to obscure almost any shape of object, it only works over a short range of wavelengths, so if used to hide objects from human vision, they might only partially disappear.

Seems like a good opportunity for ghost sightings in the distant future.