Archive for the 'management' Category

Stop celebrating failure, find a better word

The celebration of failure has become a tired, counterproductive meme.

Sure, the tension involved in celebrating something normally thought to be bad gets your attention. It’s also a way to get people out of their comfort zone. So cheers for that.

But, really, we actually want to succeed and the more I read about failing forward, failing your way to success, and not being able to succeed without failing, the more I think the word does us a disservice on several levels. For starters, failure, it’s important to remember, is a broad umbrella. On the positive side, the one that’s worthy of fetishizing, it includes things that happened not to work. They didn’t fail so much as the client didn’t buy it, the market wasn’t ready for it, it was ahead of its time, or it was a good idea but not popular enough to be profitable. On the negative, however, failure also includes (and originally meant) screw-ups, incompetence, miscalculations, and arrogant dilettantism masquerading as expertise.

The problem is that the word failure doesn’t contain within it the means for evaluating good ones and bad ones. Failure doesn’t have an internal quality metric in its meaning that helps us identify the ones that actually advance the work and ones that should result in heads being knocked, going back to the drawing board, hitting the books, or putting together a new team.

Celebrating failure doesn’t help us increase our likelihood of doing quality work so much as it increases our chances of stumbling into it. By celebrating failure, we encourage peolpe and teams to try more, and more risky, ideas. But we don’t encourage people to focus on craft, execution, or a notion of quality. For some cultures, this might be good. If you’re in an environment that is so stale and idea-less that no one ever goes beyond the obvious, than you may need that jolt. But, in an environment that is already supposed to be about creativity, innovation, and design, you’re probably dumbing the place down. By talking about failure, rather than iteration and revving, we’re not advancing design thinking so much as inflating attitude. The word failure doesn’t have enough oomph in it to get people thinking.

Worst of all, I think, celebrating failure gives teams and people easy outs when something doesn’t go well. Since failure doesn’t contain a quality metric we have trouble describing what constitutes a useful failure. Most conversations about failure assume that everyone knows the actual complete screw-ups (do we really?) but don’t help identify the earnest, but ultimately wasteful, failures. As a result, when we fail, it’s easy to describe one’s self as taking a shot and missing but then celebrate the taking of the shot anyway. Rather than critique something to find out what the hell went wrong or, more productively, what do we do better, celebrating a failure implies that things were fine, it just didn’t work out.

To be clear, I think we should promote the taking of risks. I absolutely believe that the quality of an idea — its originality, elegance, or efficiency in solving a problem or doing something new and wonderful — should be celebrated even if the product ultimately doesn’t succeed in the marketplace or isn’t approved by the client. (I also think it would be an interesting exercise to see if celebrants of failure in the design world are willing to go so far as to call the Segway, Zune, and the XO successful failures.) But I think we should celebrate failure in a very different way: by calling it iteration, critique and refinement. Better yet, let’s call it experiment.

