Pixar on Successful Creative Teams

I've seen this on a number of sites now, but it's rich enough to keep passing on. Requiring payment from HBR, the article is How Pixar Fosters Collective Creativity, by Ed Catmull. Some of his points are business management truisms or even cliches, but as with most management-related things, it's not the concept that's tough, it's execution that's tough. Especially in a creative environment.

On People. Most of his points here are about handling diversity and collecting lots of input from lots of sources. Less dictatorial hierarchy, more feedback and empowerment of teams to decide how to handle the feedback. Some good quotes:

• "If you want to be original, you have to accept the uncertainty, even when it’s uncomfortable, and have the capability to recover when your organization takes a big risk and fails. What’s the key to being able to recover? Talented people!"
• Creativity isn't about finding one big good idea. "However, in film making and many other kinds of complex product development, creativity involves a large number of people from different disciplines working effectively together to solve a great many problems."
• And yet, talent isn't evenly distributed, he acknowledges. But this does not mean anyone tells anyone else what to do - a creative team gets input and makes its own decisions about what to do with it. A "brain trust" of the truly excellent people with track records can be called on for input when teams need help, but they don't dictate anything. Ironically, this frees everyone up to talk and listen more effectively.
• Having talent on staff isn't enough. "What’s equally tough, of course, is getting talented people to work effectively with one another.That takes trust and respect, which we as managers can’t mandate; they must be earned over time." If people trust each other, they can be less polite in meetings, apparently. Ideas are under discussion, not personal status and power.
• "An important lesson about the primacy of people over ideas: If you give a good idea to a mediocre team, they will screw it up; if you give a mediocre idea to a great team, they will either fix it or throw it away and come up with something that works." I note, they can only do the latter if they are given the freedom and authority to do something radical.
• Pixar's "small incubation teams" that consist of a director, a writer, an artist, and storyboard folks. Whereas in my experience most software incubation project teams are weak on the creative staffing and very heavy on the implementation side, not a good balance of skills for the stages of creation.
• It's critical for an incubation team to function well internally: "During this incubation stage, you can’t judge teams by the material they’re producing because it’s so rough—there are many problems and open questions. But you can assess whether the teams’ social dynamics are healthy and whether the teams are solving problems and making progress. Both the senior management and the development department are responsible for seeing to it that the teams function well." I note: presumably there are non-subjective, non-gossipy ways to evaluate social dynamics. I've seen this rhetoric applied to very bad ends at one company.
• Catmull says, "Treating one another as peers is just as important as getting people within disciplines to do so. But it’s much harder. Barriers include the natural class structures that arise in organizations: There always seems to be one function that considers itself and is perceived by others to be the one the organization values the most." Overcoming that is a huge management and process challenge... Catmull seems to be saying that time together helps, but I think the deliberate creation of well-rounded incubation teams is a big aid in changing these biases. None of this "we'll add a user interface designer later" stuff, like you hear from the software company incubation teams!
• Newcomers to an organization can be threatening, because of the "not invented here" syndrome that they may cause with their new ideas. But constant change, not taking success for granted, and acknowledgment of mistakes made can make newcomers less threatening to current employees, he says.

On Processes. So they've got a good staff who encompass both technical and creative backgrounds, now how do they keep it all working and on track?

• Dailies are watched, by lots of people (the animation industry version of footage of the day). Sharing unfinished work and inviting comment helps creatives get over the fear of showing the incomplete, and that in turn means work isn't wasted if it's on the wrong track. I note, a healthy culture of regular software design critique does not exist in most software companies (barriers to this are a political subject for another time). Agile development processes seem to be better off in this regard than waterfall-like models of development: producing and showing in-progress work is critical in that methodology.
• Input on work-in-progress is collected widely, because the work needs to be great before release to the real world. TiVo executed on this principle when I worked there, too; employees all used the beta software at home and we had to like it, too.
• Post-mortems are done regularly. Rather than just "what went well and what didn't go well," his suggestions include having groups list the top 5 things they'd do again, and the top 5 they wouldn't do again. Now, in a creative environment, people often assume that you can't evaluate the creative process. But Pixar uses data to ground the post-mortems (making me wonder how they track it, who does the analysis, etc). "Most of our processes involve activities and deliverables that can be quantified. We keep track of the rates at which things happen, how often something has to be reworked, whether a piece of work was completely finished or not when it was sent to another department, and so on. Data can show things in a neutral way, which can stimulate discussion and challenge assumptions arising from personal impressions." The fact of being "neutral" prior to interpretation is important, from my perspective. Using data in a post-mortem shouldn't lead to finger-pointing so much as conversation about root causes for data peaks and valleys.
• Management challenge for their corporate processes: "Clear values, constant communication [across and around hierarchy], routine postmortems, and the regular injection of outsiders who will challenge the status quo aren’t enough. Strong leadership is also essential—to make sure people don’t pay lip service to the values, tune out the communications, game the processes, and automatically discount newcomers’ observations and suggestions." And I say: Easier to say than to execute. Leadership is so rarely evaluated well, at any company.
• Catmull says they keep up with academic research. Being cutting edge means staying on the bleeding edge, and being able to attract people who want to work on that edge, too. Why do so many companies sneer at research and research conferences?

It's a good article, and I think worth the $6 cost. It does leave a few questions I had unanswered, like how they handled the massive overtime and repetitive stress injuries he describes during one "failure recovery" period.

As a final point, something I've said here before: Post mortems may be unpleasant, but understanding how a team was successful is just as important, or more so, than understanding how it made mistakes. I don't think most companies use the positive particularly well in setting up their downstream teams. I think Pixar probably does, to have such a string of successes.

Good UX from Happy Employees?

More on creating good user experience from good organizations: a short blog post by Adam Richardson at CNET entitled "Good user experience comes from good employee experience." He points out comments from airlines with happy employees who convey happiness to their customers, like SouthWest and JetBlue, as opposed to American and other airlines with rather surly, unhappy employees.

Over the years, whenever reporters would ask him the secret to Southwest's success, Mr. Kelleher had a stock response. "You have to treat your employees like customers," he told Fortune in 2001. "When you treat them right, then they will treat your outside customers right. That has been a powerful competitive weapon for us."...

"There isn't any customer satisfaction without employee satisfaction," said Gordon Bethune, the former chief executive of Continental Airlines, and an old friend of Mr. Kelleher's. "He recognized that good employee relations would affect the bottom line. He knew that having employees who wanted to do a good job would drive revenue and lower costs."

I've worked at more than my share of offices in the past dozen years, and I think there may be something in this. Watch out if you've got customer-facing employees who don't answer internal colleague emails, are rude or curt to peers in their organization, promise stuff but don't deliver, hold onto information for their own advancement rather than the sake of the team. You probably also have a customer relations problem at the very least. Is this person answering customer email or calls politely? Sharing customer problems with other people who can help? Looking for help in solving the problems that the customer has?

Then look at the tools your employees have to use... if you find crappy tools in use internally, then double check that this isn't exposed to customers in some form. The MathWorks has an internal usability group that works on design and development processes for corporate tools. I think it pays off in many ways, not all of them related to internal efficiency. It's a sign of respect for your staff to give them the best tools to work with.

If you hire well, trust your employees, and give them a reasonable job to do, they can be your strongest advocates for hiring, referrals, and posting nicely about you in their blogs! And they'll go the extra mile on the job. Besides, a lot of your employees, past and future, are customers too.

