Book Review: Management of the absurd

ManagementOfTheAbsurdI found this book in the discount rack at a used bookstore in Fremont. Having found much of what people call management quite ridiculous I laughed at the title and flipped it open. Inside I found validation for many of the pet theories and uncorrelated observations I’ve had over the years, written in clear, short, insightful chapters. It’s a gem. You’ll have many deep sighs when you read it and will feel relieved about the insanity at work that, until reading the book, you though only you felt.

The book does offer advice but is not a a how to guide. I found it more of a catalog of the inherent paradoxes of managing teams of people, things that impact everyone but are rarely mentioned.

The management of the absurd, Richard Farson. 172 pages.

The two points of contact theory

Here’s a hypothesis: It only takes two points of contact for people to validate a reference.

If I tell you Flogging Molly is the best live band ever, you’d nod your head politely but pay me no mind. But if on the same day, or same week, another aquiantance of yours, one completely indepenent from me, mentions Flogging molly, you will instantly validate both sources. I think we assume that random, unsolicited references that correlate with each other must be true. And we only need two of them to place our confidence in recommendations.

So I think the word of mouth effect is really about two points of contact. The first time we hear about something it’s not far from noise, but the second time, especially if the sources are diverse enough, we’re ready to take action. Should we hear a third mention of whatever it is, we’d probably say “Oh. Flogging molly. Yes, I’ve heard lots of good things about them.” Even though we’ve only had two previous points of contact, possibly from sources we’ve never relied on before.

I’m looking to see if anyone has ever studied how people make recommendations and how often they’re based on small amounts of second hand data from third party sources. I’m familiar with The madness of crowds but this two points of contact idea is about more pedestrian things.

Goals for this blog

This weblog started to log the making and release of a book. Well, the book is out and doing well – But what to do here now?

Here’s the plan:

Weekly short pieces on:

  • Management, teams and leadership.
  • The making of good things.
  • Design, technology and creativity.
  • Highlights from the pmclinic and uxclinic discussion lists.

Monthly pieces on:

  • As new book projects come together I’ll be writing about them here, bringing you into the process.
  • Longer essays once a month will be posted here along with other book news, meetups or tour dates.

And as always, if if you’re willing to post it, I’ll write about anything people ask for .

Cheers.

The mystery of the front row

Paolo_IX14_front_row

Wherever lectures happen, regardless of the size of the venue, most of the front row will be empty. Even when the lecture hall is standing room only (should we be so lucky), many of the seats up front will be vacant. In this photo you can see people standing, looking for seats, but not venturing towards the front.

Now at a rock concert, or sporting event, people would sell their children to get a front row seat. The only time I had front row seats at a basketball game it cost me $300 and I had to watch two bad teams: it was just too expensive to get great seats to see excellent teams.

The front row is almost always empty because:

  • We like the freedom to be bored. In the front, there’s nowhere to hide. If we want to nap, pick our nose, read e-mail, we can’t without feeling embarrassed. If the speaker is bad, we’re stuck, for an hour or more, in living hell.
  • We’re taught in school to go for the back. People in the front get called on by teachers. Most of us hated that experience, so we hide ourselves in the middle rows.
  • We have low confidence in public speakers. We’re doubtful it’s going to be good, and we want the option to leave quickly without embarrassing ourselves.
  • The front row feels like part of the show. Sitting within a few feet feels like you are on stage yourself, a feeling most people don’t like. Some people also fear being picked as a volunteer which seems more likely in the front.
  • No one can see from the back that the front seats are empty. Unless the organizers, or the speaker, actively helps people find the best seats, the audience might not even know they’re available. The speaker has a much better view of the audience than the audience does.

I suppose it’s a sign of a speaker with a good reputation when people confidently sit in the risky front row.

This diagram below from cartoon phdcomics offers several other theories about where people sit. My favorite part of their analysis is the proximity to lecturer formula, that divides how much you care by how tired you are. Perhaps it would be more accurate to measure how committed you are to the speaker. If you’re 100% convinced you need to listen to the entire lecture, you want the best experience possible. If you’re not sure, or if you’re at an event with multiple tracks, you want the ability to change your mind.

How Do You Fix This Problem?

