Demotivation and Burnout

Picture from Creating Passionate Users

Today's post is brought to you by a five day vacation, during which I've been catching up on some reading and not working long hours! I've found a couple interesting pieces recently on the subject of why people burn out, which suggests it's not the overtime in itself.

The first article was on Blogher, It's Not Just You. A recent Wharton School study looked at reasons for worker burnout. (It's unfortunately not yet available free online.)

"One of the biggest complaints employees have is they are not sufficiently recognized by their organizations for the work that they do. Respect is a component of recognition. When employees don't feel that the organization respects and values them, they tend to experience higher levels of burnout." Or, as Ramarajan puts it, "it is often not the job that burns you out, but the organization."

It turns out there was another good piece in the NY Magazine, Can't Get No Satisfaction, which meanders through social worker burnout, teacher burnout, medical burnout, and into high tech and NY Wall Street burnout. This one notes previous good research:

In 1981, Maslach, now vice-provost at the University of California, Berkeley, famously co-developed a detailed survey, known as the Maslach Burnout Inventory, to measure the syndrome. Her theory is that any one of the following six problems can fry us to a crisp: working too much; working in an unjust environment; working with little social support; working with little agency or control; working in the service of values we loathe; working for insufficient reward (whether the currency is money, prestige, or positive feedback). “I once talked to a pediatric dentist,” she says, “and he said, ‘A good day is when there are no screamers.’

Googling for Maslach, I hit an online quiz that rates your current level of burnout risk. The questions are about how you feel and about your work environment, as predicted by Maslach's findings. (E.g., "Do you feel that you are achieving less than you should?"; "Do you feel under an unpleasant level of pressure to succeed?"; "Do you find that you do not have time to plan as much as you would like to?" etc.) See how you score!

Finally, there's a related by different piece I just read when catching up on Creating Passionate Users, on Knocking the Exhuberance Out of Employees. When you burn people out, you've got robots and zombies working for you. Zombies and robots don't argue, don't have ideas, and don't threaten you or the status quo. They're a lot easier to manage, too. Hopefully no one who works for me is reading this, though, because I like arguing with them and am in no way an advocate of less exhuberance. Let that go as read!

Lastly, an article on Job Burnout in an online manufacturing magazine says (citing Maslach) burnout is about a mismatch "between what people are and what they have to do. It represents an erosion in values, dignity, spirit, and will-—an erosion of the human soul." America, with increasingly long hours and questionable corporate values, is a leader in burnout. We measure customer satisfaction, but worker satisfaction isn't a serious corporate issue, and the 40 hour work week is long dead.

Postscript: I can't believe I forgot the classic article on burnout, the electrocuted dogs experiment by Seligman: Learned Helplessness. This one has a positive spin to it, in that it suggests some therapeutic ways out of the syndrome. Happy New Year!

Innovation 1000: Companies Profiting from R&D

An excellent study of companies spending money on R&D over the last five years, and their payoff (or not): Smart Spenders: The Global Innovation 1000.

Some takeaways from this study:

Patents don't equal profit. Although a common measurement for innovation, it's a distractor: portfolio doesn't equal profit.

"Money simply cannot buy effective innovation."

There are no significant statistical relationships between R&D spending and the primary measures of financial or corporate success: sales and earnings growth, gross and operating profitability, market capitalization growth, and total shareholder returns. Gross profits as a percentage of sales is the single performance variable with a statistical relationship to R&D spending.... Researchers who study innovation estimate that 70 to 80 percent of the final unit cost of a product (the cost reflected in gross margin) is driven by R&D-based design decisions — for example, product specifications, the number and complexity of features in a device, the choice of standardized or customized parts, or the selection of manufacturing processes. This correlation of R&D spending and gross margin shows that in many companies, the R&D silo has succeeded in its narrow goal: creating a lower-cost offering that thus yields a wider margin, or a more differentiated offering for which a higher price can be charged.

R&D money is being offshored-- or innovation is now occurring in the "rest of the world" rather than Europe, North America, and Japan.

The "integrated value chain" of innovation shows that companies that leverage their "ideation" into commercial products more efficiently are seeing payoff. This makes sense, but seems to be hard to do.

Many high-leverage companies apply distinctive approaches to innovation at all four stages. For example, from the ideation stage through project selection and product development, high-leverage innovators tend to prize end-user input. The Stryker Corporation, a $4.9 billion medical technology company headquartered in Kalamazoo, Mich., works closely in R&D with the surgeons and other medical professionals who use its products. The Black & Decker Corporation’s innovation strategy is also heavily determined by end-users. “We’ve spent a lot of time focusing on where they work, where they play, where they buy, and where they learn,” says CFO Michael Mangan. “Understanding and developing those relationships really increases the efficiency of our new product introductions.”

There are two great stories of how two very different companies seize opportunities. SanDisk operates by watching the market for parts and capitalizing on opportunities offered by lower costs.

In the flash memory industry, prices fall 40 to 50 percent per year. Thus, at SanDisk, a small team of senior executives meets twice per week to monitor prices and market trends. Their awareness, fed back into the company’s innovation process, allows SanDisk to act quickly on new opportunities. In 2004, for example, the company realized that falling costs had created an opportunity for it to enter the market for MP3 audio players with a flash memory–based device. Management contacted an original equipment maker, defined design specifications, and delivered the new product to retailers’ shelves within six months. The SanDisk player is now number two in the market, after Apple. “We don’t have big planning and product committees,” says SanDisk Chief Financial Officer Judy Bruner. “Most decisions, even those involving huge capital commitments, are made pretty quickly by a small number of pretty visionary people.”

Symantec leverages shared code and a strong core engineering team that allows them to be nimble when responding to changes. “We have a large portfolio of products and business units,” says Ann Marie Beasley, vice president of strategy. “One of the key contributors to our R&D bang for the buck is that there’s a lot of common engineering and design, as well as actual code reuse.”

Not profiled in this article, I recently read an update on Philips Design in Fast Company: Design Intervention. Philips has been recruiting for at least 6 years for its R&D Lab, and I keep wondering what's up with them. This piece pointed out a couple positives from their output, which I recall seeing in stores, including the the Ambilight HD LCD display.

A 1995 Philips Design project called "Vision of the Future" was conceptually very similar to the Simplicity extravaganza in Manhattan--a flood of flash-forward products and ideas. Indeed, the concepts unveiled back then read today like a laundry list of the technologies that are changing our lives, including personal digital assistants and voice-recognition systems. Three years later, though, Philips went back to see how many of those concepts had actually gone into production and discovered that while a laudable 60% were already for sale, only 3% of them were made by Philips. "Their design and technical specs were usually good," says Enrique Dans, a professor at Instituto de Empresa Business School, "but they were disconnected from the market."

They're learning from history and adjusting, it seems.

