When should managers insert themselves into a messy situation

Bob Sutton’s Work Matters Blog continues to be one of my best sources of managerial insight. One of the challenges of managing is choosing whether and when to intervene in your organization (presuming that micro-management is not your goal). In this recent excellent post, Sutton offers the distinction between two classic acronyms as an excellent diagnostic question to help make that choice:

FUBAR, SNAFU, Fast Company, and Good Bosses – Bob Sutton:

Snafu — situation normal, all fucked-up

fubar — fucked-up beyond all recognition

One CEO I know, also the son of a World War II veteran, uses the distinction between the two to help decide whether a “mess” requires intervention, or it is best to leave people alone for awhile to let them work through it.

He asks his team, or the group  muddling through mess: “Is it a snafu or fubar situation? ” He finds this to be a useful diagnostic question because, if it is just usual normal level confusion, error, and angst that is endemic to uncertain and creative work, then it is best to leave people alone and let hem muddle forward.  But if it is fubar, so fucked-up that real incompetence is doing real damage, the group is completely frozen by fear, good people are leaving or suffering deeply, customers are fleeing, or enduring damage is being done to a company or brand — then it is time to intervene.

This is a really nice way to assess both a messy situation and the strength and skill of your management tea. I’m adding it to my repertoire.

How better thinking about deliverables leads to better knowledge work results

Deliverables should be a knowledge worker’s best friend but, like all good friendships, the relationship can get complicated. One of the most direct ways to improve the quality of knowledge work is to spend more time and effort to define appropriate deliverables.

My faith in deliverables has grown out of decades of practical consulting experience, where defining the appropriate deliverable can mean the difference between mediocrity and success. A deliverable is an identifiable work product intended for someone outside the knowledge work process that marks the end of that particular process. Examples of deliverables include:

  • A consulting report prepared by the consultant or consulting team containing recommendations to the client sponsor.
  • A list of recommended job offers to prospective employees prepared by a campus recruiting team and handed to the hiring manager.
  • Production Release 1.0 of a new application system installed and operating on the companies intranet.
  • A project work plan and business case delivered to a steering committee for approval.

Why Deliverables Are Relevant

In the world of industrial work, process outputs are well-defined. This gives organizations a straightforward process improvement path. Holding the outputs constant allows process improvement to proceed by identifying and eliminating activities that don’t add value to the output; to break down, reorder, and redesign process steps to create more standard outputs with less input; and so on.

This path isn’t available to knowledge work practices. The goal is not to produce well-defined, standardized outputs. Deliverables are the closest analogue but their value depends on how well they match the unique needs of their users. No one is interested in a spreadsheet full of someone else’s data; no teacher is likely to value a copy of a paper you’ve submitted to another class. Understanding what aspects and features of a knowledge work deliverable are most valuable to its intended user is key to focusing efforts on producing the desired deliverable.

Natural vs. Artificial Deliverables

Some knowledge work processes produce obvious and natural deliverables. A campus recruiting effort generates a list of candidates to extend offers to. There may be a variety of associated supporting documents (e.g., interview notes, assessments), but the list is the deliverable and is a natural outgrowth of the process.

Other knowledge work processes generate more amorphous or less obvious outputs. For example, what’s the deliverable for a typical project status meeting? Shared understanding among the project team? Agreement about the state of the project between the team and the project sponsor?

Consider the typical status report as a more artificial than natural deliverable and ask how much value resides in this particular item. If you can define the deliverable more effectively, is the world a better place?

Defining Better Deliverables