In Confessions of a Public Speaker, in chapter 4 on how to work a tough room, I explain a technique. All you have to do as the speaker is take responsibility for the room. Ask people to stand up and move. It helps to have free books or Starbucks gift cards, but with some friendly requests and motivation, people will usually do as you ask.

It’s always in the speaker’s interest to improve the room. If people are spread too thin, the room will never feel good. It’s far better to have density near the front, than people sprinkled around a very large room. People need to sit near each other, and close to the stage, to feel like an audience. And as a speaker, you want the audience to feel safe to applaud, laugh and respond to while you’re presenting.

(Photo by Paolo Malabuyo, at IXDA14)

The life goal: writing books

The author page in the back of The art of project management Making Things Happen has this photo.

Scott's bookshelf

This represents a life goal: to write enough good books to fill the shelf. I’ve measured its width and according to my calculations I need to write 20-25 books to fill it. Since the book took a year to write, working nearly full time at it, I expect to be working towards this goal for the rest of my life. I won’t publish anything I’m not proud of so I’m after quality too, not just volume. If I die with a half full shelf of good books, I’ll still be a happy man (as happy as a dead man can be).

I think this goal is as insane as you probably do – but when I quit Microsoft in 2003 I made a long list of possibilites: this was the least insane. Just like everything else, insanity is relative.

Writing forces many good things to happen for me: most interesting perhaps is that I have to confront my own bullshit. I can’t just complain about things I don’t like or handwave about how I’d make something better: instead I have to sit down and try to do it myself. And if I do it right, other people benefit from the effort.

I’ll be writing more on this blog about the goal and my approach. If this interests you let me know: if not I’ll keep most of it to myself :) Any encouragement is encouraged and thanks for reading so far.

This week: Figuring out lessons to learn

This week in the pm-clinic discussion forum: Topic #47 – Figuring out lessons to learn.

Here’s this week’s situation:

We just finished a 6 month project: or more precisely, the project finished us. We had many of the major things that can go wrong, go wrong: big schedule slips, low quality code, and upset customers. We did finally deliver work to the customer but no one was very happy about it. Since we use agile we’ll be continuing to do iterations on the same codebase after a short break.

At last Friday’s status meeting we talked for 20 minutes about what we can learn from last time. Nobody spoke up. Our well intentioned, but somewhat confused, group manager talked the whole time and made vague suggestions without commitments. I don’t expect to hear anything about it again. I’m afraid that the next project is going to be much like the previous one.

Does anyone ever take time to learn from the past? Who should lead the process? How long does should it take? Has anyone experienced a good post-project review?

Comment here or join the clinic.

Teaching programming / management the Harvard way

Here’s a crazy idea: instead of trying to teach people by drowning them in books and materials, lets put them in the situations they’ll experience after college, while they’re in college. Crazy you say? Well Business schools have been doing this for a long time: it’s called the case method. Harvard Business school claims to be the originators of the idea, although I’ve come across the concept in various books on learning theory and teaching.

The challenge is that case or situational based learning requires different skills from professors and teachers. The teacher dominant model (think of your favorite grade school horror story), where there is one path of learning that the teacher defines, is easier to manage. But it’s controlled to the point where students contribute little to their own learning. And since it’s all tightly scripted, teachers are quickly bored by their own lesson plans.

CASE based teaching demands an interactive style, where discussion, interpretation and improvisation are primary to the experience. The teacher has to be able to intense classroom discussion of opinions and ideas, a skill many teachers don’t have (or are afraid to try and learn). It also demands a sense of incision and a point of view: something everyone has but many teachers are afraid to express.

Programming, design and management all benefit greatly from CASE based teaching, but it’s rare to see, even from professional trainers and consultants. And as far as colleges, many curriculums disapoint: even the senior projects rarely expose students to the challenges they’ll face after they leave school, and even fewer do it in a format worthy of their time.

Anyone have examples of CASE or situation based courses for managers, designers and programmers? Undegraduate or graduate?

Book review: Deep Survival

The book Deep Survival: who lives, who dies and why, by Laurence Gonzales, asks the question: why do some people survive dangerous situations and other people don’t? The author spends most of his time telling riveting survival stories: plane crashes, mountain climbing accidents, people lost in the woods – they’re all page turners, but Gonzales also pulls out details to offer theories and hypotheses, many of which are relevant to daily life.