Staffing for User Experience: What Can Go Wrong

You decided to hire a bunch of interaction designers and "user experience" people to improve your product, service, or general business from a customer-focused design perspective. You were lucky enough to find some experienced folks, who've proven their worth at other companies.

It may not be obvious, even if you hired evangelists to help convince the rest of the company of their value, how many ways you can still get it wrong AFTER the hiring. It takes more than headcount! Your new people need to be empowered to make a difference on the product. The issues below amount to (a) cultural and process openness around adding more design into the team software mix, (b) how the dynamics of decision making in your company can impact design for evil rather than improvement.

1. Did you hire the right people? Let's assume you did, but a couple reminders here: Your biases and your interviewer biases may be some of the problem you are actually hoping to solve. Did you hire looking for collaborative people who get along with everyone (and cave in an argument, in order to preserve the peace?). Did you hire people who do evaluation of other people's designs, or did you hire designers? Did you hire GOOD designers? (Would you know how to evaluate their design skills?) What kind of power dynamics are going on with the interviewers you lined up: Are any of them threatened by the whole idea of outside new people influencing the product? Are they looking for "yes" people or new ideas? Remember they may say something quite different from what they really secretly feel after 3 beers.
2. Does anyone other than development or product management get a say in how things turn out? How much will these expert new hires be heard? A development manager who is used to being in control may not like having to invite someone new to his planning meetings; a product manager may be unhappy if your new hire questions her market research based on usability data. How much of the time will your new staff be looking for data and ways to convince people to listen, versus actually making an impact on the product? If you had to hire evangelists, you're set up for this problem from the start - expect a lot less productive impact on the product from your new hires, and a lot more organizational time suckage.
3. Do you have ugly cultural problems you don't know about: Prejudice against non-"technical" input, assumptions that women aren't as smart or good at software or technical decisions. Women are more likely in UX/design than they are in engineering jobs, even if they started in development positions. Check out the dynamics at the whiteboard here, a scene I've watched many times...
4. Will other people take UX team work as optional input to modify, redo, ignore? Does someone else secretly want their job; not realize it's a separate real job in the process; or actually HAVE their job on the project. I've seen teams where two people were meant to be the customer design input, and didn't agree, and it led to time-wasting fights for the whole group around them, with people taking sides on issues and duplicate work being done. I've seen plenty of QA teams forgetting about the spec, developers not reading or forgetting about the details, and other errors of omission that prevent design from being fully effective.
5. Do you have decision processes that are functional in your company - or do you regularly have meetings that bog down with "votes" or too many inputs, and open more issues than they close on a regular basis? This environment won't scale well to adding players especially in design discussions. (If your team is arguing with the designer about whether to use radio buttons or checkboxes, you have a dysfunctional decision process which means you are wasting resources and time.)
6. Is there enough time in your shipping cycle to actually add design as a separate process? Not a trivial question to laugh off; mistakes made early, in requirements and design, are much easier to fix than anything after some code has been written, assuming you have processes in place to catch them before you get too far. This well-known fact doesn't make most companies happier to slow down. I think it has something to do with what's seen as "progress" and "work" in the development cycle, and the glorification of risk-taking that exists in so many software companies that have money to burn.
7. Does your company regularly bite off bigger projects than it can deliver in a release cycle? These giant projects are unlikely to be high quality when they ship after all the cuts and compromises are made to squeeze them in. Partial functionality is usually worse than no functionality because your company looks like it just didn't get what the customers were asking for. No UX person can entirely save you from this, but a good one consulted and involved in the process from the start might keep you focused on the must-haves for minimal usefulness.
8. Have you got project management to track team issues and milestones and make sure things aren't grinding down to a halt, or loaded with bugs and unresolved issues. Are they also concerned about tracking design stages, and blocks to those deliverables, rather than just safeguarding developer efforts? (Before you say "of course," maybe you should check with the designers.) These things can add up and make everyone less useful in the end; software is a team effort.
9. What will you do with the designs your designers produce -- they can make mockups till the cows of management come home from their offsite, but that doesn't mean it's useful in your process.
10. Do you have your new UX people spread too thinly to be effective -- with an average of 20 developers to one designer (who is shared over multiple projects), there will be a large number of meetings they miss; bugs they don't have time to provide input on; bugs they don't have time to file; builds or releases they didn't get to see closely enough to catch last minute errors; bug review sessions they weren't at to push for the usability/experience bugs; doc they didn't look at to see if it covers the main use cases and important details; customers they didn't have time to call or visit. And spec modifications they couldn't keep up to date. Their morale will suffer proportionally to the things they don't have time to do that decrease their effectiveness.
11. Is the UX person involved early enough to be (a) able to influence the crucial early decisions (b) and to be a true team player in the project, rather than an end-game consultant check-mark on your process? It's often in an overloaded (dysfunctional) environment that the designer or usability specialist is involved only at the end of the cycle to "review" and "bless" things. If you're tired of hearing from your new hires that they didn't know something had been decided, or that they wish they'd been consulted earlier, then you've got this problem headed your way. Remember it's much harder to effect change after code is written! And they want to be able to make an impact, otherwise they will be wasting their skills.

There are lots of ways to miss, even with good staff. I've been in good teams and bad teams for design process, but seen a lot of these failure modes. I'm keeping score of how many companies have teams that argue with their designer about radio buttons versus checkboxes, wasting valuable time in their cycle. The stats aren't looking good. But if you take care of your processes and oversee design as a separate stage and responsibility, your company can be better than that.

Let Your Designers Design!