The better we can define deliverables, the better and more effective we can make our knowledge work. Rather than ignore the end product, we need to be systematic in extracting as much as we can about the expected deliverable that can guide our effort to create it. There are three productive paths to explore in using the deliverable to drive your knowledge work.

  • Path #1: Understand the user’s essential quality need

    Does this deliverable need to be exactly correct whatever the time or cost, as good as possible given a particular deadline/budget, or the best you can come up with on the phone? Each deliverable demands a different approach; each requires a conversation (and perhaps a negotiation) with the end user. The history of systems development is littered with examples of failing to follow this path.

  • Path #2: Balance uniqueness and uniformity

    We’ve been conditioned by one hundred years of industrial experience to value uniformity. In knowledge work, the value of uniformity is to free time and attention for the essential uniqueness we’ve defined. The folks in marketing may believe that corporate identify standards are about branding. For a knowledge worker, they let you ignore formatting decisions to focus on the content that matters.

  • Path #3: Specify stopping conditions

    There was an joke that was old even in my early consulting days that you knew the design phase was complete when the budget ran out. Possibly the biggest challenge for managing knowledge work is determining how to recognize that the deliverable is done. Think of the unfinished doctoral dissertations and manuscripts of the great American novel gathering dust on a shelf or lost in a lonely directory of a disk drive. Too many knowledge-work efforts fail simply because no one thinks about how to recognize what "done" will look like.

Focusing on deliverables means working backwards with the end in mind. Knowledge work is valuable to the extent that it produces end results, i.e. deliverables, that meet the unique requirements of a particular customer or end user. Time invested in understanding what that deliverable should look like will yield the greatest return in defining and focusing the activities that contribute to creating that particular deliverable at the right time and place.

Patti Anklam on The Year of Personal Net Work

Patti Anklam and I have reconnected after first meeting several years ago. We navigate in the same circles and our networks overlap, but I hadn’t been carefully following her work. My mistake and I’ve fixed that now. Here’s a recent piece from her with a very good overview presentation on moving from a general understanding of networks to concrete actions. Worth taking a look at both for the content and for some good ideas on presentation design.

Chris Brogan writes about his strategy for deepening his personal networks. He starts off his list of tips with this one:

"Devote two hours a week to this effort. If, out of the 60 hours an average person works, you can t find two for this, reconsider how you re running your day.

This is not the only new year’s resolution I’ve seen along this line. As we become more and more connected through social media, the more we are aware of what those connections mean.

My new year’s resolution? I’m resolving to share more of my thinking, especially about personal networks. Here’s a slide show from this past October I hope you will enjoy.

Personal Network Management Km Forum Oct 2009

The Year of Personal Net Work
Patti
Tue, 12 Jan 2010 20:52:00 GMT

Andrew Sullivan on Blogging

One of the lovely things about the Internet is that the good stuff is there whenever you finally manage to stumble across it (so is the crap, but that’s another story). I’m in the process of cleaning up a bunch of stuff that has been lingering in my various queues and stopped long enough to follow this item from Brad Feld on to the excellent piece by Andrew Sullivan from 2008. It is as relevant now as it was then.

I regularly get the "why do you blog" question.  I also regularly get "thank you for blogging" notes (thank you for the thank you notes.)

I’m a fan on Andrew Sullivan – he has a magnificent article in The Atlantic titled Why I Blog.  He nails it.

Thanks for the link Dave.

Andrew Sullivan on Blogging
brad@feld.com
Mon, 27 Oct 2008 13:56:50 GMT

Gist – a Farleyfile for the 21st century

I’ve been part of the private beta of Gist for the last several months and am still wrapping my head around it. They’ve just opened up the beta for wide consumption. Here’s the announcement from CEO T.A. McCann.

Today, Gist brings you a better way to communicate and build stronger business relationships.   After a year in limited release and with the input of over 10,000 beta users, we have created a new system to aggregate, organize, prioritize and focus your time on the most important things.   We connect to your inbox or social networks to discover your key contacts and companies, automatically prioritize them and bring together personal communications, news, blogs, and the real-time web all into one neat package.

131108102856innovation

We assert a few things are true:

  • There will be more information, in more places and it s growing at an increasing rate
  • Systems will need to evolve or be created that help users harness the power of the information
  • Success in business is driven by strong relationships, both in quality and quantity
  • Companies who can quickly respond to customer demand are successful