I finished the book in two sittings, enjoying the stories and his thoughts on psychology, training, intelligence and stoicism.

The notion I can’t get out of my head is this: people that survive abandon their mental models of the world and open their eyes. They don’t try to force the world to be a certain way: instead they respond to the world like a child, taking it to be what it is, and working within the real world to try and survive (or thrive).

Every day since i’ve read the book I’ve caught myself trying to force something and stopped myself, asking: am I seeing how I want the world to be, or I am I working within the world trying to make it how I want to be?

If you enjoyed Touching the Void, this book will add another level to your appreciation of those stories.

Info on book tour part2: nyc, boston, pittsburgh

The planning for part 2 of the book is winding down. There are still a few slots open, so if you have a venue or a suggestion for one, let me know. If anyone wants to meet up for a meal I can try to make that happen, just let me know.

10/11 – Boston (open)
10/12 – MIT Sloan school
10/12 – MIT CS department
10/13 – Open (Boston or NYC)
10 /14 – Razorfish, NYC
10/17 – Cooper Union, NYC
10/18 – Carnegie Mellon University, Pittsburgh

Updated dates and time are now here and will be updated here.

-Scott

More on Firefox, IE & slashdot

Someone kindly submitted my post to slashdot this morning, and it took the site down for awhile – apologies. The first two times I was slashdotted it didn’t generate anywhere near the traffic this one earned.

I wanted to clarify a few things:

  • I left Microsoft in 2003 . I did work on IE for a long time (1.0 to 5.0), but the way the slashdot post was worded many assumed I’m still employed there: not true – I work on my own as a writer and consultant.
  • There is a good parallel discusson on Asa’s blog. Asa works on Firefox and is one of the folks that deserves the praise for making an excellent piece of software. I responded to a few comments over there.
  • Thanks for all the feedback and commentary. I doubt I’ll ever see this many comments for a single post again. It’s been fun – thanks for writing your opinions.
  • On ui design. The mistake we’re all making, myself included, is focusing on designing for ourselves. Designing for ourselves isn’t a sin, but if the game you want to win is market share, you have to work very hard to make sure your needs and wants jive with people who’s needs are less sophisticated than ours (Which is most of the planet’s web browsing poulation). Lots of folks said “my mom can do X” or “my friends can do Y” as justifications of how their experience matches everyone elses, but I think we’d all agree how fragile and anecdotal those claims are. Your mom might be a rocket scientist, and your friend might have watched you do whatever it is before they tried to do it themselves. I’m not saying I’m right, you’re wrong, or that your pants are on fire. Instead I’m saying that design arguments, ui design arguments in particular, can and should stand on firmer ground. There should be an essay somewhere called “how to have a meaningful UI design argument” (finger on nose).
  • On history trails, tabs and new windows. Folks pointed out at least a half dozen different ways both new windows and tabs are used. My stated opinion was narrow: apologies. But the concerns still strike me as valid (tabs make back/forward more complex, since there are now N history trails per browser window). I’ll need some time to read through all this, do some sketching, and rethink my stance.
  • On open source and design decisions. In digesting all of this, my primary thought is “how does each of these opinions/complaints/usage patterns, as diverse and sometime contradictory as they are, fold together into shaping a single design that’s of the greatest value to the most people.” I’m familiar with the extensions and how the community encourages people to modify, create and involve themselves, which rocks. It’s an innovation pool for ideas that can be considered for the core (Some might recall the Win95 and IE powertoys, it wasn’t community based, but the idea was similiar). But I flinch at using extensions as the copout to challenges to the basic design. It’s a great plan B, but as a designer, for core parts of the experience, the obligation is to dig deep enough that plan A stands tall on its own. I’m not suggesting anyone said otherwise: I just wanted to make sure we’re on the same page. It’s surprising how few mainstream users, of anything, customize. All the data I’ve ever in my career (web,software, etc.) is on the order of 10-30%, and that 10-30% correlates with advanced, savvy, early adopter, industry types: e.g. most of you reading this. I posit that most people, for most things in life, live with the defaults (I mean this about software and life in general).
  • I’m still reading through all the comments, so keep them coming. I can’t promise to respond to all of it (150 comments and counting, plus e-mail) but I do promise to read them all.

    Cheers.