"Philips's total sales from products introduced in the last year were 49% of total revenues in 2005, up from just 25% in 2003. In medical systems alone, an industry with long product cycles, some 70% of revenues came from products less than two years old--up 20 percentage points from the previous year. And despite disappointing LCD results in 2006's second quarter, from a less-than-expected World Cup boost, growth in Philips's medical systems and consumer electronics came in better than expected, at 9% and 10%, respectively."

I'm always impressed by companies that learn from history. And by good analysis in business. Edited to add: There's a nice piece here about a guy studying incentives for failures, a critical part of the innovation process. A lot of companies pay lip service to the value of risk-taking and failure in the corporate learning process, but few of them have incentive plans that reward risk-taking with failure rather than rewarding only the success stories. Employees aren't dumb when it comes to rewards vs. lip service and know what really counts to their managers.

Twenty About Design

I seem to update this one once a year. I wrote it when I was frustrated about the invisibility of design as a process and a skill at one company, and I've updated it to moderate it and expand and then contract it over the last 18 months. The latest update focuses more on hiring (a perpetual issue), teamwork, and recognizes management as both a problem and a solution in corporate culture.

Twenty Things About Design

Morocco Photo Selection

I haven't had the time to do this carefully, so this is rather hasty -- but here's a selection of the photos I took in Morocco this summer.

Atlas Mountains Town

This is where they filmed the slave town in Africa for Gladiator -- they added a fake Hollywood gate to the front of this place for the movie.

Google Patents Sketches

If you like sketches of product designs, and things people patent (often very odd), I recommend Google Patents search. For the product designer, these sketches are often educational as effective communication tools.

Warning: Most software companies don't want you doing any patent searches on anything you work on, because it can get you in legal trouble if you have prior knowledge of existing patents when you produce new designs. So avoid searching on patents related to your current software design work!

Dennis Frailey: A Day in the Life

Last week I was lucky enough to be in a 3-day training course on project management. I was not entirely sure this course was a good idea for timing and content reasons, despite having a great interest in the topic myself-- but the instructor proved me wrong.

Rather than the usual consulting company instructor (these people often piss me off), we got a thoughtful, wise practitioner, who impressed all of us (a tough crowd) with his depth of experience in the software industry and his thorough research understanding of the problems we were facing.

Dennis Frailey's ACM "a day in the life" bio story is here. The university classes he teaches are described here. He has made career changes based on revised understandings of the "real" problems he encounters in daily work. I share his impressions about research and practice, although I've had far less experience than he has at either:

Although I loved teaching (and still do it on a part time basis), I quickly learned that survival in academia is based on "research", not education. And the numbers game rewards you for cranking out large numbers of papers rather than small numbers of really good papers. I did some innovative research in the areas of real time operating systems and computer architecture, but I found most of the really interesting work in these fields was being done in industry... And when I was granted tenure, I learned that the research that counted the most was what I had done for industry and could not have done in academia. Moreover, there is a certain sense of satisfaction one gets from building a real product that one cannot get by writing research papers. This led me to consider and ultimately to accept a permanent move to industry, which I did in 1977.

Once in industry, at the corporate engineering center of Texas Instruments (now part of Raytheon), I discovered something else. Most of the real problems are not to be found in the research labs but in the areas where real products are being planned and developed. Thus I migrated from doing computer architecture research to actually building computer and software systems that had to work. This gave me a deeper appreciation of the intellectual challenges and rewards associated with "getting dirt under your fingernails" so to speak. It also gave me a totally different understanding of what software "engineering" is... Once I had to make reliable systems that peoples' lives depend on, I began to appreciate the need for "engineering discipline" and for greater emphasis on understanding the processes we use to develop software. This led me to move into new parts of the company where I learned about different kinds of issues. Many years later, my varied background has qualified me for a senior technical position where I am expected to understand the entire scope of a problem, from the technical details to the management concerns.

I bailed from research for some similar reasons, during the dot com boom. I've also had the intuition for years that the hardest problems in building software are not the technical problems or even the design problems, but the management problems. Which may be one reason that UI design and usability methods haven't had the impact they should have had on the industry -- not because of lack of the value they add, but because lack of organizational historical data (of most kinds, but especially quality and process-related), management incomprehension and lack of good design and planning during the dev process, and resulting interdisciplinary confusion and contention when pressure hits. Not to mention that even without the design process differences that UI and usability introduce, complex software development management seems to be entirely lacking at many companies. Chaos, confusion, and conflict are the norms I've experienced in most schedule-driven releases. Few people can make the complicated, emotionally-laden tradeoffs required in a mature, big-picture style, because there just aren't enough managers with this kind of skill and vision.

You can tell a lot about someone from who they admire and why. Dennis's response to this question:

One man I admire is Eugene Helms, who was my first boss at Texas Instruments. He would often sit through a meeting, say very little except asking a few questions, and in the end would sum up the most important points - i.e., he listened, thought about what he was hearing, and put it all together. He also trusted those who worked for him to know more about their specialties than he did. As a result, he could see the big picture better than just about anyone else. He was kind and supportive, and he would stand up for what was right.

I admire Dennis, and I hope that says good things about me.

VPs as Indicators of Problems

Scott Berkun has a nice snarky post about VPs of Innovation; if you've got one, you're probably in trouble on that front, and it's not likely they're going to help.

Which reminds me of a company in my neck of the woods (not mine): they're created a "VP of Retention." I heard this from a friend recently, as we've interviewed a bunch of folks bailing ship from that place. Ok, kudos to their executive staff for noticing they have a problem; but sad and sorry it is that they had to "solve" it at that level, didn't notice before, and haven't done enough analysis internally to understand why they have a management disaster on their hands.

Management is the least recognized role and the most important, in these situations, in my experience.

A collection of professional essays...

