My Take on Big Company Suckage

Scott Berkun wrote a good post on Why Big Companies Suck, at popular request on his site. It made me think about my own experiences at small, medium, and large companies over the past 20 years. I'm assuming Scott and his readers were mostly talking about "why it often sucks to WORK at a big company," rather than why big companies suck from the outside looking in.

The individual is lost in the machine. The opportunity to be noticed, to get feedback for doing a job well, or for improving someone's life in or outside the company, is that much less. Which may limit your chance of a promotion, or just make you feel your job is pointless. One company I worked at had a famous management mantra, "If you're not making the product or selling it, what are you doing here?" Which is absolute bullshit, and dismisses the administrative roles of accounting, the benefits department, travel and admin staff, tech support, and other critical team members at a large software business. Functional companies need a lot of people doing different things, otherwise the people writing the code can't do THAT job.

Communication from the top is often poor, intentionally or not. The message that trickles down from management, or that's delivered from main stage at company meetings, tends to be diluted for the common denominator, which means it's not really addressed to anyone in particular. Sometimes it contains no information at all, as a result. Scott may have covered this under "they believe their own bullshit," but I think there's another slant on it: They don't know what's going on. The more levels and divisions there are, the more distorted the signal is, and the more likely you are to hit people who aren't sure they're supposed to be telling you something that they know.

Secretiveness. I don't get it - but bigger companies tend to keep more secrets from their own employees. I have nothing to say about this right now, because I'm just baffled by it.