Gist is a game changer and I am proud to be part of the team that has brought it from concept to a robust and useful solution.  We are privileged to work in such an exciting and evolving space, with great investors and,most importantly, incredible users who will continue to help us focus on what is most important and most valuable.  Thank you for the privilege to make a radical shift!

Gist a better way
T. A. McCann
Tue, 15 Sep 2009 12:18:47 GMT

Here are some pointers to other coverage and commentary about the service that are helping me get a better handle on the value of this evolving service:

What is a Farleyfile you ask? There is a Wikipedia entry for Farleyfile, but I first encountered the concept in one of Robert Heinlein’s novels, Double Star, about a hack actor forced to double for a kidnapped politician. Heinlein’s description captures the essence of the challenge and the solution that Gist promises in this 21st Century incarnation:

The tightrope act I was going to have to attempt was made possible only by Bonforte’s Farleyfile, perhaps the best one ever compiled. Farley was a political manager of the twentieth century, of Eisenhower I believe, and the method he invented for handling the personal relations of politics was as revolutionary as the German invention of staff command was to warfare. Yet I had never heard of the device until Penny showed me Bonforte’s.

It was nothing but a file about people. However, the art of politics is "nothing but" people. This file contained all,or almost all, of the thousands upon thousands of people Bonforte had met in the course of his long public life; each dossier consisted of what he knew about that person from Bonforte’s own personal contact. Anything at all, no matter how trivial–in fact, trivia were always the first entries: names and nicknames of wives, children, and pets, hobbies, tastes in food or drink, prejudices, eccentricities. Following this would be listed date and place and comments for every occasion on which Bonforte had talked to that particular man

When available, a photo was included. There might, or might not, be "below-the-line" data, i.e. information which had been researched rather than learn directly by Bonforte. It depended on the political importance of the person. In some cases the "below-the-line" part was a formal biography running to thousands of words.

"God’s mercy child! I tried to tell you this job could not be done. How could anyone memorize all that?"

"Why, you can’t, of course."

"You just said that this was what he remembered about his friends and acquaintances."

"Not quite. I said that this is what he wanted to remember. But since he can’t, not possibly, this is how he does it….

"These are things he would like to remember if his memory were perfect. Since it isn’t, it is no more phony to do it this way than it is to use a tickler file in order not to forget a friend’s birthday — that’s what it is: a giant tickler file, to cover anything."

[Robert A, Heinlein. Double Star. 1956. Del Ray Books. pp.151-154]

Most of us are called on to cope with an order of magnitude or two more relationships than our parents or grandparents ever contemplated. Applications and information management services like Gist are becoming absolutely essential if we hope to cope with those demands.

Zen and the scientific method

Espen reminded me of the following passage from Zen and the Art of Motorcycle Maintenance. It is a wonderfully succinct description of the scientific method and its power to protect us from the risks of wishful thinking when problems call for discipline. We used to use this passage as a piece of our basic training for all incoming consultants at Diamond.

 

…this morning I talked about hierarchies of thought–the system. Now I want to talk about methods of finding one’s way through these hierarchies–logic.

Two kinds of logic are used, inductive and deductive. Inductive inferences start with observations of the machine and arrive at general conclusions. For example, if the cycle goes over a bump and the engine misfires, and then it goes over another bump and the engine misfires, and then it goes over another bump and the engine misfires, and then it goes over a long smooth stretch of road and there is no misfiring, then it goes over a fourth bump and the engine misfires again, you can logically conclude that the misfiring is caused by the bumps. That is induction: reasoning from particular experiences to general truths.

Deductive inferences do the reverse. They start with general knowledge and predict a specific observation. For example, if from reading the hierarchy of facts about the machine, the mechanic knows the horn of the cycle is powered exclusively from the battery, then he can logically infer that if the battery is dead, the horn will not work. That is deduction. Solution of problems too complicated for common sense to solve is achieved by long strings of mixed inductive and deductive inferences that weave back and forth between the observed machine and the mental hierarchy of the machine found in the manuals. The correct program for this interweaving is formalized as scientific method.