The more involved in management I am, the less I feel I am doing things that I can point to and say "I did that." (Also, the less I work for companies that make consumer or well-known products, but that's a different issue and a weird trend I noticed a few years ago...) But I got the good news today that an essay of mine will appear in a book accepted by MIT Press for 2007 publication along with many others by names that I know from my field: luminaries, old friends, and former research colleagues. Most of the other authors are probably wondering who I am in this list; I feel honored to be there and to have been invited to submit something to it. Here's the info on the current Table of Contents: HCI Remixed: Essays on Works that have Influenced the HCI Community. (This book must be 500 pages long!)

We're all writing about previous work that influenced us, in a personal essay vein. It could become a nice secondary textbook in a reading course in interface design or human-computer interaction research. I was fascinated by the list of source papers and immediately downloaded a bunch that I didn't know myself. As soon as I flipped through them, I wanted to know what the other folks said about them. I can see the appeal of this collection immediately. Great idea, Tom and David.

Alligator

Data and Infovis and "Art"

I've been thinking about data a lot, since the Infovis 2006 symposium. At this conference was a strange mix of scientists, mathematicians, and a few artists, or those with an artistic bent.

My friends Martin Wattenberg and Fernanda Viegas from IBM Reseach Cambridge secured funding, invited submissions, reviewed, set up the equipment for, and then sat guard over (missing talks in which they were cited) an art show of infovis applications. They were specifically featuring artistic displays of real data (I'm paraphrasing what I think they said were their selection criteria. One was Golan Levin's The Dumpster, which I blogged about a while ago.)

To introduce this art show, they gave an excellent talk that I'd summarize as "What's Going On Out There in the Real World That You Might Not Know About." A bunch of us saw a lot of people in the audience noting down the existence of Ben Fry's Processing Toolkit that makes programming datavis apps accessible to artists and ordinary people who aren't postdocs in mathematics. Sadly, it reminded me of 5 or even 10 years ago when the CHI and CSCW research communities realized web startups had already made community apps that worked and they weren't made by researchers in labs. Where's the actual innovation happening? More often than not, it's students or other clever people with time on their hands and a willingness to play around.

But back to data: When I was doing my dissertation, data was a sticky subject. Collecting data on "human subjects" was overseen by strict board reviews and ethical examination, and I had to go through this as an early internet researcher with a Human Subjects Board who didn't know what to do with this kind of data.

The community I "studied" reacted strongly to some of the data that I collected, post-processed, analysed, and reported, regardless of the reviews I went through. My data said some things that they didn't want made visible, or suggested things they didn't like simply reducible to graphs and charts. (The book is available here, the last chapter discusses this problem in some detail.) Anyone who looks at or exposes recorded human behavior is going to hit this: for example, people who don't think they talk much and discover they talk all the time often don't like knowing this, however measurable it is and however potential this exposure might be for them. Which brings up the questi0n of why and when should you turn something into data? And analyse it?

So, thinking now about how the research and infovis worlds have evolved since then, and the new inevitability of data mining on behavior from the traces we leave behind us, I see these data source dimensions:

1. Data sets that exist and are known to exist-- census data, weather data, stock market data.
2. Data that "happens" but isn't necessarily assumed captured or turned into a set that's easily analysable: email, chat, mobile phone records, my retrievals from ATMs, where I walk and what I eat.
3. Data that we set out to measure, because we're looking for something: experimental data, NSA tapping us, etc.
4. Data we have (from any of the above means) and we converted to another form of data: e.g., turning activity logs into summaries of time on tasks, turning gene sequences into musical notes, turning video of your cats into a single overlayed image, turning text into images, etc.

The really creative apps for infovis often seem to lie in item 4), because transformation of data into other modalities is a trick of visualisation that might give us insights we didn't have before. Some of them are just elegant visualisations of data we wouldn't have thought of visualising (like Ben Fry's zipcode applet that Martin called an infovis "haiku"). The "insight" part is still tricky to handle; human perception differs, and reasoning skills differ, and that makes drawing conclusions from visualisations tricky too. (Untutored people generally make more of statistical tests than they should, too.)

Martin and Fernanda stayed safely away from defining "art" but I still thought about the artistic component of data mining. The value of data mining and the ability to form and then test hypotheses from different views of data is a skill, perhaps even an art in itself. An event occurs: I capture it, I capture multiple instances of it, and I look for patterns in different views of it, and then I learn from it or measure it some more or in another way to progress towards some truth.

Or, for the more artistic data visualiser: she captures it and events like it, she presents it in a novel and beautiful way, hopefully with some elegant interactivity, and other people learn something. The might learn something ineffable or impossible to reduce to words. But that doesn't make it less important. Scientific creativity still springs from the indescribable ideas you have about the world before proof and publishing.

Moroccan carpet seller

In Morocco. (It's tough to pick which ones to post -- I've got so many.)

Social Drinkers Earn More Money

Somewhat disturbing, but ringing true in a bunch of dimensions... This study shows that social drinkers earn more money than non-drinkers, and claims it's because of the increase in social capital gained by knocking one back with colleagues.

Although there is a united campaign to restrict alcohol, labor market data may surprise noneconomists: recent studies indicate that drinking and individual earnings are positively correlated. Instead of earning less money than nondrinkers, drinkers earn more. One explanation is that drinking improves physical health, which in turn affects earnings (Hamilton and Hamilton, 1997). We contend that there is an economic explanation. We hypothesize that drinking enhances social capital, which leads to superior market outcomes. Glaeser et al. (2000: 4) describe social capital as “a person's social characteristics, including social skills, charisma, and the size of his Rolodex, which enable him to reap market and nonmarket returns from interactions with others.” Some aspects of social capital might be innate, but people can enhance others, such as Rolodex size. If social drinking increases social capital, social drinking could also increase earnings. We attempt to test whether drinking enhances social capital by differentiating between social and nonsocial drinking; we predict that those who drink in public will have higher earnings than those who drink at home. New data confirm that drinkers earn more, and we find that social drinkers earn even more.

The article is here and comes with a somewhat scary libertarian slant intro, be warned:No Booze? You May Lose:Why Drinkers Earn More Money Than Nondrinkers (pdf). Note, this obviously supports the value of conference trip networking as important for career, if money is an indicator of career success (it is to some).

E3: Effective, Efficient, Elegant

Hi, my name is Lynn and I work all the time. Too much to post much these days.

But I had a nice break when I went to Infovis 2006, the symposium on information visualization. There was a bit too much math this year, starting from the keynote, which was Eades talking about graph layout algorithms. I still managed to get something thought-provoking from it. His criteria for algorithm evaluation was "effective, efficient, and elegant."

These are good principles for software design as well as algorithm design: a good piece of software should be effective at supporting the tasks it's designed for, be efficient in use and for use, and ideally is elegantly designed. Elegance, of course, implies more than "usability." Usability is a word that's got kind of an old school ugly lab study connotation these days; it's a word that doesn't say enough to capture current thinking about the value of delightful design, rather than just adequate design, in creating a differentiating user experience.

What's "elegant" in a proof or theorem, I asked of a friend who was a mathematician in his previous life. "Simple," was the first thing he said. But not just that -- it can be taught to a second year student, was one of Eades criteria (suggesting "learnability"). Yet also somehow "surprising." An elegant proof is a result with a twist you didn't see coming, but should have, adds an insight that makes it aesthetically pleasing.

At risk of triteness, I did look up elegance on dictionary.com after striking out in a Google search: "gracefully concise and simple; admirably succinct. Combining simplicity, power, and a certain ineffable grace of design." It adds:

The French aviator, adventurer, and author Antoine de Saint-Exup'ery, probably best known for his classic children's book "The Little Prince", was also an aircraft designer. He gave us perhaps the best definition of engineering elegance when he said "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."

E3 makes a good compound principle for evaluating design of all things, including software. I'd really like more elegance in my design.

10 most real life ghost photos (sic)

Ah, Pravda. It never fails to appear on the Anomalist. Here is a sample of photos of ghosts from the Russian online paper: 10 most real life ghost photos - Pravda.Ru.

Atlas Mountains at Sunset

One of my vacation nights involved a hike into the mountains.

Morocco, Atlas Mountains, October 2006

The Powerset Blogstorm

Can anyone beat Google? Well, the natural language processing community is having a go at it. I got back from 2 weeks of vacation to discover that an old friend and mentor from grad school days is now at startup Powerset, co-founded by Barney Pell, whom I knew as a grad student in Cambridge years before. There've been a rash of articles in the blogosphere about their announcements, as Barney summarises:

Barney Pell's Weblog: The Powerset Blogstorm: 1 week later.

Yet more evidence that startups are back and interesting again! And this time they want UX people earlier rather than later, which is a nice change for the industry.

Park near my house in Natick

Wetlands

Why Crunch Mode Doesn't Work

I have long been fascinated (and disgusted) by the lack of government, union, or HR care for the abuse of workers in the software industry. During the dot com era, I actually heard it touted as an intentional strategy by some Silicon Valley managers to hire young programmers right out of school who would work long hours for little pay and were considered "disposable." Mostly, they were disposed of, by burn out.

This attitude was reflected a little more indirectly in the cuts in benefits and pensions everywhere including major companies like AT&T, layoffs in which senior people were cut on the principle that they were easy to replace; among other people mismanagement decisions that seemed to me to be incalculably stupid. Incalculable, unfortunately, because the decisions and decisionmakers at these companies were protected by layers of indirection (about the reasoning, minimally) and because there is profound difficulty in measuring the damage to the company, products, and customers, both long and short term. Stupid, because the people in the trenches doing the work understood the impact every day, in terms of workload, quality of work, culture, their attachment to the company, belief in the industry and in what they were doing...

More than one person I knew who was young and abused in the dot com era decided they were "getting out," went to open a record store (or flower shop) and never looked at a computer again. In an era of declining enrollment in computer science programs, we as an industry can't really afford that.

Here's a guy in the game industry--one of the most famously abusive software sectors--trying to make the case with a fairly well-researched article on the subject: IGDA - Articles - Why Crunch Mode Doesn't Work: 6 Lessons. Tagline: There's a bottom-line reason most industries [except the software industry] gave up crunch mode over 75 years ago: It's the single most expensive way there is to get the work done. Of course, in the software industry, quality hasn't mattered that much, till recently. Will things change? Will software management change? Will the calculation become easier to make to argue against the stupid?

And here's an article, only tangentially related, but I think still related, on why America is lagging in R&D. The State of Research Isn't All That Grand. R&D is being outsourced, because it's cheaper that way; and R&D is "hard to measure" because it's a long-term investment. Most American companies aren't actually that good at long-term anything, in a profits-now-or-your-bonus-is-impacted business world.

Why hasn't Built to Last had more impact?

Birds at the Ren Faire in Carver, MA

Archimedes looking intense. RenFaire, MA, 06

Cheap Tickets

Over the weekend I caught up on Lifehacker, and found a bunch of posts and comment posts related to finding cheap airline tickets. Some were quite surprising to me -- like shop between 12 and 1am on Wed morning when companies update their records.

TripStalker -- a bot utility that continually looks for your best price and notifies you when it finds it.

Lifehacker thread of comments on this topic.

Another link collection on cheap ticket gimics.

Lots of people mentioned Sidestep (I use occasionally) and kayak.com, and travelocity doesn't fare too badly in the listings.

A fluffy photo post: Rabbits and Flickr Stuff

A friend sent me this link to some hilarious rabbit photos: My Rabbit Disapproves.

Just after laughing a lot at the justice in this woman's photo captions, I found this new flickr tool for browsing pic categories, which I spent a fair amount of time enjoying when I should have been driving to Nantucket. The search on bunnies turns up some really nice rabbit pics, not disapproving in the least. Cats are okay, but not as nice a collection. Gargoyles are a good contrast, and turn up a surprising number of cat pics. Or, perhaps not surprising, to a cat owner.

Flickr Storm.

Youth Hostel, Nantucket.

It's a good thing I'm not too old for youth hostels yet, or I would have missed this pretty building on the south side of the island.

Rusty Bench

Nantucket, MA

More on Skunk Works

Following up on yesterday's post, and pointed to some stuff by Steve C: some radically different skunk works innovation stories, with huge business success.

Firstly, the actual original Skunk Works at Lockheed, and a list of their principles for successful operation. A few of the more interesting ones, applicable to software:

The contractor must be delegated the authority to test their final product in flight. They can and must test it in the initial stages. If they don't, they rapidly lose their competency to design other vehicles.

There must be mutual trust between the military project organization and the contractor with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.

The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).