Managers are rarely evaluated well or fairly at any sized company. Even in times of turnover or economic distress, management are the last to go (unless they're a very public, board-threatened figure, like a CEO, in a very bad political environment). Scott mentioned the Peter Principle, but I think it's more profound -- with power working as sum of the people below you, the weakest point in the tree is the bottom. Even when the bottom is arguably the most valuable part of the workforce. Companies with a lot of management structure will have fewer people doing quantifiably good work, occupying the org chart and protecting themselves at the expense of the workers under them.

Evaluation of what's good or valuable often happens on idiotic scales. When I worked at AT&T Labs 15 years ago, the company didn't think about anything but a sure business that would pull in billions -- never mind betting on smaller startup ideas to see if they could create new markets or businesses. Other companies like 3M and Google have since made this a visibly stupid way to do business, but it's definitely an easy way that managers can avoid risky bets on new verticals or product lines.

The small company made crap, and now the big company has to support it. Staff in big companies are sometimes stuck in trying to repair what was made by the small company, or what was acquired from the small company. This really sucks for the people in the big company. Bad design that was produced in a "proof of concept prototype" as VC's pounded on the door and the cash ran out -- well, those guys saying the good old days were great got rich off that crap, and now it's everyone else's job to "fix it."

Because the small company made so many mistakes, and the bigger company learned from them, there is more process and review of decisions. Face it - a lot of the processes and checks and balances in bigger companies exist because of bad things that happened when the company was smaller. The big company "learned." It decided it was too risky to do that stuff again. Stuff like having no usability review of the most important feature of the release!

Smaller companies sometimes feel more homogeneous -- the individuals know each other better, and there's usually less role differentiation and processes involving a lot of people you don't understand. This can make it more pleasant, give the impression that you're "getting things done," but it can also mean less original or high quality work is produced in the end. See above, about producing crap and making mistakes.

People who have their own money at stake, or make a lot of money from something they did, tend to be very engaged and happier about their contribution. This is a guess, but I think this study about hourly workers supports it. The study says people feel a stronger correlation between happiness and rate when they are paid hourly, rather than by salary. There's a direct reward connection between money and time. People who got a lot of money from a startup --either from selling one, or being there and getting the stock profits -- no doubt feel they were rewarded by the world for something of value that they did. It's less easy to feel rewarded either monetarily or by subjective feeling in a big company. Because the individual contribution is much harder to make or to recognize.

Finally, a few ways in which small companies can suck, too: There's never enough money, or for long enough; there isn't enough staff to do things that need doing (travel booking, accounting, etc?); the hours can really suck, related to the money issue, no doubt; there are STILL cowboy coders and often secret politics about decisions and design directions and what we're hiring for next.

In Defense of Hard Skills for Designers

The other day I was in a meeting in which evaluation criteria for developers came up; nice concrete stuff, like writing code that other people can read and modify, putting in comments, resulting bugs, etc. It made me pause and admire the local weather of that strange country. In my experience, it's vanishingly rare for an interaction designer, usability specialist, or User Experience professional to have such nice hard criteria applied in evaluation of their work. Far too often, we're judged on mushy subjective factors like whether some team likes working with us, or feels we're doing something valuable--often outside their expertise or range of view to make this judgment, but that rarely stops anyone. I have some stories about this subjective mushiness in my article in HCI Remixed, titled "Designing 'Up' in the Software Industry."

Why is this--sign of an immature field? evidence of double standards, for sure, but also imprecision of job role? Poor management, perhaps contributing?

I suspect it's related to the observation that many designers have trouble achieving credibility in their role. Scott Berkun's seminar for UIE on Why Designers Fail advocated working on "soft skills" over hard skills, such as learning ways to win friends and influence people via negotiation, diplomacy, and other interactional condiments.

Not to pick too hard on Scott - it's hard to disagree that people skills are valuable and most of us in the computer industry are weak in some of them - but I think it's generally NOT true that designers have sufficient hard skills. I think gaining and using hard skills are our best bet for being taken seriously in places full of skilled workers. Most interaction designers spend too much time in "soft" areas that can too easily look like matters of opinion to others, or overlap and sometimes threaten other existing professional roles like product management: user testing (which often looks like "anyone could do this"), observing people work and suggesting improvements to their tools, pointing out issues in existing products that could confuse users (heck, everyone has an opinion on that), scheduling and managing stakeholder meetings, writing requirements documents and functionality specs. Most of these activities are politically difficult, and don't make other colleagues drop in their tracks and say, "Oh, you're so valuable and provide skills we don't have!" As I pointed out in my HCI Remixed article, a common reaction to much of this work is, "Didn't we already know that?" Finding problems with software is relatively easy; creating solutions is not.

We can convey solid, indisputable value when we focus on creating concrete, skilled deliverables that NO ONE ELSE CAN MAKE. In economic crunch times like now, consultants hear this from the front line. If a client or potential client has someone on staff who can apparently do what they do, they're not a clear asset. Never mind that they have 15 years of experience doing it, if their value looks like primarily "opinion" or "process," it's not very convincing when it comes to opening the bank account.

Here are some of my suggestions for hard skills, that many interaction designers and usability folks could stand a more training in:

• Technical prototyping skills: Flash programming, javascript/ajax, css, html site design, Flex, Expression. Use of the tools that are used by developers, at a basic prototyping level, is a solid PLUS, because you can make things that everyone can see are relevant to the end product.
• Ability to make high quality visuals: Visual design training, skills with Illustrator, Photoshop, page layout applications, and other design tools for good looking mockups. Low fidelity may be useful and helpful with fast user testing and concept evolution, but you want to be able to make something your client or non-designer colleagues can't make. I know one case of a visual designer hired into an interaction design role because of the caliber of his mockups. Never mind how wrong this was for him and his manager eventually-- it got him the job to start with.
• Data analysis: For user research, learn some solid statistics. Even just pivot charts! Maybe some VBA for automating actions in Excel. Eventually, data mining, increasingly important with the large amounts of data around. (This is a career growth area all on its own right now.)

I'm with Scott that it's not a highly valuable proposition for a usability engineer to learn to do a cognitive walkthrough when they already know how to do 5 other methods for usability evaluation. But that's the wrong "hard skill," in my opinion. One who learns to make beautiful designs, which no one else could have made, will have a serious edge in their job role. Same goes for other skilled, niche deliverables. True story: A client with a budget problem told me recently that she had people in-house who could do an InDesign layout project, and that my value to her was in the data analysis and recommendations I could deliver for her that no one else could do. Good thing I'm working on that array of hard skills!

If only the university programs for HCI, UX, and usability thought like this, designer credibility issues would start going away a little faster. And performance evaluations for more designers could be done in concrete terms like how much good stuff we MADE during the design process, not how much we talked in meetings and if the other people there liked us when we did.

CHI 09 Panel: Moving UX Into Strategic Importance

At CHI 2009, I took a lot of notes at the panel "Figuring Out the 'One Thing' That Will Move UX Into a Position of Strategic Importance." This is a rather random summary of it; see a similar topic in my post on User Experience Organizations discussed at BostonCHI a couple years ago.

Jim Nieters, Director of UX at Yahoo!, advocated speaking the language of business, and addressing business concerns in our design work and priorities. UX at Yahoo is now in marketing, after another reorganization. They will be providing input on the product funnel, helping to prioritize company efforts.

He reminded us that even at the executive level, it's a life or death battle, and everyone has someone to answer to at the end of the day. Convincing stakeholders of the design profession's value is less important than delivering as individuals; we need to be personally accountable for our work and stay focused on the right projects.

Regarding the standard issue of having too few resources: Invest in projects carefully. A team too diluted on too many projects can't be as visibly effective. Turn things down, and focus on the most important. Work on the revenue generators, and work with the business to understand the right problems and the solutions that can come from design.

During questions, he revealed that for products to move forward at Yahoo, they need "3 in a box": key stakeholders from Product Management, Engineering, and UX have to all be in agreement before work proceeds. Sounds good to me!

Laurie Pattison, Senior Director of UX at Oracle, was up next. Her message was that you get one chance, and have to sell yourself well. You only get one chance to make that first impression. At the management level, you have a calendar quarter to make an impact. Since you can't succeed at everything, you need to pick projects carefully, and provide business value. Businesses are in the business of money, after all.

As part of the sales process, deliver something other peers at the company can't do themselves. Make smarter wireframes, prototypes, or more attractive deliverables. Come up with innovative ideas that they can't think of themselves and the value will be clear.

Her example case study was a project to help reduce tech support calls. The team did simple usability studies and discovered that users couldn't find answers to items that were in the documentation. Their redesign put answers in context and reduced the need for the search functionality; the number of calls reduced as a result, and the bottom line was visible. The CEO was educated about the process and methods and it was a clear win for the team and their methods.

One questioner asked her why not just do this on every project, it's the standard research and design process. But resources limit what you can work on. "Pick projects that matter to the bottom line. You pick mind share or market share."

In a somewhat depressing note, several panelists agreed that your team (or your contributors) are only as good as the most recent success, that failure follows them around forever otherwise. "If you spend only ten minutes working on something because you don't have time, and it fails, people will remember you were associated with it and blame you. Better not to work on it at all." I'm disappointed when I hear this sentiment, given the recent discussions in other places about taking risks and embracing failure during design. I'm afraid failure may be a luxury for very well established teams.

Craig Peters, consulting as Awasu Design, argued that we need to pay more attention to the individual contributors in our organizations and their basic skills and effectiveness. "No matter what the strategy, if we don't think about the individual level interactions, the big picture won't be helped." He described a situation at Wells Fargo in which a UX team had reached a limit on their effectiveness; and he investigated and found that non-UX colleagues had had varying types of interactions with the team and found no consistency in their expertise or work. (I'm reading this in - Craig was pretty vague about the actual details of the findings and recommendations for improvement.)

During the questions, the panel and audience debated some on whether we count as a "young" field after 20 years of CHI conferences. Regardless, it does seem that different skills may be needed to convince different organization types and sizes.

Lauri represented the absent Killian Evers, UX Program Manager at PayPal, who argues for the need for program management skills in larger companies. Program managers can successfully bring metrics and rigor to UX and bridge UX and development. (I myself agree with the need for project management everywhere, but think that UX teams need to be able to work with software culture metrics, processes and tools, and there's no excuse for requiring a third party to manage this. But I may have misunderstood the points here.)

Some comments made during the question period, not all of which I was on board with:

• If your company doesn't value your contributions, move on to another one. Corporate Darwinism works.
• Don't waste too much time on ROI attempts. Testimonials from internal folks can go a long way. If you can find someone who needs something and you make an improvement, communicate it afterward with a story. Could even create internal portfolio of examples to help support your value.
• "If you're in a confrontation or argument, you're already lost." (I find this of some concern; many dev cultures produce lots of argument and confrontations, and if UX people aren't allowed to play in those, the field is not level and we're really handicapped.)
• The impression of many UX teams is "often you come in too late, you don't understand our jobs, our deadlines, our deliverables." My comment: Who's fault is this, actually? Bring us in earlier, etc.
• UX teams without domain knowledge can be seen as liabilities. Response: Get them educated about the domain, it's part of onboarding.

Finally, there was an acknowledged tension between the desirability of being an outsider brought in for point expertise ("like a lawyer") or a team member long term. These are obviously very different models, for staffing, for hiring, for seeking positions of corporate influence.

At this panel and at the one on "Fault Lines of UX," individual contributors asked how they can make change as single UX people alone in non-UCD environments. There were no simple answers for these folks. I particularly feel for the student who said to me after the Fault Lines panel, "I was taught UCD very rigorously in school, and I thought everyone did it. Now I find out most companies don't. How can I proceed, what should I be doing?"

An ongoing exercise for our profession, as mentors, educators, and colleagues... We need to help her.

So You Need to Do a Usability Test... But the Product So Obviously Sucks.

Most of us in interaction design jobs have been asked to do a usability test on something that we don't think is ready for prime time. You think it needs some design work before it even gets to users. The usual scenario is that your company or client is unwilling to listen to another stakeholder with design opinions (yours, or your team's), but will believe it coming from users. Either that, or they don't know what design is yet, but do have an idea that usability testing is a good idea.

Some strategies for turning this to your advantage, if your ultimate goal is being involved in the design, not the evaluation:

• Make it a test that's just Pass/Fail. Don't allow room for wiggling on the results, or you wasted your time getting them data they don't want to hear. Agree up front on what this thing is supposed to support, scenarios they think it has to handle, and be firm on delivering the news afterwards. It's too easy to get wishy-washy about informal usability testing, and leave room for argument, otherwise.
• Create alternate designs for use in the usability test. One of the best ways to educate the organization about the value of design is to DO IT. And to turn the test into an evaluation of multiple designs will help build your credibility and turn post-hoc evaluation into formative, and more useful, usability testing. Throw in some mockups at the end, or at the start, and ask for comments on those in comparison to the product that so clearly has problems, from your perspective.
• Write the report before the test. No, not as unethical as it sounds - you won't deliver it, but you're checking on your skills to predict what's going to be hard to use. So, you got all worked up about how this thing is hard to use, for obvious reasons; now check to see if you were right! Better yet, have more than one person on your team do their own reports, privately, before the test, and seal them up. Afterwards, see who was the best at predicting the disaster. Chances are, the users will fail in ways never imagined (thanks to Kevin Berni for this line), and you'll be a little less cocky next time this situation comes up. But if you get it all right, you're building your case and confidence for pushing back on this kind of request next time around.
• Ask others in the org to predict what might cause the users problems in the current design before the test. I used this tactic once when a QA organization felt the way I did about the usability of the product we were testing. I gave an award to the person with the most accurate prediction of user difficulty after the analysis. You want everyone in the company to know who has good insights into design and usability, right? People with good instincts need to be making the judgment calls, in the future. And you need to be able to illustrate that not everyone's opinion is equally valuable when it comes to making design decisions. Design insight requires talent and skill. This contest before the usability test helps identify talent-- skill development can come later.

Again, the only way you'll get involved in the earlier stages of design is if you show you can do that part, and what it entails. Make alternatives, and show why they are better. Next time, you'll be at the table for that part of the job instead.

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 update was: The person must be liked well enough for people to want to work with him again...

While I enjoyed the post, I had some issues with the distinction between work vs. employer, or company. In my experience the distinction is really about "career at this company" vs. "the work I do." I've rarely seen a place where loyalty to the company is a major factor anymore (although I can think of one strong candidate in my employment history). When people talk critically about employee loyalty to the company, they really mean something more sinister about "fit" and "culture" and "not making waves." Look out for this rhetoric, it's usually covering for something else that's going on. But that's not the point here right now.

Career motivated people are a hair away from appearing motivated by the work they do, but it's a really important hair. They can be recognized by some similar signs as CPU's indicators of company loyalty:

• Excessive concern for what management thinks, or what the promoting, salary-raising decision-makers think
• Covering their asses behavior: blame assignment, rather than taking ownership and responsibility individually for tough problems that need resolution
• Star behavior: Taking credit and not giving it to others. Often excused by managers as "my team did it so I did it." Not quite what the team thinks...
• Competition for the plum jobs (some may be genuinely hard, but it's notably the ones that are visible to CEOs and Senior VPs that they go for)
• Wangling to get on the speaker list at important events attended by senior management; this may look like it's for "good" but often it's self-promotion
• Teamplay gets sacrificed for their ambition, when it's useful to them -- less pushy voices and personalities get the uglier tasks and less interesting roles if they have something to prove.
• Resume-building; a key distinguisher between loyalty to the company versus themselves -- they're figuring out how to make their tenure there useful to them for the next, better move.

This behavior, especially in a teamwork environment(see my old post about requirements for successful teams), can be fatal for morale of others. Unfortunately, it may be difficult to identify this behavior as different from dedication to the work itself, if no one is paying very close attention. Most of their managers probably aren't, actually, either because they have incomplete information, or aren't able to make this distinction. And some of the managers may fall into this category I've just described, which will make it even harder for them to tell that difference in their own employees or to think it important.

Sad postscript: Kathy Sierra at CPU has been receiving death threats. Her posts are always controversial to some, which is part of why she's a good read; but now she seems to be a target for it. It's hard not to read this as a response to her as an outspoken woman, rather than just an opinionated smart blogger.

Engineering Rewrites and Old Code

Closely related to my Balls o' Mud post about old code bases, the latest Silicon Valley Product Group blog posting is about the necessity of engineering "headroom" for code maintenance during product lifecycles. And about inevitable rewrites to scale, perform, and I'd say, accommodate design of new features, although the article doesn't focus on that issue per se.

I knew ebay had gone through growing pains, but the article suggests some absolute heroics in the form of two mid-growth rewrites of their code that barely touched their business performance. I know of some (plenty) UI designers who've left ebay because of their unwillingness to touch their UI (it sadly needs it), but I do applaud their engineers for their effectiveness at communicating the need to do code work to survive. From the SVPG article:

The deal with engineering goes like this. Product management takes 20% of the capacity right off the top and gives this to engineering to spend as they see fit – they might use it to rewrite, rearchitect or refactor problematic parts of the code base, or to swap out data base systems, improve system performance – whatever they believe is necessary to avoid ever having to come to the team and say “we need to stop and rewrite.” If you’re in really bad shape today, you might need to make this 30% or even more of the resources. I get nervous when I find teams that think they can get away with much less than 20%.

If you are currently in this situation, the truth is that your company may not survive this. But if you are to have a chance of pulling through, you’ll need to first do a realistic schedule and timeline for making the necessary changes that engineering identifies.

If your product is slow, hard to modify, and your code base is really old and hard to understand by your own developers, you should be worrying about your future in the business. Can the people you want to modify your product succeed in actually modifying the product without total internal collapse, at version N? Here's another pointer to that ball of mud article on software architecture growth issues.

Past and Current Employees and Your Reputation

As my current contract winds down, and a friend quits a job I once quit too, I've been thinking about how employees can affect your company "word of mouth." Just in time, Scott Berkun posted about why you should treat your contractors and temps well :-) Not that I have in any way had a bad time of any contract, but that's relevant to the overall topic here. Manage your reputation by taking care with your own staff.

Scott makes the point that interns and temps are potential future employees, are sources of networking for your future hires, and may be top notch in the idea department, especially since they bring in fresh perspectives. "Treat them like idiots in a box, and you’ll get idiots in a box. But give them a chance to outperform your expectations and your next star recruit might already be in your office." This is a regularly delivered message on Joel Spolsky's blog too.

Don't miss the terrific post from the guy who interned at Google, Microsoft, and Yahoo, and compared the three in a blog post with a small chart. :-) (He ended up taking a job at Yahoo.) Here's how my situation compares in an added column on the right:

Another subject of relevance is what I call the "Departure Story," or how you mutually end it with someone who is not happy working for you. My advice is not to let anyone leave suddenly, especially someone in contact with your customers; not because they will badmouth you, but because it will cause a crack in your coherence as a place that can be depended on to handle customers carefully. Imagine how that customer feels when their email to the old account bounces, and they had no warning that their contact was leaving for other pursuits? Redirecting their email to another account where someone else gets it is probably even worse; if there's any indication to that customer that the person they were in touch with had any issues at the company, this will be damaging to the company.

Sudden departures also affect the morale of other employees, just like a big riff will; they'll wonder what happened, how safe their position is, how much of an asshole you were or the boss was. Rumors and stories will inevitably get passed around. Regardless of whether the departee signs confidentiality exit papers, this is still going to happen. So is the conversation they have with their professional industry colleagues at the next conference about whether that's a good place to work or not.

Finally, if you treat a departing employee as if they're a risk, they're more likely to become one. Just like idiots in boxes.

While I was interviewing with a local company that had gone through some troubled times with lots of layoffs, I talked with current and former staff and heard an earful about their last year. It was all on condition of anonymity, and I was grateful to hear it. It made me a bit wary, I will say, and played a role in my decision process. As a manager, you need to know this is going to happen and it isn't something you can "discipline" or "threaten" out of your staff and contractors. Equally likely is the good rep and good word of mouth, if you handle them all well.

A lot of managers moan about how hard it is to hire good people. Sometimes the problem isn't the market, it's you. Checking your street reputation due to former employees and contractors might be a good idea. Someone might like you enough to tell you the truth. Then you can go about figuring out how to change your practices and image.

The current issue of Harvard Business Review has a thought-provoking piece on how companies can't be all things to all employees, but knowing what they are and capitalizing on that is a starting point in attracting the right people for your culture who won't end up telling friends, "It wasn't like it was described in the job ad, that's for sure!"

Organizing for Product Design and Production

I had an interesting chat yesterday with a manager in a large international company that is restructuring to support better innovative product creation. He asked my opinion on a number of topics, relevant to their effort:

• Matrix organization of cross-disciplinary teams: marketing, engineering, and operations, for instance. I suggested that at the innovation phase before product development, the team might look different and have different skills, such as design!
• Does long-distance collaboration really work during product design? I said it can, and that although video gets a bad rap, we used it effectively at Adobe in the same time zone. I am less sanguine about major timezone differences, and still a firm believer in regular face-to-face, especially at the start and during times of tension, for defusing it over a drink or meal. For designers, there's more artifact production to communicate ideas long-distance; and the whiteboard collaboration hasn't really been adequately replaced by any conference tools I've seen, but I'd love to be wrong if someone has a suggestion.
• Quality of product: Get it out or get it right? I said this depends on ability to absorb risk in a brand, and first to market vs. competitor situation. A first-to-market product can get a few things wrong, and still have the advantage. Not if they got the major things wrong, though, and destroyed their own business and can't absorb the hit. Soft launches and long betas are another tried and true method. Google seems to live on eternal betas -- but of course they did get search pretty much right, first, as far as state of that art goes now.
• Outsource concept design or do it inhouse: I said this depends on how much product innovation is meant to be a core competency. I think it should live in-house if it's meant to be core, because it's a risk to outsource all good idea creation. Also expensive.

It wasn't a specific question, but I pushed for the value of ethnograhic research for identifying new product areas and gaps in markets; and the value of design of both the industrial variety (closer and closer to home for software now) and the usability/interaction variety. The need to reward and remember failures is important here to encourage iteration and re-application of old ideas in new ways.

Joel's Quality of Software Teams; and Design

I'm a Joel Lover like many techies folks, and his job board is really tickling me. I just cruised the engineering ads (no, I'm not looking for a development job :-) and saw the the little questionnaire at the bottom of the page that measures the quality of the team hiring. Apparently people posting ads are answering honestly, which is excellent! And even more excellently, usability testing makes his list.

What would a similar test look like for hiring user experience designers, I wonder. A bunch would be similar, I think. I'd propose something like...

• Do you develop from specs written by designers?
• Do you have a design process with low fidelity work that is reviewed and refined before final specification is produced?
• Do you do usability testing during design or only after shipment?
• Do you change your design based on the results of user testing?
• Do you measure customer satisfaction with the product, including measures of user experience such as appeal, learnability, ease of use?
• Do designers talk to customers directly on a regular basis?
• Are developers involved in the design reviews and process?
• Does QA test for specification compliance?
• Is there a dialog about business requirements and product features that includes design staff?
• Do you require a design test and portfolio review during interviewing?
• Are other designers involved in interviewing designers?
• Are deadlines for specifications realistic and staged with multiple deliverables; or do you have single dates and one large spec document?
• Is your dev process sufficiently flexible to allow for design revisions without breaking everything and everyone?
• Are designers considered crucial to your business and to your developers? Regardless of the answer, how do you know if they are or not?

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

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.

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?

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:

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.

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).)

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.

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.

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...