Experimentation is a much better word to use, though I already know it’s too wonky and beaker-y to catch on. Still, it’s worth talking about the difference if only to make the word we’ll be stuck with for the next year — FAILURE! — meaningful. Here’s the difference:

  • Failure describes the state of not succeeding and includes miserable, ghastly mistakes as well as good efforts. Experimentation describes the state of eliminating hypotheses.
  • Failure allows any idea to be tried. Experimentation requires a theory that the way being tried is better.
  • Failure requires no critique and has no metric for its success. Experimentation has built into it the idea that anything tried should answer a question, eliminate a route of exploration, provide glimmers into cracking the code.
  • Let’s use a fresh example from an unexpected place: the iPhone. This is from the WIRED cover story:

    It was a late morning in the fall of 2006. Almost a year earlier, Steve Jobs had tasked about 200 of Apple’s top engineers with creating the iPhone. Yet here, in Apple’s boardroom, it was clear that the prototype was still a disaster. It wasn’t just buggy, it flat-out didn’t work. The phone dropped calls constantly, the battery stopped charging before it was full, data and applications routinely became corrupted and unusable. The list of problems seemed endless. At the end of the demo, Jobs fixed the dozen or so people in the room with a level stare and said, “We don’t have a product yet.”

    The effect was even more terrifying than one of Jobs’ trademark tantrums. When the Apple chief screamed at his staff, it was scary but familiar. This time, his relative calm was unnerving. “It was one of the few times at Apple when I got a chill,” says someone who was in the meeting

    Jobs rather famously doesn’t celebrate failure. What he’s done in this moment is call something what it is — inadequate, not acceptable, deeply troubling. At the same time, however, he didn’t throw a tantrum. There was a critique in his assessment of the prototype/iteration/rev/version/experiment/failure — and it went beyond the bugs. Bugs can be solved and closed, the bigger issue was that it wasn’t coming together as a coherent product. That was a design moment, an experiment being evaluated — there was no celebration of failure.

    As Nick Cage so memorably re-told the story in the immortal national treasure National Treasure: “When Thomas Edison was asked how it felt to fail 99 times trying to invent the light bulb, Edison said ‘I didn’t fail 99 times. I discovered 99 ways how NOT to make a light bulb.’”

    Stop failing and patting yourself on the back for it. Start experimenting and stay focused on quality and success.

    We are all statisticians now

    or should be to a certain extent, if we take recently anointed Google numbers guru Hal Varian’s words to heart. The former economist (a very heavy maths-focused one at that) is frequently quoted as saying that statistician will be the next ’sexy’ job (just like engineer was), but the line, from McKinsey goes much deeper:

    I keep saying the sexy job in the next ten years will be statisticians. People think I’m joking, but who would’ve guessed that computer engineers would’ve been the sexy job of the 1990s? The ability to take data—to be able to understand it, to process it, to extract value from it, to visualize it, to communicate it—that’s going to be a hugely important skill in the next decades, not only at the professional level but even at the educational level for elementary school kids, for high school kids, for college kids. Because now we really do have essentially free and ubiquitous data. So the complimentary scarce factor is the ability to understand that data and extract value from it.

    I think statisticians are part of it, but it’s just a part. You also want to be able to visualize the data, communicate the data, and utilize it effectively. But I do think those skills—of being able to access, understand, and communicate the insights you get from data analysis—are going to be extremely important. Managers need to be able to access and understand the data themselves.

    I recently started working my way through Ben Fry’s Visualizing Data and adding Fry’s process to Varian’s shows some of the deep changes people need to make in order to embrace the new numeracy. Visualizing Data is more about Fry’s Processing language and how to hook it to datasets than it is about thinking visually or how to work through those datasets to find a pattern or evocative image, but it begins with a seven-step process:

    ACQUIRE — Obtain the data, whether from a file on a disk or a source over a network.

    PARSE — Provide some structure for the data’s meaning, and order it into categories.

    FILTER — remove all but the data of interest.

    MINE — Apply methods from statistics or data mining as a way to discern patterns or place the data in mathematical context.

    REPRESENT — Choose a basic visual model, such as a bar graph, list, or tree.

    REFINE — Improve the basic presentation to make it clearer and more visually engaging.

    INTERACT — Add methods for manipulating the data or controlling what features are visible.

    This does a nice job of highlighting that Varian’s charge is a mix of skills for managers, practitioners, and interpreters alike. Some of the steps are naive or described in a way that invites unhealthy simplisticism (simplicity == good, simplisticism, the thing we often get instead of simple is reductive, which is always bad). MINEing and REPRESENTing are the steps where numbers emerge into something living and actionable. MINE, as defined by Fry, is focused on software, rather than cognitive styles and elastic minds, for the generation of insights and pattern recognition. Certainly software is needed, but the hypotheses and candidate patterns you validate with the software come from soft eyes, something I blogged about a while ago. Similarly, REPRESENT is posed as choosing from a list of standard data tropes. But hey, it’s a software book and we all know Fry is more visual than that.

    The real point is that this path shows a range of skills and validation even broader than what Varian points to. Someone working with someone working with data needs to know, understand, and respect the technical underpinnings of the first two steps, which set up the infrastructure of your entire data exercise. Like software, you need to measure twice, cut once here because this is the infrastructure of your inquiry and you won’t be able to change it quickly. Filter, mine, represent are subjects for another book perhaps, but they put you in the land of Tufte, Orwell, as well Flowing Data and statistics — a mix of simple communication, humanities, and the techniques of numbers.

    The last one was also pretty interesting. I love how Fry reminds people to let the data grow with the audience by giving some interactivity. Sure, you do the first crack at it, but letting your audience go deeper, create their own juxtapositions, or simply play with the data gets them more engaged, allows for even more meaning to emerge from the data.

    http://www.kipbot.com/blog/2008/03/05/dd-my-grad-school-footnote/

    The very definition of useless feedback

    Ever gotten this kind of feedback from a client, manager, colleague?

    Right up there with this other bit:

    HBR: Smart take on the MFA/MBA cliche

    HBR has another good article breathing new life into stale concepts (the first one is blogged here).  Right now, it feels like that the “MFA is the new MBA” is stuck in a squishy or puddle-thin space.  For some, it’s a call to be a right-brained thinker — take a drawing class, learn an instrument, write a short story!  A little more intelligent, but kind of thin, is the argument that the MBA teaches you decision-making, the MFA teaches you synthesis.  Not bad, but it doesn’t unpack into actionable ideas.
    Katherine Bell, who got an MBA, worked in business, and then got an MFA at the highly selective Iowa Writer’s Workshop, has a “conversation starter” that gets deeper into the skills and attitudes that MFAs can acquire.  It goes deep enough, in fact, that it feels actionable.  Her points, which are also covered in the ideacast, are:

    • the workshop is an important management tool and cultural goal in a business that thrives on ideas — Bell’s MFA is in writing, and one of the biggest adjustments she had to make was to the workshop:  a class where your fellow students look at your work and critique it along with your professor.  Everyone has to develop skills for an effective workshop:
      • the author needs to learn to accept criticism about very personal things, how to sift good feedback from bad, and how to incorporate it into her work;
      • the students need to learn how to give useful feedback.  This one is particularly interesting because it goes beyond “don’t be negative” into “don’t give executional feedback.”  This is something a lot of design shops, clients, and companies trying to be more design-focused have trouble with.  Comments should be “the colors are feeling kind of flat to me, not as energetic as this”, rather than “can you make it more red?”
      • the professor needs to set the right tone for the workshop, facilitate the critiquing, and give measured, but strong comments. 
    • by writing fiction, you learn empathy — Bell spends a lot of time talking about how writing fiction forces her into her characters’ heads and out of hers.  Being able to get so far into a character that it acts in ways that surprise you is one of her litmus tests for empathy.  But she highlights that management is all about understanding who you’re talking to and feeling empathy with them.  (It’s also important for design, and Adaptive Path’s Subject to Change has a terrific chapter about what empathy is and isn’t and how to focus your work on building empathy).

    Even if you can’t go to a workshop or don’t bother writing fiction, it’s a useful read and think as it highlights parts of work and types of thinking that MFA==MBA inclined managers should dig into.

    HBR: Leading by Gaming

    Guild leaders comfort the soul, while punning.The idea that leading a guild in an MMORPG like World of Warcraft could result in some important skills has been around for a while. Joi Ito has done a couple pieces on it, including one in his blog and one in WIRED. But HBR’s got a “conversation starter” that puts some teeth into the idea, or the idea behind it.

    The literal idea — that you should pay serious attention to candidates who run a game guild — still seems kind of silly to me, but this article highlighted some points about these folks:

    • they are adept at email, IMing, and forum conversations as vehicles for making decisions, resolving/preventing conflicts, persuasion, etc. This one is near and dear to my heart. I’ve been in companies that consider walking to someone’s desk for answer to be a simple-minded waste of time, and where relying on emails for even the simplest question is considered to fraught with peril.
    • they manage complex workstreams. It’s almost embarrassing to talk about it, but organizing and strategizing for a raid (a mission to kill a baddie which requires 20 or more people), is pretty complex and requires a lot of coordination and communication.
    • they create or imaginatively use communication tools. A lot of organization needs to happen when players can’t all be on the game at the same time, so most guilds have a website, a bank, email lists, auto-alerts, etc. I’ve heard one person say he uses 37Signals tools for his guild.
    • they are good at handling difficult personalities. Let’s face it, nerds and game geeks are big pains in the ass, frequently over-reliant on logic, and often the most effective but most difficult person on our teams (even non-tech, non-web teams).
    • they understand temporary leadership. They know how and when to step into something and how and when to have or let someone else step up.

    This last one is the most interesting to me. My industry (advertising and marketing services) has some very stale notions of leadership: the singular leader who owns it all; the creative genius who calls every shot; the moving lead between disciplines (IA -> Visual -> Copy -> technology) that leads to waterfall. Attempts to model leaders above a waterfall process can get you into tedious, theological discussions about delegation, abdication or back to the “everything bubbles up to me.” Temporary leadership implies ongoing judgment, continual shifts in primacy of thought, constant responsiveness and self-re-organization.

    Worth a look (or a listen on HBR Ideacast #92).

    Balancing Acts: Just Enough Anxiety

    The book Just Enough Anxiety argues that effective companies can have both too little and too much anxiety.  It also argues that there are other things that need to be balanced:  confidence and humility, optimism and hard-headednes.  The chart below describes five virtues that organizations have and that leaders should strive to balance.

    1.  open heart
    2.  confident humility
    3.  realistic optimism
    4.  open mind
    5.  constructive impatience

    I’ve been in shops where ‘big swinging dicks’ are all confidence and energy and have no openness or humility and shops where any kind of criticism is seen as emasculating or anxiety producing.  I love the way the (press about the) book tries to find a balance.  Good creative shops need their people to have some level of anxiety:  am I doing the best work possible?  is this work good?  But they need to do so without crippling themselves.  They also need to be capable of believing and convincing others that their work is the best work possible, while still being open to new ideas or post-release improvements.

    In the spirit of openness, I am struggling with keeping my impatience constructive.  

    JEAorg012208.jpg