A very simple drawing and drawing release system with great flexibility for making changes must be provided.

The principles point to small, flexible, efficient, with well-understood budget and cost accounting procedures; and in sharp contrast to most other skunk works projects in software, blessed by directorial or higher level executive support who gives them autonomy.

Finally, I like this nice quote at the bottom of the principles list: "Reducing the time to evaluation of a system almost always leads to lower costs, greater flexibility for change, improved overall performance, and less risk."

For a sharp contrast, there's this classic and fun read on the creation of the Graphing Calculator at Apple by two unemployed guys who snuck into the building to work on it anyway. It reads like fiction, but you know it isn't. I admire them for their attitude towards teamwork and quality, if not corporate legality.

Next, we needed help writing software to draw the three-dimensional images that our software produced. A friend with expertise in this area took a weekend off from his startup company to write all of this software. He did in two days what would have taken me a month. My skunkworks project was beginning to look real with help from these professionals as well as others in graphic design, documentation, programming, mathematics, and user interface. The secret to programming is not intelligence, though of course that helps. It is not hard work or experience, though they help, too. The secret to programming is having smart friends.

They have a nice page of lessons learned from designing for the PowerPC, and it has a nice list of UCD items in it, as well as some smart observations on how to do screen-drawing behavioral things that are important to users rather than just clever or fast because they can be.

The goal is to maximize use of whatever processing power is available in the design of the user interface...

1. Tackle expensive computations when they can improve the interface.
2. Eliminate dialogs and command lines in favor of direct manipulation.
3. Drop old assumptions and idioms. Use the processing power to explore new interfaces.
4. Provide a starting point for exploration.
5. Avoid programming cleverness. Instead, assume a good compiler and write readable code.
6. Invest development time in user-centered design.
7. Learn the new rules for performance.
8. Design tiered functionality: take advantage of whatever hardware you're running on.
9. Test on real users.

I suppose one of the things I like about their story, apart from the lesson that "it takes a team of different skills to make something really good," is that they did a good root cause analysis of their success. You can't replicate what you don't understand. Although their motives in doing this while unemployed were admittedly murky to the end of the story. This kind of thing wouldn't have flown at Lockheed.