The Top Ten Lies of Engineers

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

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

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

Berkun blog » Vista and Victimization and More

I've been catching up on some of my favorite reading after being away and then swamped at work -- today it's Scott Berkun.

In The Vista saga: an opinion, Scott gives his take on the delays of Vista at MS and what's being handled well or poorly, from his viewpoint as a former Windows PM. A couple points: "A slip is infinitely better than a panned product." and "Microsoft’s PR and public management of the Vista project has been reactive and weak." Here's a sample:

Centralized authority and MSFT culture. The most comical misperception about Microsoft is the management style - everyone think’s it’s a rigid hierarchy, when it’s mostly a consensus driven place. Everyone gets an opinion and senior managers are often more skilled at consensus management than leading teams. If there’s any one thing I’d point to for large failing projects is lack of successful central authority - With a project in trouble I’d move to centralize power in a smaller number of people and free them to run with the ball. The rub is that the culture doesn’t support this well - people still want a consensus mentality (something born of small team and start-up culture), they want to own their slice, even when it’s contributing to driving projects into the ground (or at least mediocrity). It’s in the fiber of the company and it’s hard to change.

Sinofsky is an inspired move. The MSFT culture, historically, is heavily polarized between Windows and Office. In my day Windows were the smart-ass cowboys who liked risks and breaking rules - not surprisingly Windows had a history of confused early projects that came together only on the home stretch. Office (again, in my day) were stereotypically smart, reliable, consistent A students, who won through plans more than passion. Sinofsky (formerly the Senior VP of Office, now VP of Windows) is the first major attempt I know of to bridge those philosophical and management differences: there’s something to be learned in both directions.

In another recent post, Berkun discusses a fascinating and cynical piece on Victimization Metrics for taking on projects.

Basically the idea is this (a now corrected paraphrase of his post): A = Number of problems you see
B = Number of Problems you don’t have the power to solve
B / A = Victimization ratio.

So if you work in an environment where you can point out 10 problems, but are only capable/empowered to solve 4 of them (so 6 you are powerless on), your victimization ratio is 6 / 10 = 60%.

Not being cynical by nature, Scott adds a couple factors, and inverts the ratio to call it the "empowerment ratio" instead. Nice reading and timely given my current project load. :-)

Finally, his next book is on innovation; he has asked for and gotten a number of recommendations that make interesting reading. (In another post, he summarizes the Amazon sales figures of his project management book over a year as correlated with essay posting and other publicity events --slashdot had the largest influence on Amazon sales figures. Nice.)

Ten things VPs never say

Scott Berkun posts about Ten things VPs never say, including: "Team A is more important than Team B," "the CEO and I disagree" (Leaders fear showing dissention, despite signs for those paying attention), "My morale is low," "I’m ending project X and here’s why," "No, I don’t want to be on the cover of Time." (To want to be a VP requires an ego. No person in the history of the corporation has been forced, at gunpoint, into executive status.)

All this entertainment aside, I've known a few nice VPs, especially at Mathworks (hi Roy if you're reading). (And I bet my new CEO would have said some of them as a VP, which is why I like him.)

[Updated to add: A VP reader of Berkun's blog took offense politely and Scott apologized for the stereotyping. One of the interesting things this VP cited was Joel's article The Development Abstraction Layer, about the infrastructure of management that enables delivering code to the customer, and the complexity of making it work well. It certainly made me think about the Design Abstraction Layer, and if/how that works -- but by Joel's analysis it's just a layer in the development management problem, which may in fact be correct thinking. Go read and see what you think.]

Motek, A Very Strange Software Company

I just read this article in the in-flight magazine on my way home from a short trip to Scotland: American Way Magazine: The Best Company to Work for in the World-Period.

As someone who needs at least a 3 day intro to a vacation to even start to relax, the European-style 5 weeks of vacation initially caught my eye and kept me reading. The rest of the story brought tears to my eyes (and I read a fair amount of business overview articles, for your average UI designer). A woman-owned company, with acknowledged lower salaries and internally published salary levels, in return for real quality of life outside the office? But that's not all.

Employees also know when an employee isn’t able to keep up with the workload. The result? Price offers a financial reward to employees who ask for help in order to stay on schedule. “The goal is to get the work done, not establish a star system,” she says.