Why I switched to Firefox

It’s a sad day and a good day. For years I’ve held onto my IE install out of love. I worked on IE 1.0 thru 5.0, and was one of the people that designed much of its UI. But my love for the past has faded. Last week I switched to Firefox: and I’ve been happy.

Why I switched:

  1. IE is a ghetto. There are specs I wrote for UI features in 1998 that are unchanged today, 7 years later, in a world where browser usage has changed dramatically. I’ve watched bugs that I fought to have fixed in 5.0 become regressions, appearing in 5.01 and surviving in 6.0. Even though it’s the product I was proudest of, using it now makes me sad – it’s been left behind. I do read the IE blog now and again – smart folks are working – but there’s nothing for me to install.
  2. Bookmarks work. The Favorites UI model in IE is the same one we built in 1997, when we knew most of our users had 20-40 favorites. It was made to be super simple and consumer friendly as most of the population was still new to the net. This UI is effectively broken today, designed for people that don’t exist. The Favorites menu and Favorites bar show links in different orders, the organize favorites dialog is just weird, multiselect doesn’t work: favorites is a sad forgotten place. This was by far my greatest frustration with IE, even though I’m responsible for much of the original design.
  3. Firefox has quality & polish. IE 5.0, for its time (1999), was a high quality release. Really, it was. Joe Peterson, Hadi Partovi and Chris Jones fought hard to give the team time to do lots of fit and finish work. We did fewer features and focused hard on quality and refinement. Firefox feels to me like what IE 6.0 should have been (or what i expected it to be after I left the team in ’99). It picked a few spots to build new features (tabs), focused on quality and refinement, and paid attention to making the things used most, work best. The core UI design is very similiar to IE5: History/Favorites bars, progress UI, toolbars, but its all smooth, reliable and clean.
  4. They made a mainstream product. One of the big challenges in designing software is balancing the requests of earlier adopters in the community, with the needs of the majority of more mainstream users. After playing with mozilla on and off I was afraid firefox would be a built for programmers by programmers type experience. It’s not. I don’t know who in the firefox org was the gatekeeper on features and UI, but I’d like to meet him/her/them (seriously). They did a great job of keeping the user experience focused on the core tasks. If you’re reading please say hi.
  5. Security isn’t annoying. . The press makes security into such a huge deal, but I’ll be honest. I don’t want to think about security at all. I’ll do what I need to, but mostly I want the system to take care of it and stay out my face. Nothing in FF makes me feel safer explicitly, I just don’t deal with as many warnings, settings and other details. I know from the PR that security in FF is better (even if only because it’s less targeted by spyware, etc.) but I’m pleased that the product doesn’t remind me of how safe I am all the time.

Problems with Firefox:

I’m a UI design guy, so many of these are UI related. (Added note: I’d used FF on and off, but since I’m now 100% some of these are complaints might fade in a month of usage. Stay tuned).

  1. Find UI. Why does the find dialog appear at the bottom of the screen? I agree that a dialog box (semi-modal) can be a mistake if you’re doing multiple searches, but flipping a coin for placement (top vs. bottom), the top is a better choice for any UI, especially if it’s going to look and act like a toolbar. I can’t move it so it earns a spot on this list. However, the overall implementation isn’t circa 1992 like the IE one. It highlights, it searches on type, & it warns on unfound items – nice..Firefox find
  2. Download UI. Here’s a case where modeless makes sense (it’s never my primary user task), but here we get a dialog box. My first crack at this would be a one line toolbar, much like the find bar, at the bottom of the screen telling me about downloads. That’s where all the other dl status info goes. Again, despite my nits, it’s an improvement on the ancient IE implementation (which we all hated forever too).
  3. Tabs and new windows. Firefox goes against IE behavior and starts each browser instance from scratch. IE intentionally brings the browser history into the new window: the bet being that users who want to continue from where they left off can, and those that want to go their home page can do that with one click. Everytime I hit Cntr-T and see a blank screen I think I’m in Word. I use tabs less often than I expected: opening new windows is often more comfortable – easier to track which window lives where. With multiple tabs (I find) the back/forward behavior becomes complex and hard to predict. Strict UI logic would put the tab UI above the toolbars, not below, but that creates other problems.
    Firefox tabs
  4. Tabs and modality. The desired illusion of tabs should be to make each tab a virtual browser. Well this breaks when you bring up a modal dialog within a tab: you can’t switch to another tab. It’s an annoyance, not a sin, but when it happens it reinforces my new window habit, and slaps my wrist on my growing New tab habit.
  5. The return of the go menu. It was with great pride that we killed the go menu in IE 5.0. It was the stupidest menu I’d ever seen, since it was never used and no one knew what it did. For accessibility it was necessary, but had no rights to be a top level menu (IE has View.Go). The Go menu was probably inherited from NSCP/mozilla, but it really should be put out to pasture. And if it stays, someone needs to explain why it shows a different history list than the one in the back button drop down.