Actually I have never seen a cycle-type maintenance problem complex enough to really require full-scale formal scientific method. Repair problems are not that hard. When I think of formal scientific method, an image sometimes comes to mind of an enormous juggernaut. A huge bulldozer–slow, tedious, lumbering, laborious, but invincible. It takes twice as long, five times as long, maybe a dozen times as long as informal mechanic’s techniques, but you know in the end you are going to get it. There is no fault isolation problem in motorcycle maintenance that can stand up to it. When you’ve hit a really tough one, tried everything, racked your brains and nothing works, and you know that Nature this time has really decided to be difficult, you say, “Okay, Nature, that’s the end of the nice guy,” and you crank up the formal scientific method.

For this you keep a lab notebook. Everything gets written down, formally, so you know at all times where you are, where you’ve been, where you’re going and where you want to get. In scientific work and electronics technology this is necessary because otherwise the problems get so complicated you get lost in them and confused and forget what you know and what you don’t know and have to give up. In cycle maintenance, things are not that involved, but when confusion starts, it’s a good idea to hold it down by making everything formal and exact. Sometimes just the act of writing down the problem straightens out your head as to what they really are.

The logical statements written down into the notebook are broken down into six categories: (1) statement of the problem, (2) hypothesis as to the cause of the problem, (3) experiments designed to test each hypothesis, (4) predicted results of the experiments, (5) observed results of the experiments and (6) conclusions from the results of the experiments. This is no different from the formal arrangement of many college and high school lab notebooks. But the purpose here is no longer just busywork. The purpose is precise guidance of thought that will fail if they are not accurate.

The real purpose of the scientific method is to make sure Nature hasn’t misled you into thinking you know something you don’t actually know. There is not a mechanic or scientist or technician alive who hasn’t suffered from that one so much that he’s not instinctively on guard. That’s the main reason why so much scientific and mechanical information sounds so dull and so cautious. If you get careless or go romanticizing scientific information, giving it a flourish here and there, Nature will soon make a complete fool out of you. It does it often enough anyway even when you don’t give it opportunities. One must be extremely careful and rigidly logical when dealing with Nature: one logical slip and an entire scientific edifice comes tumbling down. One false deduction about the machine and you can get hung up indefinitely.

In Part One of formal scientific method , which is the statement of the problem, the main skill is in stating no more than you positively know. It is much better to enter a statement “Solve Problem: Why doesn’t cycle work?” which sounds dumb, but is correct, than it is to enter a statement “Solve Problem: what is wrong with the electric system?” when you don’t absolutely know the trouble is in the electric system. What you should state is “Solve Problem: What is wrong with the cycle?” and then state as the first entry in Part Two: “Hypothesis Number One: The trouble is in the electrical system.” You think of as many hypothesis as you can, then you design experiments to test them to see which are true and which are false.

This careful approach to the beginning questions keeps you from taking a wrong turn which might cause you weeks of extra work or can even hang you up completely. Scientific questions often have a surface appearance of dumbness for this reason. They are asked in order to prevent dumb mistakes later on.

Part Three, that part of formal scientific method called experimentation, is sometimes thought of by romantics as all of science itself because that’s the only part with much visual surface. They see lots of tubes and bizarre equipment and people running around making discoveries. They do not see the experiment as part of a larger intellectual process and so they often confuse experiments with demonstrations, which look the same. A man conducting a gee-whiz science show with fifty thousand dollars’ worth of Frankenstein equipment is not doing anything scientific if he knows beforehand what the results of his effort are going to be. A motorcycle mechanic, on the other hand, who honks the horn to see if the battery works is informally conducting a true scientific experiment. He is testing a hypothesis by putting the question to Nature. The T.V. scientist who mutters sadly “the experiment is a failure; we have failed to achieve what we had hoped for,” is suffering mainly from a bad script writer. An experiment is never a failure solely because it fails to achieve predicted results. An experiment is a failure only when it also fails adequately to test the hypothesis in question, when the data it produces don’t prove anything one way or another.