Of course, it’s one thing to conjure up a cutting-edge culture and quite another to thrive amid relentless daily pressures. But Price hasn’t overlooked this aspect, either. While other companies talk about collaboration, Motek lives it. The company keeps a single to-do list... so that everyone is on the same page about priorities and the state of various projects. Anyone can enter an item, including customers and vendors. The list can include everything from ordering ink cartridges to customizing a specific function for a customer. Motek divvies up the tasks at meetings — and teams don’t pay any attention to who entered particular items.

The way Price sees it, the company’s success is a direct result of the money it invests in employees and of its commitment to developing a business structure that fosters knowledge-sharing and mutual goal-­setting. What’s more, “It’s amazing what a rejuvenated person brings back to the office, not just in terms of great new ideas but also in terms of enthusiasm and desire,” she explains. “The software industry’s idea that employees are entirely replaceable is absurd.” In fact, she believes it is precisely because of long hours and poor working conditions that today’s software is so buggy and behind schedule.

Apart from mourning that they are located in Beverly Hills (although I really do love my current job), it's now my goal to find other studies supporting her assertions. Let me know if you know of any...

Here's Motek's News page with links to many other articles about them.

Projects: Succeeded, "Challenged," Failed

The Standish Group have done numerous studies of software project success and failure rates over the last 10 years. They've observed some trends in project management suggesting things are marginally improving out there.

In 1995, their report identifies these key factors and associated weights contributing to project success:

SUCCESS CRITERIA	POINTS
1. User Involvement	19
2. Executive Management Support	16
3. Clear Statement of Requirements	15
4. Proper Planning	11
5. Realistic Expectations	10
6. Smaller Project Milestones	9
7. Competent Staff	8
8. Ownership	6
9. Clear Vision & Objectives	3
10. Hard-Working, Focused Staff	3
TOTAL	100

As you can see in the graphic below, in 1994 the the success rate for projects was only 16%, while "challenged" projects (over time and cost) accounted for 53%, and failed (canceled before completion) accounted for 31% of all projects. In 1998, 26% were successful. Then in 2004, we reached a 29% success rate. Project costs are higher and the success rates are lower for larger companies.

The 1995 piece has a scorecard to apply to your project to help you assess your potential for success. They're good questions (but a little intimidating even in 2006).

The 1999 report is quite sobering; they suggest that project size, team size, and project duration are the major factors correlated with success. They identify project management and standard infrastructure as crucial factors for team success. (Their comments on project management are well worth looking at, too, including the role of mentoring project managers.) I am quite sure that Scott Berkun would agree with them.

In 2001's report, they state that executive sponsorship replaced user involvement as the number one critical factor, because the IT world had caught on to the user involvement philosophy. Staunch business and management support now trump requirements analysis and user review of product design.

Finally, here is a telling quote about written communication on projects, from their original article:

Achieving the answers to solving project failure often lies in developing written communication such as problem statements, project plans, and detail specifications. However, one of the problems with any written communication is the participant's (reader's) level of understanding. As technologists, we think, write, and talk in a manner that is not readily grasped by many people outside our industry. Aside from sounding intimidating, you run the danger of the reader actually thinking they understand what you are saying, while your meaning may in fact be entirely different. To paraphrase the words of the English poet, Samuel Taylor Coleridge "Until you understand a reader's ignorance, presume yourself ignorant of his understanding". In other words, write the document devoid of all technical terms and pseudo technical terms. This includes words used by our industry, but rarely used outside our industry. Words like paradigm, metric, abstraction, and orthogonal, should not be used in any document if you want the normal reader to understand. Remember it is your job make the reader understand the plan. It is not your job to show how smart you are or to demonstrate that you can use big words.

Sadly, "phenomenological" is probably not a good word to put in a spec either.

Office Networks in Business Week

I've been catching up on some social network blogs, and have pointers to 2 short pieces I enjoyed in Business Week Online: IBM: Untangling Office Connections and The Office Chart That Really Counts.

In the former article, Kate Ehrlich at IBM Research notes that you want weak ties to fuel innovation, but strong ties to execute on it.

I think of the process of innovation as having three different phases: One is the generation of the ideas, and that's where you really need to have, not everybody in a group, but a few people who are connected to people who are outside. That's where you get these real "Wow, I never thought that something from that domain could be applied to this domain." So when you're talking about innovation, you've got to have somebody who can bring in the ideas from the outside.

In the second phase, you need to connect those people with others in the organization who are translators, who can say, "I can see that that idea might work in the company or group that you're in, but this is what we need in order to make it work for our product or our service or our process."

Then there's a third phase. You've translated it. You've got it set up. Then it's the delivery, and the delivery now is internally within the group. Now you want very strong ties between people. In network parlance, with innovation, you want weak ties, where people are more connected to those outside the group. [In the delivery phase,] you need strong ties in order to get the innovation executed.

In my more cynical moments, I question whether most businesses really want their employees innovating -- if they're not a research lab, that is. Most employees have too much ordinary work to do to take time to innovate and innovation from the ground up is hard to manage and control. But then I remember that finding a new way to do your work is innovation, too.

The latter piece has some excellent observations about the potential dangers of showing off who is connected to whom by social network diagrams. The same concerns apply to many visualizations of statistics in office life, of course.

For all of the benefits, charting informal networks can be disruptive. "Leaders feel pretty threatened by this," says Katzenbach principal Zia Khan, speaking of people who hold high perches on the organization chart but are more isolated on the informal map... It's O.K. for some people, such as those who spend a lot of time with customers or have expertise in niche areas, to show up on the periphery of the web. Maps can also highlight which employees might be too connected and therefore a potential bottleneck.

Confidentiality is also a touchy issue. A map that reveals who is well-connected and who is not can be destructive if it is shared too widely. "I know who I named, but when I look at the map, I might see [that person] didn't name me back," says Tracy Cox, director of enterprise integration at aerospace and defense contractor Raytheon Co. Now, says Cox, who does network analyses for the company's seven businesses, that hypothetical employee "knows that he is not valuable to his boss. And not only does he know it, but 50 of his closest friends know it, too."

This came up for me during my research days; and needless to say, it was an issue even if they didn't know who was A or B in the chart -- the map itself was frightening because everyone suspected they might be the X on the fringe.

Is Your Boss a Psychopath?

At the risk of my boss reading this, here's an oldie but a goodie: Is Your Boss a Psychopath?

Corporate psychopaths score high on Factor 1, the "selfish, callous, and remorseless use of others" category. It includes eight traits: glibness and superficial charm; grandiose sense of self-worth; pathological lying; conning and manipulativeness; lack of remorse or guilt; shallow affect (i.e., a coldness covered up by dramatic emotional displays that are actually playacting); callousness and lack of empathy; and the failure to accept responsibility for one's own actions. Sound like anyone you know? (Corporate psychopaths score only low to moderate on Factor 2, which pinpoints "chronically unstable, antisocial, and socially deviant lifestyle," the hallmarks of people who wind up in jail for rougher crimes than creative accounting.)

A good point is made in that some psychopaths are created, not born that way, and American individualistic corporate culture is a petri dish for this type of behavior. They get ahead in part because of their traits.

Of course, cynics might say that it can be an advantage to lack a conscience. That's probably why major investors installed Dunlap as the CEO of Sunbeam: He had no qualms about decimating the workforce to impress Wall Street. One reason outside executives get brought into troubled companies is that they lack the emotional stake in either the enterprise or its people. It's easier for them to act callously and remorselessly, which is exactly what their backers want.

The good news is that a productive narcissist makes a great balance for an executive psychopath. Or a productive obsessive. It's all just one big mental hospital in a large corporation. (See the related NY Times short on presidents with mental illness symptoms.)

Joel on Interviewing, Me on Performance.

Joel Spolsky's latest post is on interviewing interns for Fog Creek. I love how seriously he takes this, but with the same caveats he quotes as getting from other people. Bravo that last year's interns wrote their fastest growing business product almost by themselves. That's a good use of interns! (And in an industry full of big software companies that just acquire existing products and can't build them from scratch anymore, it's refreshing.)

Joel's main goal in hiring is to get "Smart people, who get things done." (See his Guerrilla Guide to Interviewing if you haven't read it.) This makes much sense to me. Operationalizing it during interviews will mean different things to different teams and disciplines, I think. His techniques for screening developers aren't exactly the ones I'd use on UI designers, but they're not too far off. (I like giving design problems, asking for design evaluation of existing products or mockups, examples of work process and deliverables, and willingness and ability to do the boring and hard stuff in order to push work through to completion. Checking ability and interest in learning is part of this last item.)

I was talking to a friend recently about how academic journal and conference reviews are "how professionals enact their discipline," by setting up the boundaries they want on what counts as quality work and what is worth letting in to extend or challenge their field. (It takes a brave reviewer, even in a cross-disciplinary field like HCI, to recognize something from a very different perspective as a valuable contribution to the discipline.) The same could be said for the hiring process, although far less abstractly -- and it's a little more tactical. Your target processes are always going to be moving-- hopefully improving-- but you have to hire for short term success as well as investing in the future.

Hiring is hard in part because most folks aren't good at articulating what needs to get done, and how to evaluate people for those abilities. So often the emphasis ends up on wishy-washy and dangerous "cultural fit" terms, because the objective measures are missing. Performance reviews, which are obviously (or maybe not!) related to the hiring problem, are prone to the same failures; a lack of understanding of what needs to be done in an organization can lead to subjective personality measures instead of objective measures of what got done and how and what we need to do next year. (I sometimes wonder: what if, instead of the traditional performance review methods HR depts foist on us, we were to do the interview process all over again -- with a focus on what got done in the last year, instead of previous company work? No, I don't mean we fire people who get thumbs down; but we evaluate concrete work as if we hadn't spent the year with them disagreeing or drinking after hours and learning about their cheating ways or charity contributions.)

It makes sense to me that in organizations with a poor understanding of what their business is, with an incomplete understanding of how to achieve and how to measure success, you'll also find questionable (and confused) hiring and equally poor performance review processes. But in companies like Joel's that know how to measure success, hiring, retaining, and evaluation of employees is downright rational.