For reference: I wrote about principles of browser design here: How to build a better browser.

(Update: I’ve responded to many of the comments in a second post.)

This week: managing up to executives

This week in the pm-clinic discussion forum: Topic #45 – Managing up to executives. This week’s situation comes from a web development veteran in a new organization.

I am an experienced web development manager: I’ve shipped a few things and have managed people for years. I’m in a new organization now and I’m having a hard time with my VP and the folks that work directly for him (I don’t).

I’m used to having significant authority over my team and my areas. I’m used to being in the room as big decisions that will impact my team are made: I’m at least a party to the discussion, if not at the center of it. I realize my place but I expect my VP or his subordinates to recognize mine.

Now, in this organization, I’m not even in the game. I am dictated to, or given decisions to respond to well beyond the point I can possibly offer alternatives or make a stand. My direct manager is ok, but ineffective. He doesn’t see a problem with how our organization works.

Should I:

1) Suck it up. The results are ok/good even if the means aren’t. Maybe it’s my ego that’s the problem.
2) Go direct to the VP (skip manager) and state my case.
3) Get political. Should I become more aggressive in obtaining power, getting a little rougher in how I play ball, and work around my boss if necessary.
4) Leave. Find a place where my role is more like what I want.
5) ?

Smart people, bad ideas and expertise

A previous essay, Why Smart People Defend Bad Ideas, continues to get feedback. People leave comments often and here’s a particularly interesting link (thanks CCJ).

From Studies in Intelligence (vol 47 no 1), a declassified CIA journal:

The Paradox of Expertise: the strengths of expertise can also be weaknesses. Although one would expect experts to be good forecasters, they are not particularly good at making predictions about the future. Since the 1930s, researchers have been testing the ability of experts to make forecasts. The performance of experts has been tested against actuarial tables to determine if they are better at making predictions than simple statistical models.

Seventy years later, with more than two hundred experiments in different domains, it is clear that the answer is no. If supplied with an equal amount of data about a particular case, an actuarial table is as good, or better, than an expert at making calls about the future. Even if an expert is given more specific case information than is available to the statistical model, the expert does not tend to outperform the actuarial table.

The full essay talks about the paradox of using teams to balance against expert bias, the role of methodology, etc. The context of the essay is, you guessed it, CIA type intelligence gathering, but in reading this essay much of it applied to any kind of complex work.

The full essay is here.

How to decide when to fix bugs, part 2

Part 2 of how to decide when to fix bugs, covering all the heavy duty strategy not covered in part 1, is now up on the O’Reilly open source site. Part 2 covers the following fun stuff:

* Level 3: exit criteria
* Level 4: early planning
* Exceptions to all of these rules
* Frequently asked questions
* References and resources on making bug decisions

If you want the backstory, here’s part 1.

Yesterday’s Artofpm Webcast now available

Well, that was fast. The fine folks at CMP and Dr. Dobbs Journal have made this talk available online in under 24hrs.

The Art of Project Management: This event can be viewed on-demand at your convenience.

The original event was broadcast on:
Date: Wednesday, August 31, 2005
Time: 11:00 AM PDT
Duration: 60-minutes

Description: During the session, Scott will present perspectives and techniques for project management from his recently-published book that has already sold over 20,000 copies. Learn from this veteran manager of software and web development how to plan, manage and lead projects. Scott goes beyond the book, talking about the fine print of leadership, attention/intuition/conviction, and tactics for working with others.