Finally, here's a link to an article on What Drives Innnovation (pdf) with some case studies and lessons learned. Their heuristic process to decide if an innovative idea is worthwhile for the business or executable inside a business culture is simple, but it's hard for me to figure out what to take from it... Despite the "possibly" and "no" frequency in some of the case studies, the idea was still successful. So, hmm. But worth a read.

Secrets of Great Teams

There are some nice short articles on teamwork in business at CNN's site for Fortune.

The top story, Why Dream Teams Fail, points out some of the failure modes also described in other resources on teamwork, but in somewhat different terms:

• Signing too many all-stars
• Failing to build a culture of trust
• Tolerating competing agendas
• Letting conflicts fester
• Hiding from the real issues

The most interesting notes in there were on the difficulty of finding dream executive teams, because as you climb the ladder, you're supposed to be an all-star. So of course there's less likelihood of collaboration and trust at that level. When there is, it's usually a pair consisting of one famous "outward-facing" figure, and a lesser known, internally focused-on-execution person.

The article on the Motorola RAZR is a little painful; it's another case of skunk works innovative design breaking corporate rules and even breaking human factors rules. The importance of risk-taking and mold-breaking comes up a lot in these kinds of business success tales.

A good sidebar piece looks at optimal size of teams: 4.6 people. Another one looks at the network of communication in an organization and how it differs from the org chart. You know I love anything that looks beyond the tree and makes networks:

Excel Tricks

Gotten off Information Aesthetics, and making my weekend a thing of beauty (well, also the good weather helps): Lightweight data exploration in Excel, from Juice Analytics.

This is so simple it's genius. I feel like a dork for never thinking of it. These are some lightweight way to create visuals like sparklines inside your Excel spreadsheet using really simple formulae. (This will be built-in in Office 12, but meanwhile, why wait?)

The bar graphs are built using the Excel REPT function which lets you repeat text a certain number of times. REPT looks like this:

=REPT(text,number_of_times)

For instance, REPT(”X”,10) gives you “XXXXXXXXXX”. REPT can also repeat a phrase; REPT(”Oh my goodness! “,3) gives “Oh my goodness! Oh my goodness! Oh my goodness! ”

For in-cell bar charts, the trick is to repeat a single bar “|”. When formatted in 8 point Arial font, single bars look like bar graphs. Here’s the formula behind the bars:

As the guy notes, when you're doing data exploration, you don't want to struggle to figure out which values created which outliers. Big plots are nice for an overview, but you still have to do work to figure out which items generated which points. ("Data brushing" is the common technique in infovis circles for getting this kind of info, but it's work to implement.) Why not get at what you want right in the spreadsheet itself, so you're looking at the data and the visual right at the same time? He has a good example showing the value of this in action.

The followup responses to his original post got even better. Check out these tricks to do this kind of stuff:

Updated to add: Here's even more fun off Juice! Tufte-style charts in Excel, with a downloadable file to play with.

Graves in the North End, Boston

Joanna Grant, Copps Hill, Boston

Here Lyeth

The Anomalist Roundup

Every weekend I love catching up on The Anomalist. Here are some picks from last weekend (that I never had time to post):

Here's a link to a strangely sincere article about recording things backwards and finding coherent messages (not just in trippy albums).

Shortly afterwards, my little hobby took a dramatic turn when I accidentally stumbled across the phenomenon in normal human speech. One of the first examples I found in speech was in Neil Armstrong’s famous first words as stepped onto the lunar surface. Forwards he says, “That’s one small step for man,” and when this same track is played backwards, the words “Man will space walk” can be clearly heard.

Suddenly my little hobby had turned into an obsession. I began taping as many people as often as I could and I found backward messages to be prolific, many of them as clear as the forward dialogue, occurring in grammatically correct sentences that often related to what was being said forward. I searched libraries and bookshops trying to find any other work on the subject and could find none. It then became obvious to me that this was a field that was totally new.

Uh huh. And here's a tangentially relevant piece on language oddity, a story of a feral girl who grew up with dogs in Ukraine. Like most stories of abandonned children, it's sad and disturbing. She's mentally handicapped. The worst part is how she treats her dog.

Here are three good pieces that collect strange stories. A piece from Pravda (unusually coherent for Pravda) on messages written in the sky throughout history; an article on sightings of flying people (without airplanes); and scary stories of Spring-Heeled Jack, a wacky killer ghost.

Finally from the land of dunes, King Tut's oldest gem may be from a meteor, because it's way too old; and sand dunes sing (sound snippets and article).

Puffin Pics Album

Finally, after about 15 years of missing the puffin season everywhere I travel (Scotland, Maine, UK...), I went on a special puffin trip to Nova Scotia. I got a few good pictures, although not many of them in flight, the classic silly puffin shot. Surprisingly, I like the water ones best!

Social Isolation Growing in U.S.

A much blogged social networking article: Social Isolation Growing in U.S., Study Says. Putnam's famous Bowling Alone was on this topic, and things have only gotten worse, apparently.

A quarter of Americans say they have no one with whom they can discuss personal troubles, more than double the number who were similarly isolated in 1985. Overall, the number of people Americans have in their closest circle of confidants has dropped from around three to about two. The comprehensive new study paints a sobering picture of an increasingly fragmented America, where intimate social ties -- once seen as an integral part of daily life and associated with a host of psychological and civic benefits -- are shrinking or nonexistent. In bad times, far more people appear to suffer alone. "That image of people on roofs after Katrina resonates with me, because those people did not know someone with a car," said Lynn Smith-Lovin, a Duke University sociologist who helped conduct the study. "There really is less of a safety net of close friends and confidants."

Barry Wellman, known for his studies of internet community networks, suggests that people have more diverse network connections and spread out their needs among different links. Hmm. I'm reminded of Oldenburg's Great Good Place, about the increasing lack of "third" places like bars or community centers, not work or home sites, in which people hang out and have social lives. Suburbia is particularly prone to this problem (except in NJ, where all the kids hang out and smoke at the all-night diners).

Some of the concerns this raises are that isolated people are more depressed, more prone to illness, potentially to crime...

Reforming Project Management

This is an excellent blog on project management and development: Reforming Project Management. It also, coincidentally, happens to be written by someone who works in the AEC industry (architecture, engineering, construction), which might interest some people I work with.

I like it because it has good stuff on quality (lots on Toyota right now), some good book pointers, and some nice commentary on methods in projects and leadership. I just read the entire current page of articles from the top down, without realizing I was still on the same site.

Hal's definition of project: "A project is a single-purpose network of commitments undertaken by a temporary social system."

Face it. Projects are temporary organizations. People come together on projects as strangers. We're not likely to change that. What we can do is make sure people share a context, have intentions that are aligned, and have a relationship that allows them to successfully coordinate action together.

And while I'm at it, this isn't at all a bad article on Dr. Dobbs about short-term-high-profile-crisis projects: Quick-Kill Project Management. The authors suggest 3 things are indispensable, for project success under really crappy crisis conditions:

• Vision and scope document
• Work breakdown structure
• Code review

Since Dobbs is a software journal, the insight into doing good work breakdowns and code reviews was useful even independent of the topic of crisis management.

Simple Names and the Stock Market

Not a result that will please some businessmen, but it seems that there is statistical evidence that companies with simpler names and/or companies with simple stock ticker symbols perform better on the market. Human processing may be the reason. Note, however, that it's not a sole predictor -- TiVO would have done better long term if it were, sigh.

In fact, across the entire NYSE and AMEX markets, Alter and Oppenheimer calculated $1000 invested in shares with pronounceable ticker codes would have netted $85.35 more profit after one day compared with an equal amount invested in companies with an unpronounceable ticker code.

Citation: BPS Research Digest: Why you should invest in shares with simple names.

Nova Scotia Animals Pics

A bunch of animal photos are up on this gallery.
It was a hot day -- so there are lots of sleepy, cuddly looking animals and only a few scary ones. Check out the bunnies, otters sleeping on their backs, porcupine draped over a tree branch, and fierce eagle in a kiddy pool.

This owl could be a muppet, but he's not -- he's real and he's just hot. I'm trying to get my pics from my recent vacation online in a web gallery, but it's taking the usual too-much-work...

Despair.com and Demotivation

I'm a big fan of despair.com. But handing out their posters could potentially get managers fired at the wrong companies-- maybe for the best! They've got other good products, including a funny book ("The Art of Demotivation"). I can think of a few people who need the pessimist's mug.

If you're having a bad day, I recommend their video podcasts. They will make you feel your life could be a lot worse. However, take care with the one on signs of a demotivated workforce. This one is on ZD Net, and the transcript lives here. It sounds a lot like the previous post I put up on "how to discourage innovation." An excerpt:

The fourth sign of a demotivated worker is acute defensiveness. As a result of their feeling defensive, they do extra work as a means of ingratiating themselves to executives. Now any time you can get an employee to do extra work, particularly for something as irrelevant as ingratiation, that's a good thing.

The fifth sign is employees feel acute self-doubt. As a result of their self-doubt, they will work very hard as a means of salvaging their identities.

The sixth sign of a demotivated workforce is the employees tend to feel a lack of emotional resilience. Now this is very important, because employees don't want to feel badly about themselves, and so consequently they will work extra hard to avoid humiliation. Though they tend to avoid seeking recognition, they will work very, very hard to avoid humiliation.

And then the seventh sign of a demotivated workforce is intense risk aversion. And this is very, very important, because employees are so unwilling to take any risks on their own, they will tend to be satisfied with simply being an extension of executive ambition. As a result of that, they will essentially do whatever you're asking for, and really that's what we're looking for.

Top ten tips for preventing innovation -Tyner Blain

Apropos the bad mood I have about innovation rhetoric: Top ten tips for preventing innovation by Tyner Blain. Gotten off Scott Berkun.

This funny but painful list covers:

• Hire employees looking for safety in their roles. Find people who primarily want security and a nine-to-five role, stay away from those troublemakers who want to “change the world.”
• Hire incompetent employees.
• Keep salaries below the 75th percentile. Innovators know their value - and when they aren’t applying for jobs with intrinsic utility to them, they are commanding higher salaries. If we keep our salaries low, there’s much less risk of one of these innovators sneaking into our organization. As a bonus, we’ll save a fortune!
• Treat employees like garbage. Yell at them. Whenever possible, call them at midnight to yell at them some more. They work for us. If they get uppity, make them work on the weekends. Make them dig holes and fill them back up again. Threaten them - especially when they need the job. If you can’t yell, at least be condescending in public forums. Remember we are smarter than they are. Punks.
• Reward conservative and marginal successes. The old rule of thumb for office politics was “It takes ten good projects to recover from one bad project.” Stick to it! If we punish people for mistakes when they ’swing for the fences’, and reward them for marginal and safe projects, they will quickly get the idea. This is the most subtle of all the tips - but don’t worry - people will figure out the reward system and shy away from those risky projects. This technique has the added benefit of propogating itself up and down the management hierarchy.
• Micromanage. We’ve been promoted because we understand their jobs so well that we could do them in our sleep. Whatever those pesky little people think, it’s wrong.
• Only create customer-requested features. Let our customers tell us what to do. ... Oh - and don’t second guess the customer. If they say they want the menu items in alphabetical order, well, that’s what they want. The customer is always right. If Henry Ford had listened, think of how fast horses would be today. Even better, appoint a user-representative, then we don’t have to talk to the customers at all.
• Build a kingdom. When we have information, that means we have power. With that power, we can grow our organization. The more people we have, the more important we are. We need to make sure that those other teams don’t get our information. They might apply it in ways that we didn’t intend. While we’re at it - make sure our people don’t find out what we know. Not only will it protect us from them, but it will keep them from accidentally discovering a more important problem, or an alternate way to apply what they already know to a new problem domain.

It's an excellent list.

Business Innovation & Design on BusinessWeek

There's a new portal site with articles on Business Innovation and Design at BusinessWeek Online.

I'm trying not to be in a bad mood about the rhetoric around innovation right now. One of my favorite industry commentators, Scott Berkun, is writing his next book on innovation, and innovation has somehow gotten nicely linked with the concept of design, "user experience," and good customer research. There's an article on ethnography's role in market research on the new portal site (The Science of Desire). Google claims in its recent job ads that one of their core philosophies is "Focus on the user, and all else will follow." eBay claims in its last job ad for a UI designer that the position involves "contributing to a culture of innovation and teamwork."

It all sounds like Mom and apple pie, but the truth is it's oversugared store bought corporate pie, not the kind you want to get from your own oven. The truth is that innovation on the job isn't what most managers can handle or want to see because it's disruptive, and management is hard enough without people being creative right and left while you have schedules to meet. (Er, but not me. Did I say I'm hiring? And to be fair, this report by Donna Bear does point out the difficulties inherent for management execution of the innovation goal.) But, clearly, innovation and good design don't necessarily run together at all times.

Google is an excellent case in point. It's foolish to conflate the new, different, and envelope-pushing with stuff my parents will understand, if they make a good yardstick. Flickr doesn't yet pass the parent test for me. Yes, I know that Yahoo -- with a better history and culture of usability than Google -- owns them now. But that fact also gives me hope that one day Flickr will really work for my photoblogging needs. Google's eternal early-launch betas with iffy design and functional incompleteness aren't yet professional caliber user experience, no matter what they claim in their job ads. And I think the stock market forgives them and even celebrates it, which goes a ways to explain my bad mood. Gmail is incomprehensible to my massage therapist who doesn't understand the difference between what's on her hard drive and what's in her email. It's undoubtedly different -- hence "innovative" -- but is it too different for ordinary people to use? Perhaps.

My massage therapist does not care about Google Earth, incidentally.