Fred Brooks and Late Projects

Scott Berkun, rapidly becoming one of my favorite reads in the internet for his sagacity about software projects, points to an interview with the legendary Fred Brooks in Fortune magazine.Fred is of course famous for The Mythical Man Month, in which he argues Brooks's Law: "Adding people to a late software project makes it later."

The article itself has some stellar bits of quotage in it, including these:

Brooks' law depends heavily on the amount of information that has to be communicated. So the argument is that if you add people to a project that you already know is late, which means you're at least in the middle of the project, you have to repartition the work.... Sometimes that can be done by subdividing the existing units, but sometimes you have to move boundaries. That's a lot of work. The next thing is, you have to train the new people.

...Peter Fagg, a really wise System/360 engineering manager, gave very sound advice: "Take no small slips." That is, if you're going to take a slip, get everybody onboard, get organized, and take a six-month slip, even though you may at the moment feel as if you're only four months late.

...The other was when I was a new IBM employee and heard Vin Learson, a VP at the time, later CEO. He said, "The problem is not to make the right decision; it's to make the decision right." ...I came to understand that he was talking from an executive-level point of view. ... Either way can be made to work, but it's very important to pick one and then go whole hog. A counter-example is IBM's PL/I language. They adopted it, they backed it, and then there was a spell when they decided maybe it wasn't going to be the language. And then they decided maybe it was going to be. As a consequence, most customers didn't stick with it. The wishy-washiness killed it, I think. Whatever you're doing, you'd better go do it.

Visibly wishy-washy corporate "positions" can be fatal or at least very damaging to a business. But it's unfortunately pretty common to hear one's customers say, "We're not sure what you're telling us to do" or "What are you recommending here, you have us confused." Brooks has some comments on open source that are interesting too.

Scott notes that there are caveats or objections to the original Brooks Law linking project lateness and adding manpower (item summary here, he says more about each): It depends who the manpower is. Some teams can absorb more change than others. There are worse things than being later. (Producing better quality work might justify being later, if you've identified a role or expertise that's required.)It depends on why the project was late to begin with. Adding people can be combined with other management action (...such as cut or reorganize work across the project, improve tools and equipment, throw a social event to accelerate team relationships, etc.).

Smart stuff.

Getting it Right (or Wrong, at Blink)

An interesting post-failure analysis of why social bookmarking site Blink failed while del.ico.us has succeeded. Ari blames product design, although in the comments some people blame the development decisions, the growth of the company, the loss of focus, the ad and registration burdens... in short, all the dot com era fools are to blame.

The worst decisions seem to have been using folders, leading to an insupportable number of performance and downstream design problems impacting user experience; and then the decision to make folders of links private by default instead of public. I think tagging is prone to issues similar to folder creation, but the immediate visibility of content on del.ico.us, instead of just the containers, makes the design work better. There's a real immediate payoff without a lot of digging when you look around on del.ico.us.

My links are public, if you want to browse them. See sidebar.

Microsoft hires user interface guru

This just in from steve: Microsoft hires user interface guru Bill Buxton, formerly of Alias Wavefront and long HCI history. He's being hired by MS Research, of course, and will work on ubiquitous computing ("ubicomp"), as so many people do these days.

This is an entertaining paragraph close: Buxton in the past has been critical of software companies' failure to integrate appropriate design processes into products. However, he said that Microsoft is hiring more designers, which is encouraging. "My sense is that Microsoft is in transition from an engineering-led company to as much a design-led company," he said. "There are more designers at Microsoft on any single team as there were, not too long ago, in the entire company. It's a wonderful change."

I followed up his criticism, and found this right-on abstract for a talk he gave at Graphics Interface 2005 on exactly this topic:

...We are now seeing articles appearing that are warning about the danger of a schism in user-centred design (UCD) between the ethnography and usability camps. (See for example the spring issue of Interactions.) The apparent voice of reason points out that both have distinct roles: ethnography can feed design, while usability can evaluate it. All very nice as far as it goes. But what is missing is any detailed consideration of who actually does the design. There is something missing.

In this talk I want to speak to both the role and nature of design in the overall process. Along the way, I will argue a few points, including the claim that usability and ethnography are distinct from design. Relevant to design? Yes. Design? Decidedly not. I will also speak to the whole nature of iterative design, and argue why iterative and incremental software engineering practices such as extreme programming and agile software techniques are not the same as design. Again, relevant? Yes. Design? Absolutely not.

As I will show, the software industry has an abysmal record at creating new products. I will argue that the absence of anything vaguely resembling a design process is a key reason. My talk is directed at altering this situation.

I can't wait to see what he thinks about working at Microsoft after a couple of years! Now if only more companies understood the distinction between usability and design and how to operationally overcome the issue in a way that led to product success.

Reasons ease of use doesn't happen

Martha Stewart has her 10 Rules for running a business, and Scott Berkun has 14 reasons Why Ease of Use Doesn't Happen on Engineering Projects. I wanted to cheer out loud as I reread this. Maybe it's just because I've lived through so many of them and some so recently.

Take 2, "ease of use is not an actionable goal." If there's no criteria for success, it's easy to stop paying attention to this, even if you thought it was an objective rather than lip service to "doing the right thing." "When stressed, most humans prefer to focus on things that are tangible and well defined, rather than vague and poorly defined. So even if ease of use is an explicit goal of a project, if it is not broken down into discrete and measurable pieces, or tasks and work items for someone to do, it will remain an abstract idea that no one feels pressure to fulfill."

Item 3, "decision makers don't see the tradeoffs," is probably one of the most important but most difficult to manage. Because it requires management to be bought in and innovative in software processes. "To get an easy to use product, a different kind of thinking and planning is required.... Team leaders have to recognize how ease of use effects other engineering decisions, and must modify their decision making process to account for it." This is echoed in #7, "Technical focus dominates the view of the project," wherein team leaders get obsessed by brilliant architecture and leave the UI to last or second place. Hey, your customers don't care how brilliantly it's architected, even if it saves you time later. "Wise engineers understand when they don't have the right sensibilities for certain kinds of decisions, and know to yield them to someone more appropriate. An arrogant engineer will tend to assume that what they do not understand must be trivial, or worse, doesn’t exist at all, and will proceed to apply their hammer to things that are definitely not nails."

"Confusion over who the customer is" vs. client vs. user is a good reminder issue. Often the person buying it isn't the person using it, and more often, the person building it isn't really representative of all users, even if they think they are or have some domain expertise.

#8, "Diffusion of design authority (Too many cooks)," is reminiscent of the post I made recently about free software usability issues; "When authority over the design of a project is distributed across too many individuals, the likelihood of a high quality final design decreases. The worst approach is design by committee, where lots of people who don’t have shared goals or shared high level ideas, get in a room and torture each other with compromises until mediocre results that no one likes, but everyone can just barely manage to live with, are achieved." Good design requires good design leadership, unified vision ownership, not widgets built separately thrown together into a patchwork at the end of the day. Good design isn't just the sum of all the features you are adding to the latest release. "In either case, being an effective designer, or design authority, means the ability to: generate good ideas (creative), convince others of an idea (conviction and communication), and integrate the best ideas and feedback that others around them have (mature egos). Good design leaders are therefore quite rare." Of course, you have to know you need them and how to identify them, in order to hire them.

This is closely related to point #12, "The wrong people are involved," the case in which the wrong people own the design decisions. Even on teams with UI designers, I've watched this play out in team dynamic. And it's worse when there's no recognized UI design authority or the wrong person has it for the problem at hand. "The craft of designing interfaces is a unique skill. It requires an individual to have at least four personal attributes: compassion for other people, abstract problem solving skills, the ability to communicate or detail web/software design ideas, and experience crafting designs and watching people use them. Giving design authority to programmers or project managers without these traits is unlikely to work out well."

"Feature design vs. task design," #9, is the reminder that just because you have the bullet on the box doesn't mean anyone can achieve a work goal with it. Did your customer do something real with it? (This could be one of your actionable criteria for #2 above.)

#11, "General incompetence," is another good reminder -- teams might suck, and leaders might suck, despite all best intentions and well-produced documents. Check your team chemistry and ability to Get Things Done Well as a Group.

Well, they're all excellent points, and I think it's worthwhile using them as a diagnosis form for your organization if you think poor usability is a problem you suffer from. The Root Causes may be deeper and more diverse than you thought, but Scott has suggestions for almost all of the issues he lists. If you don't know if you suffer from poor usability, you're even one step behind the need to diagnose why you've got it -- and trust me, you're probably very sick.

Why Free Software usability tends to suck

Matt Thomas, a Mozilla contributor, has some interesting observations about design on free software projects. If you're a fan of evolutionary design by accretion and multitudes, you might want to check out his concerns in Why Free Software usability tends to suck. (It was picked up by a number of people including Joel back in the day.)

One of his points will be controversial to some people, I think: Every contributor to the project tries to take part in the interface design, regardless of how little they know about the subject. And once you have more than one designer, you get inconsistency, both in vision and in detail. The quality of an interface design is inversely proportional to the number of designers.

I don't think this is necessarily true in a non-opensource environment; and, to be more concrete, in a software environment where people aren't argumentative prima donnas, communicate regularly, and reach consensus before implementation of the crucial features. But when there's frequent handoff of work, a tendency towards grandstanding or power plays in the design phase, or poor communication, it will be true.

Updated to add: He has a sequel article based on comments he got on the original, at Why Free Software usability tends to suck even more. His points continue to be good, including the inspiring last comment, which I think is also is true in any organization: As with previous critiques of Free Software, each of these weaknesses will become less of an issue proportionally to the number of contributors who read about them, and learn to recognize and combat them.

In software companies, this is known as "risk management." Doing that well in a design process requires recognizing the failure modes, worrying about them, and making yourself immune to them.