Skill at this point consists of using experiments that test only the hypothesis in question, nothing less, nothing more. If the horn honks, and the mechanic concludes the whole electrical system is working, he is in deep trouble. He has reached an illogical conclusion. The honking horn only tells him that the battery and horn are working. To design an experiment properly he has to think very rigidly in terms of what directly causes what. This you know from the hierarchy. The horn doesn’t make the cycle go. Neither does the battery, except in a very indirect way. The point at which the electrical system directly causes the engine to fire is at the spark plugs, and if you don’t test here, at the output of the electrical system, you will never really know whether the failure is electrical or not.

To test properly the mechanic removes the plug and lays it against the engine so the base around the plug is electrically grounded, kicks the starter lever and watches the spark-plug gap for a blue spark. If there isn’t any he can conclude one of two things: (A) there is an electrical failure or, (B) his experiment is sloppy. If he is experienced, he will try it a few more times, checking connections, trying every way he can think of to get that plug to fire. Then, if he can’t get it to fire, he finally concludes that A is correct, there is an electrical failure, and the experiment is over. He has proved that his hypothesis is correct.

In the final category, Conclusions, skill comes in stating no more than the experiment has proved. It hasn’t proved that when he fixes the electrical system the motorcycle will start. there may be other things wrong. But he does know that the motorcycle isn’t going to run until the electrical system is working and he sets up the next formal question: “Solve Problem: what is wrong with the electrical system?”

He then sets up hypotheses for these and tests them. By asking the right questions and choosing the right tests and drawing the right conclusions the mechanic works his way down the echelons of the motorcycle hierarchy until he has found the exact specific cause or causes of the engine failure, and then he changes them so that they no longer cause the failure.

An untrained observer will see only physical labor and often get the idea that physical labor is mainly what the mechanic does. Actually the physical labor is the smallest and easiest part of what the mechanic does. By far the greatest part of his work is careful observation and precise thinking. That is why mechanics sometimes seem taciturn and withdrawn when performing tests. They don’t like it when you talk to them because they are concentrating on mental images, hierarchies, and not really looking at you or the physical motorcycle at all. They are using the experiment as part of a program to expand their hierarchy of knowledge of the faulty motorcycle and compare it to the correct hierarchy in their mind. They are looking at underlying form.

(Chapter 9. pages 107-111 from Pirsig, R. M. (1999). Zen and the art of motorcycle maintenance. 25th Anniversary Edition. Morrow.)

Tags:

It’s not about creativity, it’s about curiosity

The critical leverage point for an organization seeking more effective innovation is establishing new attitudes toward curiosity. Industrial organizations were optimized to extract value from tiny doses of curiosity and cannot tolerate larger doses. Today’s organizations require more frequent and intensive invention and innovation, which depends in turn on learning to foster and effectively channel curiosity in greater doses.

The industrial economy was driven off of very small doses of curiosity, carefully controlled and administered. New ideas were the province of either the senior-most leaders in an organization or their specifically designated deputies (industrial engineers, product designers, strategy consultants). Outside of this small cadre, the rest of the organization was charged with pulling on the oars and carrying out the execution of the designs created by this cadre. Industrial organizations are optimized to extract the maximum output from the least curiosity. Moreover, our schools and other social systems are built around throttling curiosity and channeling it into acceptable settings; isolating the most curious from the rest of the system. For those immersed in the industrial mindset, unfettered curiosity is a serious threat that operates at an emotional rather than rational level.

In the knowledge economy invention and innovation take a more central role. Success based on the ability to out-execute the competition is increasingly short-lived. The changing economics of information and communications technologies continue to drive down the costs of execution. They shorten the distance, in both time and money, between idea and execution. They also shorten the distance between innovation and duplication. The need for more systematic and effective invention and innovation is generally acknowledged. Curiosity is the necessary prerequisite and fuel for this invention and innovation.