eBay. Many of their UI designers (and other customer-focused staff) are now bailing for new gigs; what does this say about their culture of "innovation" for designers?

Finally, what does it mean as a company to say you are focused on customers and design, but to employ no researchers with social science background or designers who are non-technical? Where is the diversity that leads to true creativity? I've seen this at a number of companies, of course.

Remember when the major R&D labs shut down or radically downsized in the late 1990's? I don't see enormous evidence of a change of heart, apart from perhaps the new Yahoo Labs. I have friends at other research labs that are feeling underappreciated, underpaid, actually bored, and are looking around now; some of those labs are profiled on the innovation portal.

It's not very convincing, is it, even if you want to believe. Ethnographies of companies that claim to be doing ethnography, or more mundanely, claim to be promoting "innovation" and/or claim to be focused on design and customers, could be damning. Business hype is easy, execution is a different thing.

Daily Hassles

I've been tracking my time, in part because we were asked to (for budgeting better on the next release cycle) and in part because I just love the data-centered view of the world. Buried in the details of everyday life, we don't see the big picture, and this kind of time tracking exercise helps. (God forbid I do it for my non-work life, that would provide a level of big picture insight I don't feel prepared for right now.)

A while ago there was a small kerfuffle on the 37signals blog about the uselessness of meetings -- the gist of the post from the ballsy, tiny small startup was "meetings are a waste of time, just get down to doing the work." This caused the usual response from the less big-mouthed, possibly more mature crowd of readers with experience at larger companies or on more software teams: "Not all meetings are a waste of time, and maybe you guys are a special case in some ways." I was one of the readers who was irritable, because I genuinely believe that without meeting-time, we can't produce coordinated design work on complex products and we can waste a huge amount of time in email (delaying critical work) and acting on poor or poorly understood information. Project risk increases without meetings as a forum to be sure everyone understands what's going on and what's next.

That said, I do believe there are inefficient meetings, and teams that revisit decisions made in meetings undermine meeting usefulness; and meetings that go badly have the ability to damage relationships and project work as much as they could have improved things and made projects more likely to be successful. To add to the list of my many opinions on this topic, meetings are a place -- sometimes the only place, which is worrying in itself -- for necessary social chitchat interactions (on the meeting margins) as much as for making project progess, and folks who don't care about that aspect of face-time are more likely to have meetings that go bad and cause project damage.

But I went off and did some research on the topic of meetings and stress and found this article: Meetings and More Meetings: The Relationship Between Meeting Load and the Daily Well-Being of Employees (pdf, Luong and Rogelberg).

Defined in the stress research literature as “annoying episodes in which daily tasks become more difficult or demanding than anticipated,” hassles have been found to predict stress symptoms better than most other predictor variables (Zohar, 1999, p. 265). Varying from equipment malfunction to inappropriate behavior of coworkers (Zohar, 1999), such obstacles predict an array of stress-related effects, including burnout (Zohar, 1997), anxiety, depression, and other negative emotions (Koch, Tung, Gmelch, & Swent, 1982; Motowidlo, Packard, & Manning, 1986).

More or less, one of the article's findings is that meetings annoy people because they aren't seem as a goal in themselves, they're a necessary evil that's often, in poor cultures, really evil in practice. They are seen as hassles, instead of work in themselves.

Digression: I remember a friend, on moving from engineering management in which he still wrote code to higher level strategic management, having the realization that meetings weren't getting in the way of work, but instead, "Meetings ARE my job now!" I also remember a developer at Adobe realizing that the number of meetings my UI colleague and I had to have with his project team to move that design forward were the tip of the iceberg in our lives; you effectively multiplied those meetings times the number of projects we were assigned to, to reach the total of some ridiculous number of meetings we were responsible for calling, preparing for, and documenting afterwards in order to produce specs, which was our perceived "real" job. We were always borderline psycho, of course, in a constant state of frenzied stress, prone to freaking out if a pen ran out mid-use or the video conference system needed rebooting and we lost 10 minutes of meeting time.

But back to the above quote. Say meetings are a necessary evil, and viewed in a better light, a significant part of work in themselves rather than a blockage to doing "real work." Then, maybe the other hassles in our workday that are genuinely just hassles rather than misunderstood work might be "fixable." Like the bad pens and video systems.

In one of my favorite books, Management of the Absurd, Farson cites Maslow on the hierarchy of grumbles in organizations. The gist is that people always complain -- it's a human fact -- but the category of complaints is significant. Grumbles about equipment, the "hassles" of the above quote, are the most worrying, because they mean that low-level needs aren't even being taken care of. Hassles that interfere with the "real" work add significant stress, and are invisible to many managers. These could be the equivalent of the food and safety level of office needs. (Admittedly, the threat of arbitrary job loss is something that's a bit more "safety" related and counts as more than a "hassle." So my parallel may not be entirely fair here...)

Farson says that a better company will have people complaining about higher order issues like the source of credit for work, whether there is truth and justice in the office, about the opportunity for creativity and self-expression on the job.

Everyone is working at capacity these days, it seems. But folks who are most stressed may be stressed because of too many daily little hassles. I'd put on the hassle list the inability to schedule a meeting room, or frequently-used intranet software that fails 50% of the time because of a server issue that hasn't been taken care of. People who are already working at capacity are especially prone to not coping well with the little hassles -- but they are actually a lot more fixable than the higher order issues people face at higher order companies. So I guess there's some good news if you go looking deeper at the sources of workplace stress.

(Here's another citation from Zohar's work on work stressors: "When things go wrong: The effect of daily work hassles on effort, exertion and negative mood" (pdf).)

I found a turtle in my backyard today! He scurried away, slowly.

Critical dragonfly, Garden in the Woods, Framingham MA

Jobs on BayCHI

This weekend, Don Ahrens announced that he wouldn't be posting the BayCHI job list anymore. This important job listing is on hiatus till another owner can be found and trained.

It's easy to say Don did the user experience profession a great service with this list, but it's very hard to imagine where some of us would be without it. The BayCHI chapter of the Special Interest Group of Human Computer Interaction (SigCHI) is a major force for professional good, offering great talks by industry stars and important networking opportunities. (I just looked at their page and discovered that a friend from the UK whom I haven't seen in 10 years is speaking this month, and I'm missing it!) The Bay Area is the spiritual home for user experience professionals, rivaled only by some odd corners of Scandinavia. That job list, to which many non-locals subscribe, is one of the best ways to track industry opportunities in interaction design and usability. Watching that list gives one important insights into what's going on at major software companies. Jobs outside the Bay Area are regularly posted there, because of its large readership and the recruiting pool that exists in the Bay Area. I myself have been reading it since grad school.

In honor of Don's tenure (how long HAS it been? I can't remember when he didn't run it!) I've made a few retrospective graphs of the job list contents from 2003 to 2006.

Unsurprisingly, the growth of the stock market matches the growth in the raw number of job postings appearing on the baychi list. We're averaging around 70 to 90 jobs every weekend right now, incidentally. This picture shows the raw counts of job posts overlaid on the percentage growth of the NASDAQ.

If we look at the actual companies posting jobs, it gets more interesting. By raw counts, you see some of the big tech names you'd expect to see.

Check out the major players in user experience on the left edge.

Now, these are dumb data points -- we know nothing about actual filling of positions, or how many times a job was reposted or how many positions each posting represented. One major caveat there: the Google NY jobs have been open for almost a year, I think, without disappearing, so this is inflating some of their stats. The Trend Micro positions in East Asia were likewise open forever.

Regardless of the potentially misleading nature of these numbers, the stats do get more interesting when you compare the size of the company with the number of UX jobs posted on the baychi list. For the public companies that I could track down, I resorted by the higher ratios, and this shifts the list tremendously. Microsoft, for instance, falls way back down, as does Oracle.

As a former TiVo employee, I am not surprised to see them leading the pack (even when I know that their numbers are probably inflated by difficulty of hiring, and recent departures of key folks -- but then, everyone has this problem, right?). More interestingly, Shutterfly comes in second now. Shutterfly is where my former UX Director from TiVo, Kyrie Robinson, landed post-TiVo departure. Ah, suddenly not so surprising to see Shutterfly second to TiVo. (She has just left Shutterfly to take a VP role elsewhere with the words "User Experience" in the title, a rather rare position name.)

Now, what jobs are being posted? Simple word frequency on the titles shows us an interesting pattern...

Senior interface designers top the most wanted (or bottom, in this graph). Usability and user research positions trail rather in comparison. This is actually a nice trend for the industry, since Don Norman noted a few years ago that "design is where the action is." As a hiring manager seeking senior UI designers, their popularity is bad news for me; it's very, very hard to hire them. There aren't enough, and they're clearly in high demand.

From the founder of Motek

A couple of months ago I posted about Motek, a woman-owned company offering sufficient vacation days to let employees come back to work enthusiastic, practicing enlightened management policies that secure quality of life on the job, not just despite the job, like most companies.

I received a number of interesting comments on that post, one of them from the founder. The authors of Peopleware would pretty much agree with Ann Price, I think. I snip here, since summer is a good time for a reminder about big life lessons.

I'm honored by your blog. Motek’s a small company making a difference in an ominous world that left millions behind. While Microsoft creates more software for the desktop we give computers to the desk-less. We automate places still using paper & pencil to track inventory. In case you're wondering that's 85% of the nation's warehouses.

Along the way we try to improve the quality of people’s lives by shunning sweatshop environments that expect people to work nights and weekends. Our product enables companies to get more done than they did before so they can eliminate overtime. This delivers cost savings for our customers and quality of life for their employees.

...I started taking 1 month vacations when I was 22 year old GE software consultant. No, GE's vacation policy didn't accommodate me. As an employee who'd only been there 1 year I was given 1 week off. So I told my manager I needed to take 4 weeks off for personal reasons but never provided details. I didn't care if he thought I had breast cancer or a death in the family as long as he understood it was non-negotiable. Sure it was gutsy, but the lesson was invaluable. I learned I could do it. I learned I could live by my own rules and have done so ever since.

Anyone waiting for their employer to enable them to live is missing the point. Try to understand. You don't look the same on the beach in your 40's. You don't feel like climbing the steps at Machu Pichu at 35. As I tell all Motek employees: the time to go is now. Once people realize their employer isn’t the obstacle money comes up. People inevitably say they can’t afford to take a month off. When I was 22 I didn’t have any money either. And back then (20 years ago) there were no frequent flier miles on credit cards. I found a book called Air Courier Bargains. Yes I actually flew as an air courier to Asia. Even though I can afford to fly anywhere I want these days I still put every expense I can on my credit cards to accumulate miles. You can pay your electric bill and mortgage on a credit card today. I always have enough miles to travel and get away. I believe strongly in recharging your batteries and although I spend 3 weeks a year on vacation with my husband I always start or end my trips by spending at least 1 week all alone.

Yes, I’m passionate about this topic. I truly believe all my other business ideas have come from my ability to step away from work and think about how I want to work. Success is 1% inspiration and 99% perspiration. Without the inspiration you may be working hard but not necessarily smart.

Design Success Factors

About six months ago I was interviewed as a followup to a survey I had answered about factors that influence successful adoption of design and usability practices in the corporate world. The survey ended with a writein box asking for the most important factor, and I was unable to write just one. The phone interviewer wanted me to pick a single response from my two, and I still can't; in fact, I'd add a third.

Executive Support, or more generically, management support up the ladder to the top. There are subcategories on this one, of course, because support manifests in different ways as needed and where needed. The most important is in recognizing the need for design as a value of the company, and investing in it. This means funding the right teams and instigating the right processes to allow it to happen. "Processes" are a bit vague as a concept, but essentially entails setting up a context in which "design is being done by the designers," i.e., they are enabled to do it, and other people who want to do it or aren't skilled at it are disabled from doing it. Of course, this cashes out in the daily nitty gritty of development meetings in which everyone may have an opinion about design (they will), where there must be a culture and a recognition of the fact that someone in the room has a better track record at being right in their judgments. Even if they make it look trivial and easy. In fact, especially if it looks trivial and easy.

Hiring well is the second factor, most important when you are trying to make the case for good design in a culture-change way (a pretty common experience for most of us, although getting less common, thankfully). I used to think this was a matter of just finding good designers, but that's only a small part of it. You also have to hire people who can work with good designers, which is not usually a factor considered by hiring managers in the rest of the organization. The more design "thinking" pervades the culture (from management messaging) the likelier it will subtly influence hiring in the non-designer roles, I believe. (Trivially, for instance, it's less likely that a product manager or engineer will be hired on the grounds that they are also "good at making icons" if there is someone on staff understood to handle that job already.) There are a lot of other personality and skill factors that influence doing successful design work, though. During the hands-on, day-to-day interactions in which design discussions happen and decisions are made to do one thing or another, the person on the ground has to be able to deliver when the context is good in which to produce and other people are listening.

(Hiring good designers is shockingly hard. Most UI designers can only list a handful of others they think are good. The "why" of that is another topic.)

The third item I'd add, which may seem obvious, is Development of good designs must be possible. This could conceivably fall under the management of processes, but I think it's worth calling out as a first class item. It does you no good to have designers who are good in a company that theoretically wants good design to happen, if there is no way to execute technically. The code itself and the timetables for work must allow design to be implemented; not just features, but designed features. I think Don Norman has a riff on this somewhere, and I know people who live in UI standards "police" roles wrestle with it all the time -- the toolkits used should enforce easy compliance with standards, not make it hard to honor them, etc.

And that's my third, for this six months of reflecting on the professional topic I care most about.

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.