Scott Berkun on Train Wrecks

A week or so ago, I went with a couple colleagues to hear Scott Berkun talk on software project train wrecks. It was entertaining, albeit rather painful, for people who have been victims or occasionally contributors to such disasters.

Like any UI guy worth his paycheck, Scott notes that the crux of the software design matter is often team management and project management. I find it not the least surprising that he and Joel Spolsky, also noted for his UI and design observations, are both so sensible on the topic of project management. Scott's new book, The Art of Project Management, is getting raves on Amazon, and I'm cheering as I read it. (I'm not sure you'll recognize the insights for what they're worth if you haven't lived through the kinds of process issues he describes, but I find him right on.)

Scott's slides are here. His diagnostics for train wreck projects are these:

• We know we won’t meet goals
• No one is happy / Everyone is frustrated
• Things keep changing, but there is little progress
• We don’t know if we’ll be able to solve them
• We don’t agree on the existence of problems
• We don’t know whose job it is to solve them

Sound familiar? For some people, this might describe entire companies! He has more specific criteria for design disasters, which may be even more familiar, since design is so hard to do well (depending as it does on more factors than simple project management):

• Disconnect between the “design” and what’s being built
• No one knows what the “design” is
• No one knows what the goals are
• There are competing designs being built simultaneously, and unintentionally, by different people
• The design has no possibility of satisfying goals: Customer / Technology / Business;
• Note: People with different goals will define disasters differently.

And finally, he hit my favorite subject, good teamwork. Good teams:

• Avoid many problems and rat holes
• Are good at recognizing/communicating issues
• Are good at using each other to help solve its problems
• Teach each other how to find and resolve problems
• Make mistakes, but are encouraged to learn (not hide)
• NOTE: One team’s train wreck is another team’s good day.

I was surprised not to find my favorite study of effective teamwork (Teamwork: What Must Go Right, What Can Go Wrong) in his bibliography.

Update: Here's another good review of Scott's book.

Networked Governance: Network & Teams

Harvard University has a Program on Networked Governance, on whose site I found some nice links on networks and teams. I thoroughly enjoyed the literature review in their first article link, Building Effective Intra-Organizational Networks: The Role of Teams (pdf). The starting observation is that there hasn't been a lot of research cross-over between people studying social network analysis (SNA) and effective teamwork in organizations.

As a tourist in both fields, I found the literature review and the points of contrast and comparison very interesting. It's a good intro to both fields.