We all know now that good design is a crucial element in a crowded market. But just because people in your company have strong feelings about design, doesn't make them good at it. Some of their ideas may be good, but that doesn't make them good at executing either. In the worst cases, they both think they have good ideas and think they can execute, and they can do neither. (Remember, incompetent people don't know they are incompetent.)

Signs of the problem in your org:

1. You have designers on staff, but they're demoralized and frustrated. Designers are a special breed of person, more likely to leave when they can't accomplish what makes them tick than many others; they're driven by their skills and talents more than promotion opportunity inside a company or a domain in which they work.
2. Consensus-driven culture has ground projects to a halt. You can't break out of decision-making meetings with a clear goal, and there are too many cooks involved. Because the designers aren't empowered to make the final design decision, and other (incompetent) people are weighing in or fighting with them. (See Scott Berkun's recent take on this, and an old take on why products don't end up usable that covers all this organizational stuff too.)
3. You may have a lipservice executive level belief in design as important (ever since Apple made it profitable), but you have no headcount for it, and no org process for it. There are no goals in the marketing pipeline that focus on it, there are no metrics to measure it, and it's no one department or person's job. It's handled diffusely, and not managed effectively.
4. Secretly, you or other middle-level managers think design is a technical thing, or the "fun" part for the technical folks, and it's best handled by developers as a kind of prize for the good ones. Don't bother trying to hire in this climate!
5. Final decisions about what gets in the product and what's shippable are based on criteria or opinions that don't know much about how customers respond to your stuff. Bugs that in a one-in-a-million system configuration cause a crash are prioritized about correcting a layout problem that makes you look amateurish, or a typo that makes you look like a busload of idiots.
6. You think it's all about the documentation - the customers just need to read more.
7. You outsource all of your visual design, and that's what you mean by "design" anyway.
8. You didn't realize people get degrees today in usability, human factors, interface design, interactive design, etc. In these degree programs they learn the correct ways to collect and interpret data, deliverables that communicate at different levels of fidelity, how to go from abstract to concrete, how to validate designs, and how to prototype. Corollary: You also think design is work that's "obvious" and easy, probably also because it doesn't involve writing (much) code.
9. You don't have actual project managers on your staff. You make it someone else's job, usually a development manager's; this means design as a phase and design deliverables are not scheduled and monitored in the way that code production is. Instead, it's all "where's that damn spec, we need to start making this thing."
10. Your designers are actually trying to steal the project management, so they can get some control over the process, but this is leaving them too busy to actually do design. They schedule meetings to get stakeholders together, they try to get the PM's to articulate what the heck the requirements are, they hire visual designers, they call customers... they never actually get to design, except after hours.
11. You've got innovation projects going on in your company, but there aren't any designers working on getting things right from the start. (Chances are, they are too busy with 9 and 10 to be contributing even if invited.) But basically you feel that design is "icing" to make it look pretty after the big ideas are implemented. You think the real breakthroughs come from technical ideas, not ideas that come from watching people work or new interaction techniques or novel workflows. Never mind how expensive it is to get requirements wrong up front and have to "fix" things later. (There are any number of software studies on this, drop me a note if you want refs. I've seen startups go under from this, before they even got out the door with their product.)
12. You've got internal folks like usability testers who are told they "facilitate" group processes but aren't empowered or able to make overruling design decisions. This is explicit support for consensus design or committee design, dangerous when everyone else is opinionated but incompetent.

Okay, I admit it felt good to get this list off my chest today. It's not the last time you'll see the subject cross this page. Let's hear it for design moving up the org chart; and for middle management and technical management understanding there are skills that might help with product big picture and end-game success!

Open Source vs. Organizational Code

An interesting, free article from Harvard Business School working papers: Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis (scroll down for PDF link). From the abstract:

Specifically, products are often said to "mirror" the architectures of the organizations from which they come. Such a link, if confirmed empirically, would be important, given that product architecture has been shown to be an important predictor of, among other things: product performance; product variety; process flexibility; and future industry evolution. We explore this relationship in the software industry by use of a technique called Design Structure Matrices (DSMs), which allows us to visualize the architectures of different software products and to calculate metrics to compare their levels of modularity. We use DSMs to analyze a number of matched-pair products--products that fulfill the same function but that have been developed via contrasting modes of organization; specifically, closed-source (or proprietary) versus open-source (or distributed) development. Our results reveal significant differences in modularity, consistent with a view that distributed teams tend to develop more modular products. We conclude by highlighting some implications of this result and assessing how future work in this field should proceed, based upon these first steps in measuring "design."

I've seen work on this subject before (including similar diagrams that show code module relationships)-- not usually in business press, although it's nice to see this get a wide audience. Recently I read Becky Grinter's essay in HCI Remixed which reflects on Parnas 1972's "On the Criteria to Be Used in Decomposing Systems into Modules" and on Conway's Law: The structure of the code mirrors the communication of the organization that developed it. Or lack thereof.

More than that, I'd say the UI design and the broader corporate outside facing design often reflects the organization's internal structure and different goals. Marketing groups that don't talk to engineers, executives who don't get along, customer support and sales who don't speak -- these things all hit heavily on the face that a customer sees for the company. All of which can be reasons why "User Experience" as a group can't live low-down in any one part of a company, especially a big one.

More personally, I've started using R, an open-source competitor to MATLAB, and wondering about this stuff as I try to track down the open-source resources I need. I've been enjoying ramping up on R despite finding the documentation available and code quality of some libraries very hit-or-miss. MathWorks's doc team and their demos are one of their strengths. Regardless, R has a growing number of books and sites, and I've learned some simple concepts faster in R than I ever did for the same concepts in M-code. In many ways, I prefer the language to M, despite my belief that open-source usability is generally very poor [here we might have a discussion about usability of the language itself, for different tasks, versus that of GUIs or tools available for programming support, but I'm still thinking about the topic].

In short, R works; plus it's free, and it's powerful and extensible. (For just how free is free: compare about $4K for what I'd need for statistics and database access plus some reporting, with $0K, and that's pretty free.) I wonder how the code compares to to MATLAB's.

2007 Usability Salary Study

The results from the 2007 Usability Professionals Assoc. salary survey are now available to UPA members. I am one, so I'm posting some highlights plus some new charts I made from their numeric data. Sadly, I can't get the raw data to try anything very interesting. A caveat first: The "usability" profession is only a sample of the jobs that relate to interface design, customer experience, interaction design, and other related titles. The survey reflects this (as you'll see) but does not necessarily reach all related disciplines. I'm particularly suspicious of the low numbers who responded from the US west coast, and suspect this is to do with general organizational regional politics (who belongs to what, who reads what, who cares). California in particular might bring up some of the numbers, from what I know of their salaries and consulting rates.

In general, salaries have gone up since 2005 by about $5000, most markedly outside the US (UK and Canada) and for women (who are, however, still paid less than men). Consider me irate that women aren't as valuable as men in most organizations, for most jobs, except secretarial.

Some charts: there are linear relationships between salary and experience and salary and education level.

I don't know if there is any additive effect; for example, if you're me and have a Ph.D. and 12+ years experience, do you get even more? (That is, if you're not a hand-to-mouth consultant like me.)

There are interesting relationships between job title and salary. "Directorial" are the highest job bin reported, which is disappointing (in that I keep hoping there will be C-level design folks soon). "User Research" titles are the highest paid individual contributors. This makes sense to me if UR jobs are being filled by advanced degrees. I feel they should be -- statistics, experimental design, ethnography, strategic input -- these are not activities to hire a junior usability testing person to perform. And I think the software industry understands this more and more, based on the job ads I see. Note that "usability" as a title component is now outpaid by "user experience." There were more respondents with the title "user experience practitioner" than for any other job title. This is good news, and appropriate; if a company understands that there is more to a good user experience than making it usable, then there is more involved in the job description and hiring criteria and it's also worth more. We're moving forward! (Even if women still lag behind.) Related to this, I'm personally interested in the chart of job "activities" practiced by the survey respondents. Usability testing is still way up there in frequency of mention in this surveyed pool, despite the shift in job titles. Design prototyping is close, but not at a par yet. I'm sorry to see this, since I don't think design should be done by non-designers and I don't think UX folks should be evaluating design produced by non-designers. I'm disappointed by how low quantitative activities and market research fall, but I assume this will pick up some steam as more senior quantitative user research folks are employed by UX departments. I'm especially disappointed by how low "requirements gathering" falls -- this being the number 1 cause of poor quality downstream, as found by many studies of root causes of software defects.

For a change of topic: In a sobering news story for those of us still trying to get design taken seriously as a strategic role, IT development salaries are projected to soar in the next year, well above what the data in the UPA survey shows. Read about it here.

Consumer Design is Easy?

Steve at tingilinde sent me a link to David Pogue's NYT piece on design flaws in digital picture frames. From the intro section:

"We learned deeply a few hard lessons," he said. "Consumer electronics is a very difficult business. It's difficult to get it right." ...

Maybe this particular guy is rightness challenged. Or maybe he meant that getting things right takes time, money and effort, which is true.

But it sounds like he's saying that it's hard to know what's right in product design, and he'll never convince me of that. A ten-year old could have identified the design flaws in the frames I tested this week.

I don't agree on all points -- Some of the design flaws he identifies are tricky "icing" on the consumer cake that it takes a clever designer and a budget to go after: like having a little pocket on the frame back for a remote control. Nice to have, but not mandatory, even for a good consumer experience.

But getting things right does take time, money, and effort; as well as "big-picture" design management of the sort lacking at all but few companies. Someone needs to remember the people you're designing for, and to represent that by stepping backwards out of the details of schedule and bug counts and putting into perspective: "...Hey, can your Grandfather use this for the baby pictures you're sending?" It's the responsible executive's position to make the call to change the schedule to accommodate the experience-breaker issues that will threaten you in a crowded market, and to champion processes like in-home user testing as part of the design cycle.

Kodak, who comes out pretty well for their frame design in his piece, hires interaction designers, although I don't know if they have a Chief Design Officer. So why hire an interaction designer instead of, say, a 10-year old? Because most 10 year olds aren't up to arguing with project managers and engineering schedules, and generally keeping their head both in the gritty details and well outside, for that important user perspective.

Pogue's piece is still good and also funny. As a former TiVo designer mystified by the crapness of most "consumer" electronics design, I especially liked this one:

Question 10: Which is the right way to label the jacks and buttons: White lettering on black (or vice versa), white on white (Momento), or with no text labels at all (eStarling)?

We did think of this at TiVo (of course), but I still wish we had added a little LED flashlight dongle to the back, since there's always bad light at the back of your cabinet!

A Look Inside SolidWorks

SolidWorks World, the annual user convention for SolidWorks CAD users, is going on now in San Diego. I'm consulting with the company, and have been doing usability research out here. (Rather strangely, I appeared in a photo posted by one of our blogger users here. The gentleman I am talking too was just made extremely happy by a brief chat with the founder of SolidWorks, who remembers his name every time he sees him.)

SolidWorks' latest release featured some major changes to the UI, which caused a bit of a ruckus among the experienced users. Matt Lombard, author of the SolidWorks Bible, is one of the ruckusers. Along with posting pictures of me (hah), Matt also just posted a YouTube interview with one of the best guys at SolidWorks and one of my clients there, Jim Wilkinson. To see some inside scoop on how the company works, you can watch it on YouTube linked from Matt's blog.

A final note: It's a credit to SolidWorks that someone like Jim exists there and has authority. Not only is he a good manager, but he's universally well-respected AND well-liked by everyone who meets him, internally and externally; and he's active in the user forums answering customer questions on top of his ever-expanding day job. Jim saw a need for a usability team long before most CAD companies found out such a thing exists (for the rest of them, that was only 2.5 years ago). Kudos to SolidWorks for having such great employees and managers. It explains a lot about the product success.

Designing Your Home Page

Kicking this one off, here's a good article by Joel Spolsky about the design of the product home page for FogBugz, which nicely spotlights the badness of committee decision-making in design. They tried to achieve too many things with too much input, the results frayed, and finally they [he] had to make the tough decision to start over and stick to a single unified vision with fewer "votes" on the matter. You can track this in the mockup screenshots.

Joel also makes a good point about the difference between the company page and the product page in terms of their goals. Nice willingness to go with entirely different styles, as a result. A brave decision!

I've been involved in a few home page design discussions the past year of consulting. They tend to be wicked problems (i.e., ill-defined, messy, and circular). Some of the reasons for this:

• There may be a difference between who you are and what you do, which may be important and hard to describe. Or hard to recognize.
• There may be a difference between who you WANT to be and who you are. This is hard to design for, because when you stray from what you are, you tend to confuse people.
• Conveying who you WANT to be in a clear fashion can only happen if you have a clear idea of who you want to be, and test your methods of conveyance on people to see if it flies. This is different from usability testing as usually understood.
• A bunch of company stakeholders who disagree on these things (who we are, who we want to be) can't communicate this to a designer very successfully. Design will then take a longer time, with more iterations, and may turn into a committee consensus nightmare.
• Design directions can be contradictory -- sometimes you can't say two or more complicated things, and you can't do both well enough to succeed at either. Let alone 10!
• If your business is confusing or going through a change of some kind, it's almost inevitable that the design reflects this, without a very strict control on it. No designer will succeed in clarifying confused input when the underlying problem is actual confusion. The designer may see this going on and be able to point it out, but that won't get it solved. The problems may be too high, too deep, and too wicked themselves. Solving them is much harder than the simple design problem at hand.

One client was working on a new project that was barely outlined in a development spec. He asked me "What do we do for our home page? We're really worried about that." It was premature for this, because most of the business plan didn't exist yet. The design input they REALLY needed was "Your business idea is a little too complicated right now. Can you simplify it first? Here are a bunch of others in your space with successful 3 bullet explanations on their home page. Can you meet that level of simplicity?"

Sadly, most designers aren't in a position to spur you to clean up your entire business plan. Or to make it clear that this might be needed because it's hard to make it sound simple when it's not. (At least, without lying.)

I think design is a strategic activity - requiring hard, brave, high level decisions in order to direct the minds and hearts of customers; and a creating a good business plan is therefore partly a design activity. To create a business that is clear and attractive to prospects, and therefore portrayable as such, requires high-level decision making inside a company. If more business leaders thought like designers, or more designers were in business roles, the execution of the home page would be a lot simpler.

Food for Brains

It's been a tough week - minor road accidents in snow, encounters with consultants that earn $2500 for a few hours of phone time [I don't earn this!] - so here's venty post on something that bugs me: People with bad memories. I don't mean bad in the sense of "I lost my keys again," more in the sense of "Weren't you going to schedule that meeting?" No, you were, you said you would! Why do I suddenly feel so defensive, when I did nothing wrong??

Any number of excellent books have been written about project management and scheduling, but few of them confront this phenomenon head on, and I've now seen it at a bunch of companies. Someone important, or even just useful, can cause a lot of damage by having a bad memory. If they're a manager, it might become their employee's second job to stockpile email in case they need to "prove" who's mistaken at review time. If it's a peer, they don't pull their share of the work because they conveniently forgot to do most of it and someone else has to, or some schedule slips. This might be passive aggressive (if they're not a psychopath or an asshole), but since it's the holidays, let's consider that it might be a medical problem. Maybe they're eating badly?

A few suggestions for coping: Start ordering in veggie platters. Take them out for sushi whether they like it or not. Leave them Secret Santa Ginkgo Biloba supplements by their monitor. And finally here's a list of some nice articles from Psychology Today on food for your brain, which I rather enjoyed:

• A Taste of Genius
• Top Ten Smart Foods
• Eat Drink Man Woman (on foods for long lives)

Happy holidays, and eat better! [Edited to add: Consider hiring a chimp instead if your team mate or manager can't remember things after eating better.]

BostonCHI Panel: User Experience Organizations

There was a good cross-company discussion of organizational models for User Experience (UX) teams at Boston CHI on Sept 11 (check that link for full bios on the speakers). Companies represented by managers, directors, and VPs of UX: EMC, Oracle, Symantec, and Fidelity (with Sun and others in the audience).

Some themes that emerged:

• Need to maintaining standards and cross-company guidelines requires having high level management or at least view that spans the organization — with creative org charts and management across sites often happening as well;
• Difficulty getting enough staff to meet demand (settle instead on doing fewer things well rather than over-extending, and making the case for more people that way);
• Organizations have more interaction designers than usability, by 2-to-1 or more (again, a separation of design from testing roles);
• Assumption that "good user experience" is no longer something that has to be argued for, it's seen as an obvious competitive advantage (the only mild disagreement from Fred at Fidelity);
• Engineering pay scale for their UX staff (common except for Fidelity, where pay didn't come up — since Fidelity hires a lot of low-paid contractors, I suspect they don't pay their internal folks by engineering scales ).
• Get the design right up front, or pay for it later. Very broadly assumed to be understood here!

Less obvious themes that resonated from my past few years in the field as manager and individual:

• UX people can get bored working on the same thing, or the thing with too small a scope. Being able to move across projects will help with this issue.
• Not having to be accountable for all your project time means being able to do cross-product things and user studies that will improve design work downstream (it doesn't mean goofing off on long lunch breaks!).
• Long-distance management working remarkably well with the right management attitude.
• From Oracle, being responsible for good products, not just good specs (teamwork in an organization). [Adobe, while I was there, was terribly concerned with the checkoff that UI had delivered a spec on time and were not "blockers" on the product schedule; this was an ill of centralized UI management that wasn't very flexible in the development process or in terms of their deliverables on each team.]
• Value of being managed and reviewed by people who know what you do, not being dependent on managers who don't understand your process, contributions, and work products.
• Investment in prototyping and development.

Relevant past post on my blog: my study of the job postings for UX folks on the BayCHI mailing list for 3 years. Oracle, Symantec, and EMC are on the graphs, but not very high in terms of number advertised for relative to overall size of the company. Fidelity doesn't appear at all, but it hires mainly in MA, I believe.

I have a full report (albeit sketchy) from the panel and the questions posted here. Scroll down to get past this recap on the top!

Classic Software Mistakes: Steve McConnell

Steve McConnell's blog is advertising a survey on the prevalence and severity of software management mistakes. It's worth taking it, just to see the long list of possible disasters. I don't think it's a wonderful survey as surveys go (they are very hard to do well), but it might make you feel slightly better about your current development environment when you see all the things that can go wrong. Or, not.

Some examples:

• Insufficient planning
• Abandonment of planning under pressure
• Subcontractor mismanagement
• Lack of effective sponsorship (at executive level)
• Outsourcing to reduce costs
• Unclear project vision
• Switching development tools in the middle of a project
• Lack of automated source code control

They're all defined during the survey, so it may feel a little long to take (plan on 20 minutes). My biggest difficulty was that a lot of them overlap, and it's hard to tell which one to "vote" for! I also wondered what he meant by "catastrophic" results -- I decided it meant people quitting, rather than projects getting killed, since it's often hard to consider the latter a catastrophe instead of a mercy killing.

I admit to mixed feelings about McConnell and this survey doesn't help reduce them -- he and his books are written as if no one but developers are involved in building software, which alienates me as a designer. His discussions of requirements, planning, and design don't seem to allow for the involvement of user researchers or even product managers, let alone interface designers who may have to write the specs. One "classic mistake" I see is to leave all the interaction design, visual design, requirements collection, and user testing to developers who also need to be writing code; may not know how to do the non-coding work well; and may not want to do it "all" themselves.

Software is and has been a multi-disciplinary effort for a long time now. McConnell has a huge readership, but hasn't helped spread that word, which set us all back a bit, I think.

Asshole-Driven Development on Berkun

Time for my weekly post on assholes in corporations, I guess; this is a few weeks behind, but I needed to space out the AH stuff, and I was busy.

Berkun posted an idle conversation starter on what he called "asshole-driven development" and the responses brought down his server. Then Lost Cog did some content analysis of the styles of development described by the comment thread. It seems to be going on and on. Some of the original categories identified:

• Asshole Driven development (ADD) - Any team where the biggest jerk makes all the big decisions is asshole driven development.
• Cognitive Dissonance development (CDD) - In any organization where there are two or more divergent beliefs on how software should be made.
• Cover Your Ass Engineering (CYAE) - The driving force behind most individual efforts is to make sure than when the shit hits the fan, they are not to blame.
• Development By Denial (DBD) - Everybody pretends there is a method for what’s being done, and that things are going ok, when in reality, things are a mess and the process is on the floor.
• Get Me Promoted Methodology (GMPM) - People write code and design things to increase their visibility, satisfy their boss’s whims, and accelerate their path to a raise or the corner office no matter how far outside of stated goals their efforts go.

As some posters and Scott noted, bad development management may be subtypes of general Management Antipatterns, like "Death by Planning."

And I'd note that these techniques aren't limited to management of technical problems, but also exist in any other project context, in slightly different forms.

User Experience 2007 Survey Report

The Usability and User Experience Report 2007 from e-consultancy costs money, but the sample data are interesting enough to post about. There were 756 respondents to the survey that fed this report. (Hopefully it represents more than just the UK, where the consultancy that did the survey is based.)

Some highlights:

• On average, organisations are investing 11.5% of their overall website design and build budgets in usability, and 13.2% of their design budgets. [If you're spending none, or you don't even know what you're spending, this may be an Issue for you.]
• A quarter of agency / consultancy correspondents say their clients are typically indifferent whereas only 9% say their clients are extremely committed. [I admit I find this surprising -- if you've been hired as a consultant, doesn't that suggest they care? Or is the evaluation of caring based on more complex factors, such as "are you listening to my advice," "is there anyone else in your organization advocating for this," "is it likely anything will change after I leave."]
• Top benefits/ROI for commitment to user experience and usability included as number one and two, improved perception of brand, and increased conversion rates. [Since brand is now being defined as what a customer thinks of you and what and how you do it, rather than your logo and graphic design [see, e.g., the Brand Gap], this makes a lot of sense to see here.]
• Two thirds of the respondents say their agencies plan to increase their spending on usability in the next year.
• The activities that are being "done" in organizations are, in order of frequency, user testing, expert evaluation, information architecture; and lagging behind, "full user-centered design" [a rigorous process that incorporates testing and design during the definition and development cycle].
• The largest barriers are time pressure to get things done and lack of resources. [We still have a ways to go to educate businesses about the risk factors in not being more rigorous about the processes for good design up front, it seems.]
• Project management is either not done, or being done "ad hoc." [Coincidentally, I've just written an article for interactions, a professional journal for designers, on the ways in which designers get lured away from doing design and into project management, in order to be sure that things get done. Timely!]

The full report costs $179.

Sutton's Weird Ideas

I've been reading Robert Sutton's Weird Ideas That Work, which is Yet Another Book on Innovation. I like his Assholes bookand Evidence-Based Management, and this one is entertaining and provoking too. Here is the summary of the weird ideas, which he counts as 11.5, but this is hard to do automatically in html so for me it's 12:

1. Hire "Slow Learners" (of the Organizational Code)
2. Hire People Who Make You Uncomfortable, Even Those You Dislike
3. Hire People You (Probably) Don't Need
4. Use Job Interviews to Get Ideas, Not to Screen Candidates
5. Encourage People to Ignore and Defy Superiors and Peers
6. Find Some Happy People and Get Them to Fight
7. Reward Success and Failure, Punish Inaction
8. Decide to Do Something That Will Probably Fail, Then Convince Yourself and Everyone Else That Success Is Certain
9. Think of Some Ridiculous or Impractical Things to Do, Then Plan to Do Them
10. Avoid, Distract, and Ignore Customers, Critics, and Anyone Who Just Wants to Talk about Money
11. Don't Try to Learn Anything from People Who Seem to Have Solved the Problems You Face
12. Forget the Past, Especially Your Company's Successes

He says executive audiences responded to him with an "all very amusing, Bob, but we need to get things done here." I admit I'm a little bit with them on this -- it's great for consultants to come in and be creative at you, but end of the day, most of us need to ship code/product, which means teamwork of some variety, goals and means mapped out, achievable successes. But an innovation factory is a different thing, perhaps.

This said, I have seen the teamwork and normative workplace culture taken to extremes of unhealthiness, usually to the detriment of new hires with different ideas from other places. It's possible to be both infused with creative new ideas that threaten your status quo AND ship products, in my opinion. It's a challenge for mature management! To test your own culture: Check carefully how many managers, especially senior ones, were promoted from within versus hired externally. Then look at how experienced the people being hired are (sometimes, very). It might tell you something interesting about status quo thinking versus desire for fresh input.

Another test of your culture: In interviews, does the corporate "fit" come across as paramount, or the resume and evidence of work product elsewhere? I once watched a very senior statistician get turned down in favor of a more junior candidate who was just like everyone else in her skillset. I didn't fight hard enough myself on that one, I was part of the problem.

Defying authority certainly doesn't go over well in most corporate cultures I've worked in. Hierarchy is very much part of the American firm (Larry Prusack pointed this out recently at a great Boston CHI talk)-- the larger and more established the company, the more ingrained it is. I think there's a function related to size, corporate age, hierarchical position, and a person's tenure at a company that will predict how resistant she/he is to new ideas about doing things differently. Because large, successful companies are most reluctant to change what they do now (which is making money), for some sensible reasons: shareholders, golden handcuffs, employees to retain and feed, etc.

For designers, this often cashes out in how much change to an old shipping product you can make... a lesson it took me many jobs to really understand. (Note to designers hunting for jobs: Don't believe them when they say you're going to redesign it, especially if it's selling! The inertia will be strong and may become an actual undertow.) Historical success limits how much change you can make to processes that produced a selling product, even if they were flawed or painful in various ways for the people who worked on it. People are always more comfortable the way things are, regardless of what could be better.

Edited to add: It's a cultural failure mode to assume that everything is great or okay as is, but it's another one to fail to critically understand your successes, too. You can do root cause analysis for the good things too, and it might even teach you more than the failures do. If you aren't good at understanding success, you can't duplicate it, and you might make the critical morale error of celebrating the wrong factors.

Of all the weird ideas, the sensible-sounding "punish inaction" is particularly hard to see really happening in most offices. Few people are ever fired for not rocking the boat. People who aren't often noticed usually have a job for life, as long as their company keeps doing the same old expected thing.

CEOs Who Work Too Much

A great article in the Huffington Post on CEOs who neglect their families but get written up in Fortune for it. Low-income fathers who work too much get critizied, but Fortune blithely praises it in executives. Towards the end there's a nice bit on the long hours phenomenon more generally:

Fortunately, respect for this sort of parenting outside the board room is dwindling as baby boomers disappear from the parenting picture and Gen-Xers take their place. Sylvia Hewlett presents research to show that while baby boomers are willing to work extreme hours, younger people scoff at the idea of doing that for more than a year. And recent polls (via Hole in the Fence) show that men are sick of the long hours and want more time with their kids: Almost 40 percent of working dads would take a pay cut to spend more time with their kids. It'll be a great day when CEOs are dismissed for neglecting their kids. Meanwhile, employees, beware: CEOs like Stringer and Immelt have a negative effect on your own ability to keep your personal life intact, because work-life policy starts at the top and trickles down.

Amen. Some ways to figure out what the real corporate values around work-life balance are: Do people regularly have email exchanges on weekends or at strange hours of the night? (When you start a contract, do the execs welcome you via email sent on the weekend? :-) Who's still working at 7pm in the office?

Another point I'd add: How effective are they if they have that much to do, even at the office where they spend all their time? Executives at one of my past companies-- who praised it as an "aggressive" company with no ability to promise new hires good work-life balance and reasonable hours during their growth plans-- were themselves too busy to pay attention to many of the critical management issues that cross their desks! They're way past the tipping point on being good parents at the office, or good peers-- blowing off visiting VPs, even-- never mind what their wife and kids think of them for neglecting them! (This is, of course, my own opinion on them as seen from the middle management trenches, and may not be their own or their peers' opinions.)

Berkun on Innovation Myths

Another book recommendation: Scott Berkun's new Myths of Innovation. I'm a big fan of Scott's earlier book, Art of Project Management, and his new one does not disappoint. I think it stands apart from other books by consultants and design agencies on building innovative organizations. (They're now a dime a dozen.) It's short but still condenses a huge amount of material from both business lit and historical research in a way that even someone who once wrote a dissertation can be amazed at. (Note: I was not as successful as Scott was at this trick.)

One of my favorite parts is on the myth that "good ideas are hard to find." Why, no, they're not, but execution is hard. Which segues nicely to his other book; in my experience, a lot of organizations have grand product plans and grand business goals, but execute very, very poorly. The customer only ever sees a fraction of it, and often the worst fraction.

Some of the sentiments that kill good ideas before they even get to fail by execution include: "We don't have time," "That never works," "We don't do that here," "We tried that already," "That won't make enough money." A longer list lives here on Scott's Blog. I'd add the question: "Who are you, again?" Or the related, "You're here to listen, not talk" (which I've actually heard).

The issue of time is the biggie, from what I've seen in my past few companies. The execs may be reading books about innovation (for whatever reason), but at the operational level, everyone is signed up for way too much work. They can't succeed at what they've agreed to do, but they're trying anyway. Why would anyone want to sign up for more, regardless of how cool the idea is?

I have the same feeling about brainstorming; as a concept it's all warm fuzzies, considered obviously valuable, although it's often poorly or incorrectly executed (as Scott points out). In practice, though, not everyone's ideas ARE considered equivalent, precisely because of this economy of time available to the participants; given a small, finite amount of time to think and make decisions, why pay attention to the crazy sounding new kid's idea, instead of the seasoned manager who deserves to get his say because he's proved himself, right? In a more applied, problem-solution context, the more seasoned people are assumed to "know the code" or "know the users" better and therefore their opinions are worth more. It's been said out loud. It's basic human sense, right? And the less time people have, the less they're willing to extend themselves to be open.

Successful innovation might require fewer over-ambitious projects, acceptable risk and play (meaning: someone isn't working on your critical shipping "normal" work and that's okay, and not overtime work for them), plus a commitment to try to listen to all voices differently, no matter what the problem is: new product, new feature, or old ordinary problem you have to solve on an ordinary project. I'll come down strongly in favor of that last -- I think innovation can happen on "old" projects, too, and it should, to keep them viable and interesting to developers and customers.

But good project management is always needed to help you actually plan and then ship something! It's still innovation once it's in the development phase, even if it feels like just "work" then. The team needs to be supported, rather than having their work taken for granted as "a done deal" while managers go off looking for the next big idea.

I can't find it now, but one of my favorite lines from Myths of Innovation goes something like, "Successful ideas, like happy pets, are shared among many people who care about them deeply." Pet them, sometimes.

Hiring the Smart and Effective: Joel

Joel Spolsky has just published a short, concise book on his hiring principles, summarized by the excellent "Hire Smart People Who Get Things Done." His book is Smart and Gets Things Done. I've blogged about his hiring guidelines and other interviewing issues: My 20 Observations on Coporate Design touches on this, as does the post about "Joel on Interviewing, Me on Performance" and the one about "Past and Current Employees and Your Reputation."

As a consultant now, and a survivor of (too) many companies, I do and have done a lot of interviewing. As a manager, I interviewed a lot of people while hiring (especially at TiVo and Autodesk). Joel is a good guy to follow on this subject, and I find his points can be extended to interviewing for designers and good employees in general. Failure to hire well (or take the right job!) is sometimes your fault!

Some things to consider when interviewing people to hire or interviewing for a possible job yourself:

1. A bad interview usually means "you don't want them and they don't want you." It's okay if it's not a mutual fit. Use that time wisely on both sides.
2. Some reasons for bad interviews (that suggest bad jobs in the background): They have junior people doing the interview, because they don't take it seriously; they have unqualified people doing the interview, who don't know what's good or bad; they have the wrong expectations, because they've never hired for this type of position before or are confused about the market and the job.
3. If you're the interviewer, and you do a bad job, that person is now possibly pissed off; freaked out; depressed; going to tell other people about your and your company. Mostly about your company because they may not distinguish between you and the company since they probably don't know you personally and you act as a representative of the company when you bring in a candidate. They may want to tell their friends, who are possible great fits, or tell their friends' friends, that you are a scary place to interview. This can do you damage and make it hard to get good candidates, needless to say (right?). I've heard more frank stories from former "rejected" candidates of the places I've worked since I left them than you can imagine. Bad word-of-mouth is not something you need in a competitive climate.
4. Sometimes you hire badly not because the person is bad, but because your job description or belief about what's needed are inaccurate. I've also heard plenty of stories along the lines of "this is not what I thought I was hired to do." (See post on "Invisible Work," for some examples.)
5. Someone who does a really superficial interview for a high-level position is a warning sign: either they hire other people badly so your peers will be poor colleagues, they have had a really hard time retaining and are desperate, or... something worse. Be wary of people who don't do a rigorous interview. I had a great one recently, or mostly great: the hiring manager walked me through scenarios, questions about the resume (detailed), adjectives people would use to describe me (I tried for positive and negative), past performance review feedback, etc. Her one failure was that she didn't ask why and what I was looking for up front, and in truth, I wasn't really looking! I was hoping for an informational discussion, as a consultant, first! But at worst, this wasted some of our time, and I ended up thinking she was a good manager and a possible contact for future work.

Ways you can avoid bad interviewing, as an interviewer, apart from having design/code tests and the other things Joel talks about:

• Treat each candidate very seriously -- it requires energy, but don't convey disinterest. Intuit once sent me home with a design test, rather than doing their usual and more effective whiteboard version, which pissed me off on several fronts; and I would not interview again with them despite them having many large product groups that need good designers, and see, I'm now blogging about this; see points 1 and 3 above.
• Get back to them in a reasonable amount of time with frank but polite response -- yes you're busy, indecisive, disorganized and unable to get everyone's input or reach a decision as a committee, but still. This is important. They're forming conclusions about you too.
• Don't assume you're their only job option and they're not being picky and making a decision too -- you're not in as much control as you think you are here.
• Don't let disorganized, rude, or confused HR people get involved and ruin the mood for them.
• Have senior people involved, to show you care, and to help make the right call outside of the comfort zone of junior folks on the interview schedule. Sometimes a hire can be strategic as well as tactical.
• Hire for potential and growth, not because of someone's current age (yes, it has happened), what they look like (yes, again), because you had budget to spend (someone still has to manage them), or because of domain knowledge that they will lose in a year off that former job. Yes, it's harder to evaluate this, but if you can't do it, maybe you're not the right person to hire or manage them?

Followup on Assholes at Work

Following up on my previous post on this... On Sutton's blog, he has a No Asshole Rule Roundup of comments he's gotten. One is quite well-taken: the subtle asshole is just as bad or worse than the flamingly obvious asshole, in their effect on morale. Sutton agrees: "Indeed, these more subtle assholes actually can often get away with doing more damage than their more 'over the top' and less politically skilled counterparts."

While googling around, I ran into this well-observed book review: Disorganized, Incompetent and Dangerous: Workers Dislike Manager Incompetence Even More Than Abuse, Study Suggests. The review is for a book I have since ordered but not yet read, Dignity at Work, by Randy Hodson. Some points from the article about it:

He found that abuse by managers was significantly connected to negative employee actions such as absenteeism and withholding effort on the job. However, the research found an even greater connection between mismanagement and these same negative employee actions.

"Nobody likes abuse, but employees can find ways to work around abusive managers. But employees don't want to be involved with chaotic, mismanaged workplaces where nothing gets done well and people feel like they can't be effective," said Randy Hodson, professor of sociology at Ohio State.

"The thing that undermines dignity more than anything is incompetence and mismanagement."

I spoke with someone recently who told me how much he'd learned from someone competent who had managed with a big stick approach, arguably an asshole by Sutton's criteria. But he had respected the guy anyway. It seemed to me in listening that he had tolerated it while he was learning, and then moved on to a more humane work environment. You decide the moral, if there is one.

Design and Risk and Innovation (and CEO Pay)

Over on NussbaumOnDesign, there's an interesting thread on the role of designers in innovation. Designers thrive on risk, learn from it, and move on from it, so they're useful as models for innovation processes at companies. That's is the gist of a piece by IDEO folks summarized here on BusinessWire. Given this, design as a process reduces corporate risk during innovation, Nussbaum recaps:

Let me repeat--the design process cuts risk. When you do design (or innovation--whatever you want to call it), you use ethnography, prototyping and story-telling to develop a product/service/experience. These processes actually reduce risk. This is a fact that most CEOs simply do not get. It is far riskier to come up with a new technology in the labs, make it into a product and then throw it at consumers than it is to first start with your consumers to find out what they really need and want (the essence of design).

This admirable sentiment requires a definition of design as a process that involves good customer research, a definition not all would agree with, although I myself certainly prefer it and sell that as a service during design :-)

But for any good interaction designer, intuition counts, as well as the prototyping, empathy for the customer, focus on the desirable, and grounded research to inform that process. The risk in design is that there's never perfect and complete data, and at some point, you have to just follow that intuition and make something which might be a failure if one of a million details doesn't go right. And those final details are usually a team effort, whether the designer wants them that way or not: building a product is (usually) expensive and complicated, unless it's a garage Flash app.

There are a few provocative comments following up on this later on Nussbaum's blog, suggesting that until designers put up their own capital, they are less risk-taking than their clients or the businesses that run with their ideas. A quote from the comment by Chris Conley:

Actually one could argue that designers simply ask their clients to take risks on them and their work. Few designers put their own capital at risk. I would also argue few understand the notion of investment and return which is how risk is manifest and monetized in business. Designers mostly have a cost mindset just like most business managers. An investment mindset is something that needs to be taught and is part of a innovation toolkit. Until designers put up their own capital (and not just the proverbial sweat equity) and take real equity positions in ventures, the risk is truly being born by someone else.

But there are other real risks for designers apart from personal capital, which Conley doesn't acknowledge: loss of credibility, reputation, credit (including financial reward), missed opportunities at other companies/agencies while betting on this job or client, and others that may be more important to an individual designer. Personal risk management is about all of that, too.

Edited to Add: Actually, after drafting the above and going to bed, I've woken up fairly incensed at the idea that designers should be putting up their own money in order to experience "real" business risk. Point one: Many of them do, because what they're motivated by is seeing their ideas in the world. They quit and go to startups, they do their own thing online, etc. This is fairly clearly "their own money." (At one company, when I couldn't get usability bugs taken seriously, I considered bribing engineers to fix the bugs I had filed. I was a hair away.) Point two: CEOs and other executives certainly don't put up their own money, and they're paid outrageously in comparison, so don't talk to me about money here, Mr Conley! Hmmph. Here are some articles on the pay issue, if you want to get educated about this:

• CEOs are Overpaid
• Executive Paywatch
• A new trend in CEOs: The See-Through CEO.

Note especially that even if they "fail" they have enormous severance/retirement packages, suggesting there isn't much financial significance to their failure.

The Asshole Test

Surprisingly apropos of recent posts on management, there's another popular book going around now: The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn't, by Robert Sutton, one of the authors of the well-cited and enjoyable Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management.

Sutton also has two blogs, on which he's posting rousing, blood stirring commentary on the reception he's getting for the assholes book. One is "official" at Harvard Business Review: The Working Life. There's a pointer there to an online test you can take to determine if you are an asshole, and it includes gems I've posted about before, such as: “You are constantly buttering up your boss and other powerful people, and expect the same treatment from your underlings.”

His other is his personal blog, Work Matters, which has even more about the book's reception. If you're interested in asshole managers and hostile workplaces, they're both good reading.

Sadly, I suspect even assholes are passing these on -- consistent with the "Incompetent People Don't Know They're Incompetent" findings I've posted about before. And I fully understand the potentional implications of my pointing this out. :-)

Workaholics in Consulting and Engineering

Really more about type-A personalities, or at least very driven people: An article in Fast Company on Boston Consulting group trying to get a grip on employees who work too many hours.

"A hero at BCG is not someone whose light is on at 10 at night," says Kermit King, the firm's head of recruiting for the Americas. "The emphasis should be on productivity per hour, and I think there's a point where productivity diminishes."

That's why the firm--which doesn't bill by the hour and explicitly states that hours don't figure in promotions--launched a program called the Red Zone three years ago to spot and tame chronic overworkers.

It's not quite working yet -- perhaps because the workload makes it impossible to succeed within the green zone. They have had a slight decrease in the percentage of employees who say their load is not manageable, though, up to 63% from 67%. (At one place I was salaried, 100% in my department said it was unmanageable. The hours we worked reflected this of course, which is one reason I charge by the hour now.)

A related post appears in the increasingly interesting 37signals blog, on development type A's: Don't Be a Hero. Their gist is that if you haven't finished a task in estimated time allowed, don't push on to do it in more time:

That’s where the concept of sunk cost gives us a guide on what to do. It doesn’t matter what you’ve already spent. That time and money is gone. It only matters whether spending what’s left is worth it or not. Business school 101, but one of the hardest lessons to internalize.

Unfortunately, the switching cost is often high for creatives and execution-driven folks. In morale if not attention to task measures. But in general I think their point is very good.

12 Breeds of Client

Freelance Switch, a site for freelancers of all types, has a nice post about different types of client personalities and how to handle them. It's applicable whether you're a genuine freelancer or working in a consultative role inside a large organization -- I recognized a lot of it from traditional dealings with consumers of interface design and usability, including previous managers. Some of my favorites, in the "recognizable but not so nice" category:

• The Hands-On Client: The hands-on client is a frustrated artist, as soon as they walk in the door they will be telling you about their skill as an artist, illustrator, photographer or writer. The hands-on client already has a very specific idea about what they want and usually has very little interest in your thoughts on the matter.... If you feel you have an ethical responsibility to point out the flaws in your hands-on client’s directions, you are headed for conflict. Hands-on client’s secretly believe that they could do their job much better than you and that there is little or no specialist knowledge you could possibly impart. One oddity about working with a hands-on client sometimes occurs when you give in your creative ambitions and agree to do it their way. All of a sudden your hands-on client may accuse you of making them do all the work or not doing your job.
• The I’ll-Know-It -When-I-See-It Client: The I’ll-Know-It-When-I-See-It client shares much in common with the uninterested client except in a more frustrating way. Their indecisiveness and inability to articulate what they are after makes them one of the few clients that it is generally best to steer clear of.
• The Always-Urgent Client: All their emails are ‘highest priority’ and their couriers are always red-hot. They work on weekends and late into the night and think that everyone else does too. Additionally the always-urgent client often seems to think they are your only client and that their job should therefore be your highest priority as well as theirs.
• The Decision-By-Committee Client: Usually inhabiting the world of large corporate clients, the decision-by-committee client can still be found in smaller operations where they share their decision making with a spouse, neighbour or dog. The decision-by-committee client is one who lacks a single point of authority and for which every decision must be approved by many people.

I'm breaking in a new tag for this one, a consulting tag.

Crazy Bosses Hall of Fame

An entertaining read at CNET: the Crazy Boss Hall of Fame, featuring stories of swearing CEOs and bathroom reading that's circulated daily. Weird stuff in there, it might make you feel better if you work for a nutcase. I don't like the suggestion that I always get in these articles that because they're aggressive and nasty they succeeded in business (maybe I read it in, but it's caused by close juxtaposition of wacky antisocial story with glory story of million dollar business win).

But there are some good failures in there too, like Craig Benson of Cabletron who also failed in politics. Anyone else find irony in a guy who ran a company like a "military environment" and then ran for office on a libertarian-bent of "less government in people's lives." He had a virtual staff and virtual volunteers, with whom he had (virtual?) affairs. He ran standing meetings from behind a standing desk -- leading to a great quote from the article link above:

"It is," Peterson said, "the most efficient way to reach the wrong answer in the shortest amount of time."

Best-selling books touting surprising management styles keep coming. First Break All The Rules: What the World's Greatest Managers Do Differently has 227 positive reviews on Amazon right now. Hopefully, being a great manager isn't just about finances but includes something about work culture, too. I'd like to think you don't have to be an asshole to do good things for the company. Meanwhile, breaking the rules doesn't make you an asshole either -- a senior VP at a former company criticized a move I made as a manager for an employee of mine on the grounds that "I've never heard of anyone doing that before!" Yes, it really was intended as a criticism, and probably said more about him than me, alas.

Relevant past posts on ghostweather: Is Your Boss a Psychopath? And Past and Current Employees and Your Reputation, not to mention, Demotivation and Burnout.

Passionate About Your Job? Your Career? Your Company?

A while ago, Creating Passionate Users had a post about employees who are passionate about their employer versus passionate about their work. The gist was that people who are passionate for their company are like this:

• Defends the company to anyone, anywhere that criticizes or questions its products, policies, or practices
• The ultimate team player who goes along with the group rather than voice dissent
• Is well-liked because they do whatever is asked, enthusiastically
• Accepts (and uses) phrases like, "this is what corporate needs us to do."
• Cares a lot about his career path in the company; focused on getting management recognition.

Whereas employees who are passionate about their work are recognizable because they:

• Would spend his own money, if necessary, for better tools
• If they were NOT doing this as their job, they would still do something related to it as a hobby
• Works late nights when, "I'm just one-compile away from this awesome refactoring that's going to make this thing run 40% faster." In other words, they work late when they're driven by something they know they can do better on.
• [And somewhat controversially:] May not be extremely well-liked, but is highly respected and tolerated because he's known as one who, "cares deeply about doing the best possible job, and is very good at what he does." CPU's updat