Alan Kay tells a story of his days at Xerox PARC. The suits from headquarters in Stamford Connecticut had come to Palo Alto to inspect their investment in open-ended research. Alan carefully explained the nature and risks of research; that PARC was conducting experiments, that most experiments failed, but that even failures moved the research forward. The suits nodded politely, allowed as how they understood what Alan had said, and insisted that these experiments be designed to succeed.

Given the degree to which curiosity in most organizations is discouraged and often suppressed, the first task is to carefully reawaken it. Carefully, because too much curiosity will trigger corporate immune responses. Fortunately, despite all the best efforts of our school systems and organizational watch guards, the human animal remains fundamentally curious. We need to give permission for this curiosity to be engaged and protect its first cautious glimmerings.

Here is one place where RSS and blogging have an important, low threat level place inside the organization. Seth Godin captured this succinctly as quoted in Naked Conversations last year:

Not only are bloggers suckers for the remarkable, so are the people who read blogs,” said Godin. “This is the most curious segment of the population, the people who are seeking out the new and the useful. This is the audience that doesn’t need to be interrupted because they are already listening. They are alert, on the lookout for the next big thing. No need to yell. If you’ve invested the time and the energy and the guts to make something remarkable, this audience can’t wait to hear about it.

(Naked Conversations, Chapter 3, Word of Mouth on Steroids, p.40)

Find and encourage those in your organization who are already paying attention to do so a little more systematically. Encourage them to begin to pass along what they are finding to others who might also be interested.

The second task is to start channeling this nascent curiosity toward potentially useful deliverables that can be judged and evaluated. Incorporate an interesting discovery into the next presentation to a customer. Adapt a lesson learned to an improvement process about to launch. Craft a proposal to target a new customer or begin a joint effort with an adjacent department.

Understand that channeling curiosity is a leadership challenge not a management task. Like a parent with an inquisitive toddler, leaders need to allow room for exploration, risk bumps and scrapes (and possibly worse), and intervene only to avert real danger. If they opt to guide exploration into familiar paths, they will get familiar results.

If you are still unsure about the importance of curiosity, recall what Albert Einstein said toward the end of his life:

I have no special talent. I am only passionately curious.

 

Making online forums work

Excellent insights from Cory Doctorow on the skills and techniques needed to ensure reasonably civil and effective discourse in online environments. You would also do well to take a look at Teresa Nielsen Hayden’s advice on moderation in online forums.

Which troll-fighting techniques work

Cory Doctorow: In my latest InfoWeek column, I look at what works, and what doesn’t, when it comes to fighting trolls:

In the wake of the Kathy Sierra mess, Tim O’Reilly proposed a Blogger’s Code of Conduct as a way of preventing a recurrence of the vile, misogynist attacks that Sierra suffered. The idea was that bloggers could choose to follow the Code and post a little badge to their sites affirming their adherence to it, putting message-board posters on notice of the house rules. Although it sounds like a reasonable idea on the face of it, bloggers were incredibly skeptical of the proposal, if not actively hostile. The objections seemed to boil down to this: “We’re not uncivil, and neither are those message-board posters we regularly see on the boards. It’s the trolls that we have trouble with, and they’re pathological psychos, already ignoring our implicit code of conduct. They’re going to ignore your explicit code of conduct, too.” (There was more, of course — like the fact that a set of articulated rules only invite people to hold you to them when they violate the spirit but not the letter of the law).

O’Reilly built his empire by doing something incredibly smart: Watching what geeks did that worked and writing it down so that other people could do it too. He is a distiller of Internet wisdom, and it’s that approach that is called for here.

If you want to fight trolling, don’t make up a bunch of a priori assumptions about what will or won’t discourage trolls. Instead, seek out the troll whisperer and study their techniques.

Link