• Bavelas and his colleagues at MIT conducted experimental analyses of how communication patterns among teammates influenced team effectiveness ... When the information was simple, centralized communication was optimal. When the information was complex, centralized communication was dysfunctional.[Me: For decentralized communication to work, the network must be highly functional.]
• The paradigmatic focus of team research is on the task performance of a small group with a clear and well-defined boundary (Alderfer, 1977) “Clear and well-defined” means that team members and outsiders know who is on and who is off the team (Hackman, 1990). This is a critical element of the very definition of a team. [Me: This is also the in-group/out-group issue I found in the community studies literature in my dissertation research. Individuals who are shared across multiple teams may have a harder time identifying with any one team, and this may impact productivity or team relationships.]
• For teams with little autonomy or with overloaded team members, communication initiated by the external environment negatively affected team performance. [I guess this includes management wrenches thrown in the game very late...]
• Do team members know each other before the team exists? Jehn & Shah (1997) found differences in intra-team communication when they compared teams composed of friends to teams composed of acquaintances. [Not surprising. Check who has lunch with each other!]
• We know that a team’s success or failure can influence subsequent feelings of cohesiveness among teammates (Turner, Hogg, & Smith, 1984). One possibility is that misery (lack of success) breeds company (connectedness). Another possibility is that successful collaborations result in increased communication. Lack of success may lead to a vicious cycle of failure, leading to disconnectedness, leading to more failure, and so on. [As a manager I would think hard about retaining the same team members in a context where their first product was seen as having been a failure... or where they thought it was.]
• While knowledge networks describe who knows what, each individual in the organization also has his/her own perception of who knows what, or a “cognitive knowledge network” (Contractor, Zink, & Chan, 1998). Cognitive knowledge networks are a combination of knowing who knows who, and who knows what – i.e. who knows who knows what. Cognitive knowledge networks vary in their accuracy and completeness (Contractor et al.), where higher levels of accuracy can be expected to result in greater access to the knowledge in the network. [An environment where people don't know what other people know, or who knows what is a risky environment for the success of a teams and individuals.]
• Another mechanism social systems have that regulates individual tendencies toward noncooperative behavior is the possibility of continued relationships, because the fruits of future collaboration are at stake (Axelrod, 1981). ... We would expect teams made up of relationships with a greater expected duration will suffer from less free riding. When one free-riding team member can “crash” the entire team, and free riding is thus a dangerous risk, a desirable network will feature high levels of embeddedness, strong ties within the team, and expectations for future interaction. [Free riding, of course, is slacking off, in a work context. So, if the team hasn't felt it has been a failure, the existence of the group over time encourages individual performance and communication.]
• When a manager assigns people to teams, he/she is molding the social capital of the organization. .. There are two overarching points here: (1) when assigning people to teams, managers should consider the impact of a team on the organization’s long term social capital; and (2) managers should consider viewing social capital the same way they view other types of capital: it may need to be amortized over time. Under certain conditions, it may even be worth sacrificing some short-run team performance for the sake of fostering long-run organizational performance.

I really enjoyed this article, but then I'm a great tourist.

Groups and Teams and Growing Pains

I've linked before to Big Dog's Leadership page, which summarizes the stages of team development described in Tuckman's classic "Developmental Sequence in Small Groups."

If you've got deja vu because you remember my post, well, so do I, since I'm going through the same phenomena yet again with a new group-- supporting how universal his observations were. Tuckman's stages are these, named with silly names (I'm quoting from here) :

• Forming: The group gets to know each other. It's non-threatening. The major task functions also concern orientation. Members attempt to become oriented to the tasks as well as to one another. Discussion centers around defining the scope of the task, how to approach it, and similar concerns.
• Storming (my favorite because it's the one I always notice and hate): Because of "fear of exposure" or "fear of failure," there will be an increased desire for structural clarification and commitment. Although conflicts may or may not surface as group issues, they do exist. Questions will arise about who is going to be responsible for what, what the rules are, what the reward system is, and what criteria for evaluation are. These reflect conflicts over leadership, structure, power, and authority. There may be wide swings in members’ behavior based on emerging issues of competition and hostilities.
• Norming: Group members are engaged in active acknowledgment of all members’ contributions, community building and maintenance, and solving of group issues. Members are willing to change theirpreconceived ideas or opinions on the basis of facts presented by other members, and they actively ask questions of one another. Leadership is shared, and cliques dissolve. When members begin to know-and identify with-one another, the level of trust in their personal relations contributes to the development of group cohesion. It is during this stage of development (assuming the group gets this far) that people begin to experience a sense of group belonging and a feeling of relief as a result of resolving interpersonal conflicts.
• Performing: The Performing stage is not reached by all groups. If group members are able to evolve to stage four, their capacity, range, and depth of personal relations expand to true interdependence. In this stage, people can work independently, in subgroups, or as a total unit with equal facility....Members are both highly task oriented and highly people oriented. There is unity: group identity is complete, group morale is high, and group loyalty is intense. The task function becomes genuine problem solving, leading toward optimal solutions and optimum group development. There is support for experimentation in solving problems and an emphasis on achievement. The overall goal is productivity through problem solving and work.

The Big Dog site points out that groups aren't teams, and the above stages really characterize the formation of teams that work towards a known, shared goal.

While teams have an identity, groups do not. It is almost impossible to establish the sense of cohesion that characterizes a team without this fundamental step. A team has a clear understanding about what constitutes the team's 'work' and why it is important. They can describe a picture of what the team needs to achieve, and the norms and values that will guide them. Teams have an esprit that shows a sense of bonding and camaraderie. Esprit is the spirit, soul, and state of mind of the team. It is the overall consciousness of the team that a person identifies with and feels a part of. Individuals begin using "we" more than "me."

The formation of teams requires some special commitments -- everyone knows everyone is on board and working for the same goal; they can be relied on. If some of the members aren't reliable, or have split loyalties and agendas, there's not going to be a real team at the end of the day. There are lots of potential barriers, including prior history; I think I'm currently part of a subclique in the new group composed of survivors of another successful team (where some group members evolved to a real team and others dropped out); we're dubious about whether the new group will become a team, given what has gone before and who we're missing now.

Teamwork is hard to get right, that's all there is to it.

Next-Gen Tools in Global Software Development

Another link from Barney's: Barney Pell's Weblog: VC Taskforce on Next-Gen Tools in Global Software Development. The topics covered with Barney's great notes are the risks of outsourcing, getting requirements wrong (a costly problem made worse in distributed development), and investing in software tools.

Some of Barney's big takeaways from the panel discussion:

• Individual programmer productivity is always nonuniform. Some programmers are 10 or even 100 times as productive as others.
• The results of outsourcing are often disappointing
• A recurring theme in the panel was the difficulty and importance of getting software requirements right. Despite all the improvements in tools and processees for developers, there have been limited improvements in the way people create and validate the requirements in the first place. Errors in requirements ripple through the downstream flow and get more expensive to fix the later they are caught.

I contend that a good user-centered design process that starts during requirements gathering will achieve the results that are wanted, assuming the business has a goal that's addressing a real user need. A good designer helps bridge that communication gap between business analysts and "the IT folks who got it wrong." More of Barney's notes:

"Do your business people and IT people understand each other? Answer to this is usually 'no.' The problem: Missing, ambiguous and contradictory requirements. 60-80% of project failures can be attributed to requirements errors. at the very front of the process. not the arch, dev, or testers! The biz people say you didn't understand, the IT guys say you didn't explain. Scope creep and rework usually mean you didn't find the errors it the beginning; Good requirements are hard. Requirements definition and validation cycle: informal primarily text requirements -> spec -> formal spec documents -> validation -> visual inspection and review of spec for errors -> elicitation. This is a laborious process, with error detection that's bad."

Almost every usability practitioner in industry or consulting moans about "not being involved early enough." That moan is usually because the problem is with the requirements, on a project that's already made it to the point where it's too late to change direction....

Educating UI Designers

In 2004, I gave a talk at UW about user interface design which consisted of a long wish-list for the education of future generations of UI designer colleagues. Some of it was based on conversations with junior colleagues at Adobe, including things they wished they'd been told or taught before getting into the field. Other items were based on my own cross-over from research to practice, and the sad gulf I see between the two. A few were based on my growing belief that design skill is the important frontier for education, hard though that may be to conquer.

The condensed form of the "please teach them" list includes this motley assortment:

Teach them… The Language of Business & Marketing instead of HCI & UCD; Teach Them… Product Design instead of Interface Design, If You Can; Teach Them… Usability Methods; Teach them… How to Determine Appropriate Study Methods; Teach Them… To Characterize their Customers; Teach them… To Identify and Characterize Problems; Teach them… To Review and Critique Designs; Teach Them… Different Kinds of “Design”; Teach them… Design for Multiple Devices; Teach Them… To do Fast Low-Fi Design; Teach Them… To Prepare Multiple Deliverables; Teach them… To Recognize the Value of Multiple Levels of Abstraction; Teach them… To Present Their Design Work; Teach them… To Find and Interpret Previous Research; Teach them… To Relate In-House Research to Design; Teach them… Justify without Defensiveness; Teach them… Software Development Lifecycle Models; Teach Them… How to Interview; Teach them… To Drive Projects; Teach them… Most Design Happens in Committees; Teach Them… Public Speaking; Teach them… To Study Their Own Organization; Teach them… To be Solid Experts but not Shrill Evangelists; Teach them… Organizational Planning; Teach them… To Know and Evaluate Books on Design; Teach them… The Difference Between Peers and Resources.

In case it's of interest, I've put my powerpoint slides up at Teaching UI Design and HCI. ("HCI" is a common label for the academic cross-disciplinary field of human-computer interaction, which usually includes usability and user interface design, as well as research and innovative interface engineering.)

Can Usability Scale Up?

At last week's CHI conference, there was a panel "debate" on usability that I didn't think entirely effective, in that it was Jared Spool being provocative and little interesting disagreement from Eric Schaffer of Human Factors International. But I did find it challenging and thought-provoking to hear Jared complain (yet again) about this stuff, so I'm recapping here.

Jared's contention is that usability departments don't scale -- hiring more usability professionals doesn't make for more usable products. He trots out dubious statistics about big name companies (MS) employing huge numbers of usability folks and still having very poor websites; and hotshot firms like Amazon with few or no usability staff producing famously usable, standards setting sites.

His points come down to these, from my summary notes:

1. More usability staff doesn't necessarily (or often?) equal better usability. (But his numbers from various companies were faulty, and people called him on this.)
2. Good usability often means good design culture, not good testing culture. More people doesn't mean good design.
3. ROI isn't calculated and monitored by usability departments; this is dangerous in riffing climates.
4. Are we an engineering discipline or a craft? We want to claim both and don't provide the mechanism and support for either for our profession. "Engineering" means standard skillsets and repeatable results; "craft" means some people are just better than others and portfolios matter.
5. Process quality in usability is important.
6. When usability is effective, are we effective because of our methods and skills and training, or because a company that hires us is thinking about new things and considering them at the same time and could do it just as well without us: customer needs and feedback, firm marketing goals, good beta testing feedback, design process, quality.

Item 2 is his most unexamined, unsupported point and yet the one I also agree with most. He's flippant about what "good design culture" entails and how it works. Yes, evaluation and design aren't the same thing, but they also aren't simply separable either. And good design itself is a complex and difficult issue in environments where employees have diverse skill sets, engineering compromises are required to make deadlines and marketing demands the impossible -- in short, where multiple stakeholders are responsible for implementing the many parts of a large system (who often disagree on the goals or the "design" to achieve them). Design is hard to do well, even in a company with supporting usability staff and cooperative players working in development and management. The cats all need to get along.

Item 4: He's just correct about this. But since design and evaluation are often practiced by the same professional, it's not clear we need to be either an engineering discipline or a craft and frankly we often have to be both. Not everyone is going to be good at both activities, though. And as an audience member said, it's certainly true that some engineers are better than others, and it's also true that at the architectural level of engineering, it's really design that's going on.

Item 6 is disturbing. I worry about this regularly, especially faced with teams that don't really need much help, for whom I'm kind of an expensive waste of company money. Where's the value add? At least I don't think my stone is magic, when it comes to testing products. Jared told the stone soup fairy tale, in which the soldier with the stone knows full well it's the vegetables that make it good, but coerces the townspeople into cooking, and then he moves on with his stone to the next town. Jared thinks usability engineers think they're really making good soup because of their magic stones, and aren't seeing the vegetables too.

GUI Developer Position

I'm pointing this opening out to folks of the Java and UI programming persuasion. It's a great team and a great product, and absolutely cutting edge stuff. The UI challenges are only getting more fun as it evolves (no, I really mean it -- there's a big "whoa, cool!" factor with every other functionality addition). I'd do it myself if I had any serious Java under my belt.

Anyone know anyone looking, in the Boston area or even elsewhere? Job ad here: Mathworks GUI Developer

Invisible Work, a Short Essay

Talking to a colleague yesterday about design and usability work, I used the phrase "invisible work" a few times and he said he wasn't familiar with it. I gave a short not-very-political explanation, and now I'm delving into it a bit further. Consider this an infomercial or something.

A 1999 issue of Computer Supported Cooperative Work (CSCW) was dedicated to this subject. ("CSCW" is more or less a subdiscipline of the research arm of the field of human-computer interaction, which itself broadly covers aspects of interface design, product design, and usability methods.)Here's the Introduction to the journal, which summarizes the basic topic they covered:

This special issue documents four kinds of invisible work: (1) work done in invisible places, such as the highly skilled behind-the-scenes work of reference librarians, (2) work defined as routine or manual that actually requires considerable problem solving and knowledge, such as the work of telephone operators, (3) work done by invisible people such as domestics, and (4) informal work processes that are not part of anybody's job description but which are crucial for the collective functioning of the workplace, such as regular but open-ended meetings without a specific agenda, informal conversations, gossip, humor, storytelling.

The way I actually used the term yesterday was in reference to another kind of invisible work, I think more formalizable than (4): the shadow job, the job you do that doesn't at all match your job description, but more or less has the same end goal. It's the job you have to do to get your job done, and the more it doesn't match your job description, the more dysfunctional something is (or might be) in the company: hiring and evaluation of candidates may not be oriented correctly if the shadow job is done by everyone, or team dynamics may be screwed up if it's only one person doing the shadow job out of the crowd with similar job titles. Perhaps the company doesn't know the categories of work that could exist or need to be done by someone, because they haven't got those activity classifiers in their sights yet. To me, it comes down to an ethnographic research issue: what's labelled vs. what's not, and why? What are the missing vocabulary items?

One of the articles in this issue gets close to another topic dear to my heart, the shadow work involved in the user interview/usability test/qualitative data analysis. It just happens to be about ethnography here:

In her paper, "'It's Just a Matter of Common Sense': Ethnography as Invisible Work," Diana Forsythe turns the analytical lens on ethnographers--those who have made significant contributions to uncovering everyone else's invisible work. Forsythe notes with irony that now that ethnographers have convinced researchers and corporations of the value of ethnographic work in technology design, they face a new and unexpected problem: appropriation of their methods. Ethnography does look easy. It's just talking to people, right?!... Drawing on Star's concept of "deletion," Forsythe observes how certain kinds of activities are "deleted," or simply not considered salient, from various kinds of accounts....For example, Forsythe reports from her studies of artificial intelligence researchers how technical people describe the work they do in terms of programming or system design, but consistently delete social activities such as meetings and other kinds of social interaction. The work would not get done without these interactions, but they are deleted by the researchers as inferior to "the real work."

Lots of usability professionals (and UI designers) discuss and have to shrug away this issue in practice; it's better to have 4 developers who've never had a course in interviewing visit the customer alone and bring back enthusiastic (if noisy) stories than to have one usability professional interview a dozen people and return with carefully analysed data that doesn't interest anyone else because they didn't get it viscerally for themselves. And it's better to have everyone participate in usability testing and hear the data first hand even if the signal gets garbled, than to have one person attempt to rein in the wild horses and sour everyone on the practice at the same time. There's usually no time to give people a crash course in methods, after all. We just mope about this at conferences with our colleagues and buck each other up over cocktails.

Invisible work is certainly a problem even for folks in high status positions doing what's seen as the "real work." I've recently had conversations with a few developers about their own invisible work; some of them need cocktails at conferences as well, I think.

(On a personal note, Diana Forsythe was very important to me as a role model and colleague when I was in grad school; she died in a hiking accident in Alaska a year later, an enormous blow to me and to an entire discipline.)

How Yahoo Got Its Mojo Back

I don't know if the mojo is back or never actually left. I'm always distrustful of hype over substance, because in only 15 years I've already seen things come and go that were in or out with the press on alternate days; but here's someone claiming Yahoo is back and looking cool to us again. (Hey: I posted about Yahoo's UED jobs and VP of UED before that flickr buyout happened. I'd like to say I saw something coming from the pulse.)

See Om Malik on Broadband: How Yahoo Got Its Mojo Back. Note the mention for their beta for Yahoo 360, a combined photo and blogging effort, perhaps trying to fix the weaknesses in LJ and in their own communities effort, while competing with blogger. At least I hope, if they've done their usual decent requirements analysis. (Posting photos in LJ was a problem that many people in my blog survey identified as needing improvement.)

Yahoo's UED Jobs

I keep tabs on jobs in my field as a way of feeling the pulse of the industry. They tell you a lot about the corporate situation and the company vision; and sometimes, if you read between the lines, you can tell how healthy their internal design and usability efforts are. Most of the hot industry jobs right now are interaction design or information architecture; there aren't that many strictly "usability evaluation" jobs now (this has been noted on a contracting mailing list I'm on as well). Except at Yahoo. They've got 36 jobs open in their User Experience Design category, which encompasses interaction design, visual design, web programming, and user research, which they are now calling "Design Research." I like this title, in that it focuses better on the deliverables and end-goal of research in usability.

Some of the key responsibilities for this role include:

• Responsible for the user research, including planning and running usability studies, benchmark studies, competitive evaluations, participatory design sessions, ethnographic field studies, user surveys, heuristic evaluations, and similar methods.
• Provide insight and vision for the team based on researching user needs. Convert research findings into actionable items.
• Collaborate with other research organizations within Yahoo! (market researchers and data mining analysts) in order to create comprehensive coordinated research.
• Synthesize research findings from other data sources (including market research and data mining) into meaningful recommendations and actionable items.

Their new corporate design mantra is "Life Engine," which you'll have to embrace to work there. It's all about integration of experience, in the face of Google's growing presence.

The VP position is most interesting and revealing (my commentary in brackets):

...A key goal for this position is to elevate the influence of the UE group to become a strategic resource. [Whoa: They aren't now. They're biting the bullet and making it a VP-level job--unless someone quit--because everyone in the industry knows user experience can't succeed as a priority without VP-level support--? But I'm a little surprised Yahoo feels this too; it must be Google nipping at their backside.]

...Ensure successful knowledge sharing and improve visual, functional, and conceptual consistency across products and components - oversee the development of design standards, guidelines, and best practices;  [Again, I always thought they were remarkably consistent and had this already. One ad says "new creative direction," so I suppose they're just worried about continuing and pulling deviant products into line.]

...Partner with Engineering on the development of new interface conventions and code libraries to ensure consistent and efficient deployment of design; [Ah, the crucial insight into why standards are hard to enforce -- the tools need to enforce them well, not a human post-design police force. This goes back to Don Norman in, like, the Stone Age, I think. But few places get it.]

....A professional manager with strong executive presence, credibility, and a reputation for unquestioned integrity and management skills that allow for instant credibility with business partners; Demonstrated ability to build strong relationships with and influence senior executives and internal clients; Degree in graphic design, human interface design, interaction design, computer science, or information design; advanced degree in these fields and/or MBA a plus. [I like this: Computer science counts too, and an MBA is an asset. And the rest: Whoever wrote this is pretty right on.]

Other places hiring widely now: Google (of course, and in multiple regions), Adobe (because of a small diaspora, I believe), Intuit (always hiring, very hard to please), Microsoft (ditto and hard to please the hiree, too), and a few design agencies like Razorfish, which is usually the best indicator that the industry is in an up-turn. You can check out the Yahoo UED job list at Yahoo! Find a Job.

Fast Company's Creativity Issue

This is a few month's old, but still worth linking to, I think.

Fast Company's December 2004 issue is on creativity and innovative companies. There's an in-depth and somewhat inevitable article on Microsoft Research, What Money Can't Buy: the gist seems to be that they spend more time and money being defensive, and innovating (i.e., sticking new features onto) their existing products rather than figuring out new arenas to conquer. That's a company that clearly delineates between research (the "creative" folks) and ordinary folks. They're likened to the telecoms in the 1990s, and it does sound a bit like the AT&T I remember -- who never wanted to develop on any idea not guaranteed to be an instant billion dollar market.

And there's a surprising, charming piece about W.L. Gore, the company that made Goretex and apparently Glide dental floss among other stupendous and profitable items. They, in contrast, have a non-hierarchical, team-based, inclusive approach to innovation. And, I'd add, a lot of equally clever marketing folks, who manage to break them into areas that are truly new for them, not just extensions of existing brands. Even into areas already flooded with big names. The article describes this difficulty with a few anecdotes about viral marketing among other tricks. They sound like a 3M, only even better.

Finally, a study on corporate creativity that debunks some myths about what makes people and cultures innovative (and here I've rewritten her myths to make them truths):

1. Creativity [Doesn't Only] Come From Creative Types
2. Money Is [Not] a Creativity Motivator
3. Time Pressure [Doesn't] Fuel Creativity
4. Fear [Does Not] Force Breakthroughs
5. Competition [Doesn't] Beat Collaboration
6. A Streamlined Organization Is [Not Necessarily] a Creative Organization

My favorite quote: "One day's happiness often predicts the next day's creativity."

The Tyranny of Structurelessness

From a friend on LJ, an article from the women's lib days on how structureless groups have their own informal rules and roles: The Tyranny of Structurelessness:

For those groups which cannot find a local project to devote themselves to, the mere act of staying together becomes the reason for their staying together. When a group has no specific task (and consciousness raising is a task), the people in it turn their energies to controlling others in the group. This is not done so much out of a malicious desire to manipulate others (though sometimes it is) as out of lack of anything better to do with their talents. Able people with time on their hands and a need to justify their coming together put their efforts into personal control, and spend their time criticizing the personalities of the other members in the group. Infighting and personal power games rule the day. When a group is involved in a task, people learn to get along with others as they are and to subsume dislikes for the sake of the larger goals. There are limits placed on the compulsion to remold every person into our image of what they should be.

Software Functional Specifications: What's the Point?

Well, I've become pretty opinionated on this one recently. It's been on my mind as I think about what constitutes good design, the role of usability, and the process of team problem solving.

Cutting away to a separate essay page this time, so you don't get spammed without asking for it.

Teamwork and Teams

One of my favorite reads of last year was Teamwork: What Must Go Right/What Can Go Wrong. In a nutshell, they found that effective teams share the same characteristics:

1. clear, elevating goal;
2. a results-driven structure;
3. competent members;
4. unified commitment;
5. a collaborative climate;
6. standards of excellence;
7. external support and recognition;
8. principled leadership.

The two things that most often screw up effective teamwork are personal agendas that conflict with group goals and politics. Trust is a big issue as well; trust lost is hard to regain, if it ever can be.

I just looked around for a good review of this book, since I seem to have lost the one I wrote for my previous company newsletter, and I hit instead some interesting pages on group behavior in developing teams. Big Dog's Amusingly Titled Leadership Page pretty accurately describes the meetings of a group I'm in now as it tries to organize to solve a problem together. It even characterizes the personalities in my meetings!

The team's transition from the "As-Is" to the "To-Be" is called the Storming phase. All members have their own ideas as to how the process should look, and personal agendas are rampant. Storming is probably the most difficult stage for the team. They begin to realize the tasks that are ahead are different and more difficult than they imagined. Impatient about the lack of progress, members argue about just what actions the team should take. They try to rely solely on their personal and professional experience, and resist collaborating with most of the other team members. Storming includes these feelings and behaviors:

• Resisting the tasks.
• Resisting quality improvement approaches suggested by other members.
• Sharp fluctuations in attitude about the team and the project's chance of success.
• Arguing among members even when they agree on the real issues.
• Defensiveness, competition, and choosing sides.
• Questioning the wisdom of those who selected this project and appointed the other members of the team.
• Establishing unrealistic goals.
• Disunity, increased tension, and jealousy.

I think Someone inviting all members of the group to lunch instead of just some of them might have helped with that last bullet, but hey-- I'm just playing my role in the evolving team process with a little tension and jealousy!

Luckily, one of the group is a "Driver or Controller, a take-charge person, who exerts strong influence to get things done, focuses on results"; so we might get to the accomplishment phases soon. And the textbook strengths and weaknesses apply here: "Gets things done. Determined, requiring, thorough, decisive, efficient, direct. In-attentative behavior when listening to others. Dominating, unsympathetic, demanding, critical, impatient."

And no, I'm not going to tell you which group role I'm playing.

Ten Questions with TiVo's Director of User Experience

Just AFTER I did a talk on TiVo and quality at work, this appears in my blog reading list: The PVRBlog Interview: Ten Questions with TiVo's Director of User Experience, Margret Schmidt. Margret started after I left the first time (although I did work with her when I was contracting there 2 years ago); I'm relieved to see so much similarity in what she says and what I said in my talk at my company. At least most of my experiences look still "relevant" for the current TiVo. (FYI: I'm planning a web summary of my talk for posting here.)

Why Good Design Comes from Bad Design

I've been looking for materials to help an internal team understand a design point I've been unable to articulate well, and taking interesting detours that will help me give a talk next week about why TiVo did design well. Here's Scott Berkun of MS on the process of good design, not in terms of deliverables, but in terms of thought evolution. Why Good Design Comes from Bad Design.

The difficulty of hiring well: Google Labs Aptitude Test (GLAT) & Joe Kraus

One of my favorite of the Excite founders, Joe Kraus, has a post on his blog about the perils of hiring badly: No False Positives. He comes down strongly in favor of Microsoft's puzzle interview practice (at least, it sounds like it), which I'm not so sure about myself. (Not because I ever suffered through one, despite 2 interviews there at very different times, but because I've heard plenty about them from people I consider top notch. I should also point out we were not all turned down by MS, either.) One problem at MS is that if they've got anyone on the hiring committee who isn't as smart or lateral-thinking as the interviewee, they just can't do a good assessment. But I guess that's where "fit" comes in -- and when the old "B people hire C people" issue comes in. They may not even know they're already rotten, and worse, they may not ever be able to hire anyone who can help them fix things, or take a fresh view on their practices and processes. Anyhow, one of the traceback links off Joe's post is to the Google Aptitude Test. It's an entertaining read. But can Google keep it up? Relax, Everything Is Deeply Intertwingled: Google Labs Aptitude Test (GLAT)