Evolving Web

Innovation for Erratic Meatbags

Okay..  Herbert Hoover and Ayn Rand tell us of the rugged individualist. More or less, its a western ideal. We question convention - even conventions WE helped create. We have free will. We make decisions and act accordingly. In our rational hearts, we make only appropriate, moral, and ethical decisions.

We want to control our environment and, in order to do that we must control ourselves - and perhaps even those “less intelligent than us”.

But we've learned a lot recently about the human brain and the psycho soup we call a mind.  We now have significant data that leads us to scientifically understand that humans are more like highly suggestive, moody, erratic meatbags. And I understand that I, Jim Benson, fit that bill as much as anyone.

We also understand that we fall into some definable types. Some of us are introverts, some of us are gregarious, some of us are creative, some of us are INTJ, some of us are ADHD, some of us get depressed in the Winter. etc. etc.

And maybe all these deterministic blanket statements describe no one in particular - but rather describe common human states we all find ourselves in from time to time. We do know one thing, that whatever evidence we may find that our will isn’t as free as we’d like it to be - the opposite is also untrue - we are not some B.F. Skinner robots of behavioralism. We are neither John Galt nor walking computers.

We’re something very different. We are neither pre-programmed nor truly rational, we are influenced. We are complex emotional beings striving for clarity. And we go to work in the morning.

Why this matters to people and business...

Recently, I had the unique opportunity to see some beauty worked. Simon Marcus and Jabe Bloom at The Library Corporation decided that their staff needed a dose of entrepeneurialism. Why they felt this is not really important right now. What is important was that a large group of computer programmers who had worked their entire careers on legacy systems suddenly found themselves in a situation where they had to invent new products and then discuss those products with potential users.

And by potential users I mean strangers walking the streets of Washington DC.

TLC’s staff is as varied as anyone’s, and they have their share of introverts. These introverts had to talk to strangers on the street about products they just made up.

Jabe Bloom, TLC's CTO, knew that the coders would literally freak out if asked to do this - so he had to ease them into it. For a week leading up to the DC day, he gave his teams exercises that slowly helped them understand who their clients were, the sensibilities and needs of other people, what problems these people might be having, and then license to invent products that might solve those problems. From this, product ideas would be generated, refined, and then vetted (validated) with these on-the-street interviews.

What was important was that these programmers were ... programmers. They just wanted to code. This was a huge and frustrating distraction from their regular work - which really needed to get done. So they started the first exercises annoyed and angry. Jabe gathered comments along the way - after the first few days of this process he received some extremely negative feedback.

As the exercises progressed, they began to generate products for the participants. They created personas of their system users, affinity maps of attributes, and most important - real individual and team learning.  Feedback became more positive.

By the time the group started generating real, tangible ideas - they had unprecedented clarity, not only into the exercise, but into their own clients and products. Perhaps for the first time ever, they had a deeper understanding of who would use their products and that those people were real. That clarity felt good, it was empowering. I don't mean “empowering” in the harmonically convergent woo-woo babble sense - I mean that in the actual "I now know how to really do my job" sense. They had more real power to write good code.

By the time these people did their exercise in DC, they were so into the game and their ideas, that the previously terrifying prospect of going out on the streets of Washington and talking to strangers was now merely .... terrifying.

Yes, it was still terrifying.

But they did it.  Introverts and non-people-persons stormed the nation’s capital and got some real work done.

Because they had clarity and because there was a system that made those actions logical. That made those terrifying actions easier.

Punch line

Our individual programming obviously runs deep, and circumventing it is not trivial. But we are not hopeless. No one is a trapped.

We can step outside our comfort zones, we can grow. And we can enjoy the experience.

Our brains have tendencies, some stronger than others, and many extremely rewritable. When we encounter stimuli, our brains record it and we are changed by it. The more that stimuli is repeated, the more our brains physically and operationally adapt to the new patterns.

We, as individuals, team members, and managers, all would do well to appreciate that thoughtfully created collaborative systems like TLC's can have radical impacts on the system participants. (Habits take longer to develop, of course).

After all was said and done, at about 10 pm on a Wednesday night we were gathered in TLC’s offices back in Inwood, West Virginia. I ran a retrospective with everyone in attendance. These people were exhausted and euphoric. The most successful applications will be further refined and likely built. People stepped way outside their normal comfort zones to make that happen. It was draining and beautiful to watch.

Simon Marcus, the COO at TLC, who started this whole process rolling, listened to everyone talk about what they enjoyed about the process and what they did not. He made it clear that innovation was everyone's job. And, by and large, everyone knew he was serious. The next morning they were at work, building a new process to harness this new power.

Simon and Jabe could have written off their programmers as stereotypical introvert meatbags and left the innovation to product development experts - but that's the normal way of doing things. Silo'ing innovation where it’s appropriate and turning everything else into a factory.

In the middle of all this, Jabe said to me, "you know, I thought I would get a ton of stupid ideas and maybe two good ones, but I've been overwhelmed by the number of really good - not just good but really good - ideas these guys came up with."

If Jabe and Simon  would have silo'ed their innovation, they would have destroyed not only value, but people as well.

Photo of Jim Benson by Jim Benson

Photos of TLC staff by Jabe Bloom

Depth in Progress: of Wine Snobs, Audiophiles, and Agilistas

“Wine is to enjoy, not to judge.”
~ Hwi Woong Jeong (웅가) Wine Enthusiast

 

The gentleman next to me took out his laptop and began typing, he had a large pile of wine labels and a notebook filled with wine notes. He began systematically copying them into his laptop. I figured he was a wine critic.

Other work he went on to do involved software development and airplanes so my curiosity overtook me and we began to talk. It turned out that he was a software developer that worked with airplanes. But … he was also a noted wine critic enthusiast. He had been to the Pacific Northwest of the US on a wine excursion as a guest of the major wineries. He had been all over Washington and Oregon tasting.

When I was in my 20s, I decided I wanted to be a wine snob. So I went and took courses on wines, read books, and started a collection. I became rather good at it. So good, in fact, that I found I wasn’t actually enjoying wine any more. I was always critiquing it. I could always find something not quite right.

I told him this and he smiled and said, “wine is to enjoy, not to judge.”

We will always suffer from snobbery – to this day, I cannot listen to music from laptop speakers. And I know more than my share of agile adherents who actively hate every team they come into contact with because of their flaws.

We tend to fall in love with our ideas and nothing kills romance like familiarity. Richard Dawkins once said, “There is an anaesthetic of familiarity, a sedative of ordinariness which dulls the senses and hides the wonder of existence.”

We do this all the time with our work. We get excited about a task or an idea and we go deep. Too deep. Beneath the layer of effort that separates excitement from boredom. From energizing to draining. From inspiration to drudgery.

We might call this “depth in progress”. Just like we can have too much work in progress, we can also have too much depth. It’s simply doing too much of something. We go beyond what would be an acceptable level of completion and strive for “perfection.”

“The fact of storytelling hints at a fundamental human unease, hints at human imperfection. Where there is perfection there is no story to tell.” ~Ben Okri

At some point on the path to perfection, we pass the point of diminishing returns. After that point, our efforts do not return profit, only waste. In our pursuit of perfection, we identify all the things that cannot be perfect and then strive to perfect them. Yet, the imperfect is always with us. It is where growth resides.

Yet the need for growth, and the imperfection, will always be there. We end up in a doom loop of reductio-ab-absurdum – we manage our products as if the end product were a fine diamond that would last centuries. Well, it took the planet millions of years to make that diamond, and we don’t have that kind of time.

Therefore we need to approach our work by asking, “What is the least amount I can do to make this task successful?” In doing this, we want to move our ticket to DONE and have it stay there. No re-work, no additional tasks created because it was incomplete.

Can that task be improved in the future? Absolutely. But for now, it is complete. We launch it, watch it work, and come back to improve upon it later if necessary.

We want to know what the minimal completed task looks like and then do that. Anything beyond is too much work. Our previous goal of “perfect” is still valid, but now it has an upper boundary. Overly polishing the task does no one any good. Because of this, perfection is no longer gilding the lily - we now recognize the lily is perfect. We want to enjoy our wine, not judge it.

"To gild refined gold, to paint the lily ... is wasteful and ridiculous excess." ~ Shakespeare

Reading is (Still) Fundamental

 

I recently tweeted this after mulling over the differences I’ve seen while working with various clients. Some of them have practically been begging people to slow down, finish less with higher quality, and to take time out to read. Others are so scared that they don’t produce enough, that people are running in every direction trying to get something done, while finishing practically nothing, and learning even less than nothing in the process.

Of course, the first tweet I received in response was from JB Brown, at Nordstrom’s Innovation Lab. Since “Innovation” is well, what they do, they like to read a lot and… apparently…are fond of statistics:

To me, the benefits of giving teams the time to read is self-evident. But I thought I’d let the people actually giving their staff the time time to read speak for themselves.

Simon Marcus: COO of the Library Corporation

I encourage people to read at work for the same reason that I encourage them to write things down. Reading and writing give you time and room to think. Mostly at work people think they are supposed to be DOING ALL THE TIME. But if they aren't thinking, the result of all that doing can be a whole lot of nothing.

I love when I am reading and stumble on a word or a phrase that sends me spinning off into one of my own real world problems or opportunities. I love it even more when it happens to other people, but the long range value of reading at work is that it slows people down and makes them more thoughtful and intentional about their work.

Lastly, a word about why we encourage people to read AT work (instead of just expecting them to read on their own time). If I think that something is important enough to ask people to do it, I owe it to them to give them time to attend to it. This is part of the larger effort we make to respect people's time AT work. Reading is Work in Progress (WIP), just like everything else we ask people to do. We try to avoid making work WIP slip over into people's home life. All of that isn't to say that I don't love it when I find out that people have gotten the reading bug and are reading on their own time too. I find that the reading bug can be contagious. Eventually, about one out of three people who we encourage to read at work seem to start reading more on their own time. When I hear that someone who "never reads" has started reading, it makes me smile from ear to ear.

Jabe Bloom - CTO of the Library Corporation:

I have 2 general concepts for why reading is important at work.

1) Technical Knowledge is more valuable the earlier you can apply it. For many of my developers ensuring that they are constantly retooled is one my most critical tasks. Encouraging them to read helps them to maintain a “landscape” view of the technologies they are using so they have a better chance of “finding” the right tool at the right time. Exposing developers to a wide range of new and interesting thoughts is a good way to inoculate them against complacency and “I have a hammer-and-everything-is-a-nail-itus”.

2) I think.. more critically... Having an open environment at work where individuals can be SEEN reading, activates the social space as a learning environment.

More and more studies of cognitive science support a concept of ritualized changes in thinking patterns... transforming from one way of thinking to another.. I think that having people read at work, helps them to think in a “learning activated” mindset.

3) Encouraging employees to read AT WORK, sends a clear message that we EXPECT and VALUE learning in the work environment. Employees aren’t expected to keep up on changes to the industry on “their own time.”  Our encouragement of reading at work has seen an increase in;

1) Teams’ abilities to communicate internally and with other teams via shared vocabulary

2) Increase in individuals sharing learnings and source materials.

3) Decrease in defect rates, especially escaped defects.

Jason Montague, the Director for Application Development at RW Baird:

As you've stated, a staff that is willing and equipped to read is a staff that understands the need for continuous improvement.  In that regard, reading, reflecting, and learning is crucial.  To understand why, let's simply look at one of the most common reasons given (to me) for why some don't read.

"I learn enough through experience!  Everything I know I've learned through the school of hard knocks.  What could a book *possibly* tell me that I can't get from experience?"

While it's true that experience is likely the most powerful means of learning, the sad truth is that we don't have as much experience as we think we do.  As I've learned (in books no less) most of us rarely have "20 years of experience".  We typically have one year of experience FOR 20 CONSECUTIVE YEARS.  That's right.  If we reflect on our past, occasionally we have brand new experiences that indeed teach us quite a lot.  But for the bulk of our past, we tend to repeat what we know over, and over (and over) again.  In that way, I would argue we need to step outside the boundary of experience-based learning and learn from others collective experiences.  You do that in books, articles, websites, blogs, and yes, tweets.

As you might guess, it's important that your teams are "willing" to read.  Just as important, they need to be "equipped" to read.

As employers, we can help control the second of these two statements.  Our obligation while building learning organizations is to model behavior, challenge assumptions, infuse an attitude of curiosity, and generally create conditions that allow (and encourage) people to read and reflect.  After all, as adults, quiet reflection is critical to our growth.  We are therefore obligated to not only "allow" people to read at work, but to encourage and incentivize them to read at work as well.  In that way, each employee becomes a well spring of "new" ideas, and a potential catalyst for infusing those ideas in our organizations.

 

Don’t Slow Down, Just Get It Done

My colleague and I were four days into a field exercise for an environmental impact statement or EIS. An EIS is a document every public project must complete to show what the short and long-term impacts would be if it were completed. They tend to be large and expensive. This particular project was very large and the impacts many.

Given that the project was underway and had a definite deadline, no one was willing to slow it down or change its scope. This particular task was supposed to take the two of us about a week to complete.

Four days into this particular task, we found the data we had been given was poor, the people to contact with better data were unavailable, and that the massaging of the new data we couldn’t even get would take weeks.

When we presented the managers of the project with this information, we were told Don’t Slow Down, Just Get It Done.

Get it done with what?

The data you already have.

We were then expressly told not to contact anyone else or extend this particular task.

Back then, we were completely confused as to why anyone would be so totally stupid. How could these managers knowingly ignore that we were using faulty information that would result in a useless report? These weren’t Dilbert characters, they were real live human beings.

Over the years I would watch other seemingly smart people drive their high-tech startups into the ground by insisting that an initial plan or idea go forward despite ample evidence that all that lie ahead was ruin.

What cognitive biases kicked-in to destroy these endeavors?

Irrational Escalation – This is in-for-a-penny-in-for-a-pound-ism. Once people start on a project, they find it very hard to stop – even if the project is obviously doomed or the return will not cover future costs. The managers felt that the project was already underway and even using bad data was better than delaying the project and asking for new data. The bad data (not surprisingly) later resulted in obviously flawed analysis – causing even more expensive and stressful work later in the project.

Expectation Bias – This is a world-view bias. If we believe something, we pick data points that support that expectation. Further, we expect that most data will support our expectations. We had an opportunity to create a research regimen that would yield scientific results. The managers assumed this was all a formality and that any data (good or bad) would support the original plan. This was likely underscored by “experience” that showed that most data did indeed support the original plans (which were likely suffering from expectation bias).

Planning Fallacy – A central issue here is simply that we didn’t have enough time to finish our task. The expectation bias inherent in the people who wrote the initial scope gave us only a week. This led to them, and us, falling prey to the Planning Fallacy which shows that human beings have a strong tendency to underestimate task completion times. On the ground, we saw this playing out. From the manager’s desk, the plan was correct, we were at fault.

Status Quo Bias – This bias says that once we start something, we tend to want it to continue. This is why in Collaborative Management we seek to build an explicit Culture of Continuous Improvement for teams and companies. Making change and improvement the center of the culture makes change the status quo. Needless to say, this wasn’t the case with my project back then.

The upshot here is that biases can gang up on us. Our enthusiasm, belief in ourselves, and assumption that things stay pretty much the same can combine to create seemingly logical decisions that can turn deadly. My managers no doubt reasoned that the project plan took over a year to write by well-informed professionals. There was very little cause for concern that a small part of the project might derail the whole thing.

In the end, our re-work was hardly noticed because other parts of the project became late, with much higher costs. One can only guess that the same forces were at work.

Collaboration over Process

(This is the first in a Daily Thoughts series. I used to blog every day, but during the writing of the Personal Kanban book and creation of the Personal Kanban website, I fell out of practice. This is getting back to true blogging. Fast, unedited, perhaps a little more politically incorrect here and there.)

 

The agile manifesto said "Individuals and interactions over processes and tools".  For years, I did not question that principle.

Now, however, I would replace this with "Collaboration over process."  Here’s why:

What's happened with agile is that the rhetoric is so team empowering that it transforms teams into heroes. Like individual heroes, this divides them from the rest of the org. It turns them into inward focusing groups that are optimized for their own product and have a well constructed but ill-fitting interface into the rest of the organization. While it was team collaborative and was more collaborative with outside stakeholders, the rhetoric still focused on the teams.

But the teams are made up of individuals. And the team operates within an organization. And the team has outside resources. And the team has clients. There’s a lot going on with those outside interactions that need to be explicit.

I really took the Agile manifesto seriously. Like many, it was pinned on my office wall. I could bludgeon uncooperative employees or clients with it. I could wax eloquent about it. For me, finding its shortcomings was a painful and lengthy process. I slowly came to the realization that, as it had aged, Agile had codified, ossified, solidified into something you could easily do wrong and that was nearly impossible to do right. The words in the manifesto no longer represented what was happening in practice.

So, I began to strip away some of the trappings of over-loaded agile at my company. We replaced sprints with release cycles. We destroyed the product owner for a fully collaborative relationship with clients. When we started with kanban, it was game-on. In 2005, when we ran our first kanban driven project, we had a very different view of kanban - but even then visualization of flow almost immediately started to change how we worked.

Our process evolved rapidly during that project. At every standup people had a suggestion of how to make it better. There was a collaborative spirit not just for creating the software, but also for how the project was managed. We were no longer following a rule-book of best practices. We were building something that worked for that particular team building that particular software for that particular client.

In other words, the team had the freedom to truly optimize.

Don’t let anyone say you are doing a process “wrong" – find what your “right” is.

Image by @gavintech and shared by Venessa Miemis

 

 

 
--

Spechetti

When coders have crazy unreadable code its referred to as “spaghetti code.” Single strands of code are impossible to trace through the tangled masses coders can weave. When this happens, it becomes incredibly difficult to understand the original intent of the code, the order in which changes were made, and how to go about making things better. This creates something known as “technical debt”. As time goes on, the difficulty in interpreting the code makes it time consuming and expensive to expand upon or to fix bugs.

It strikes me that this is very similar to the specifications that I have seen through the years. At project conception, one person might sit down and write a spec. Between conception and the start of coding, any number of people might edit that spec, introducing, editing, or removing features from the project. As the project begins and progresses, the spec is altered even more. Change orders occur. Off-line detailed conversations are hastily added to the spec or worse yet, included as an addendum. Soon we have spechetti - a document that has been through the hands of many, with differing intents, reflecting dozens of unrecorded conversations.

Spechetti creates a type of “legal debt.” Teams are required to satisfy difficult-to-decipher legal code that can be easily interpreted differently by others. Conflicts grow as interpretations diverge. Interpretations diverge the more granular (and difficult to find) operational clarity is in the spec. This makes the product time consuming and expensive to finalize.

The goal for projects should therefore not be to create a comprehensive spec that can be argued about at completion, but to create a legal and management system that actually drives agreement, clarity, and good business decisions while the project is in-flight. To do this, emphasis is placed on contracting for operational imperatives and not implementation specifics.

Existing contracting mechanisms create legal debt as a matter of course. We need a new kind of collaborative, non-punitive contracting system that replaces mounting legal debt with a mechanism that actually creates social, creative, and business capital.

Well, that sounds easy doesn’t it?

Tune in next time for what will kick off a series on Agile Contracting.

Portfolio Careers / Portfolio Lives

My friend and microbusiness partner Jeremy is a well-rounded guy. He has a few consulting clients that give him the income he needs to get by and maybe a little more. But that doesn't take up all his time. In his spare time he's also dancer, and with his wife and a few friends is opening a Montessori school. But that doesn't take up all his time, so he worked with two other guys and myself to create iKan, the Personal Kanban iPhone app. But that doesn't take up all his time either, so he got together with a bunch of other guys and created Crowdmap an awesome shared mind mapping tool for the iPad.

So Jeremy is, as I said, my microbusiness partner. iKan is a microbusiness. The application has helped many people take their Personal Kanban with them when they are away from their home or office. But it's also only $4.99. With four partners, it would take a very long time for any of us to become wealthy from it.

But what I'm noticing is this: The new entrepeneurs the media  keeps touting are not out building companies with just sweat equity. That is nothing new and completely misses the point of the transformation that is taking place.

The previous career models of "I'm going to get a stable job and go to the office every day" or "I'm going to launch a startup and we're going to become huge and make millions" are increasingly viewed as the self-defeating, zero-sum games that they are. People are recognizing that full time-work is fleeting; that at-will employment means you have no job security. And hopping from job to job is stressful and forces you to give up all self-control.

Instead, people are collecting portfolio projects with residuals that, over time, will result in reliable income streams. This is a vital distinction, because when you have a huge time-sucking job with no hope of residuals, every hour you spend working is worth a set amount – regardless of how much effort you put in or how much value you create. 

This means that trade-offs between the rest of your life and work will always fall in favor of work. If your boss tells you to work until midnight during your daughter’s recital, you need to work. If you don’t, the zero-sum game means you lose disproportionately to the cost of the action. Going to the recital will always lose to not having a job and health insurance. But the action that night at work compared to your daughter’s recital? That individual trade off was likely in favor of your daughter.

Building a portfolio of microbusinesses with an underpinning of paid project work means you are building both good short and long term income opportunities. For a portfolio holder, the option of working that evening or spending quality time with your daughter will, appropriately, come down on the side of the daughter – and if it doesn’t, it will be because the trade-off was really worth it.

So Jeremy and others I know are placing themselves in a position where they can exercise life’s options with the least amount of external costs. This allows them to build not only a portfolio of projects they have worked on, but also greatly expands the portfolio of projects they can work on. In doing this, Jeremy and others have bought themselves a great deal of freedom.

The next time you think about work/life balance, consider this: have I placed myself in a position where I pay a penalty for choosing activities outside of work? Have I placed a tariff on my own happiness? Have I left myself unable to work on projects that will make me money, expand my capabilities, and provide an interesting challenge? How many of my options have I closed off?

The original image can be found here by TheAlieness GiselaGiardino²³

Working with the United Nations

Over the last six months, Modus Cooperandi has had the good fortune to participate in three United Nations projects. The UN's missions lend themselves well not only to collaborative management, but to lean and social media, too. While the UN will be quick to admit they aren't early adopters of the last two methods, they are nevertheless appreciative of the power of lean and social media, and are ready to begin implementing them in earnest. It's been exciting and rewarding to watch, and we feel privileged to be a part of this work.

Our three projects so far have been:

Collaboration eLearning Packages

UN Food and Agricultural Organization - Rome, Italy

Modus Cooperandi worked with a team of 20+ authors, editors, and eLearning specialists to build a comprehensive set of lessons around collaboration, community, and team building. Jim and Tonianne helped devise a group writing system using a variety of online tools to facilitate communication and collaboration. Additionally, we were principle authors on three sections of the eLearning package itself. Once complete, the system will be translated into six languages, and made available to UN staff and those interested worldwide.

OzonAction's 2010 Social Media Plan

United Nations Environmental Programme, OzonAction Unit - Paris, France

OzonAction is the UNEP's group which, with the ambitious goal date of 2010, helped phase out the manufacturing of ozone depleting substances (ODS) such as chlorofluorocarbons (CFCs). Now, in its second phase, two additional ozone-depleting chemicals are on the chopping block: hydrofluorocarbons (HFCs) and MethylBromide. While OzonAction could certainly use their existing and successful methods to meet their deadline for the removal of these two compounds, they've chosen to incorporate social media to eradicate them ahead of schedule. Their success in the past has not made them complacent, and Modus Cooperandi is helping to create a social media plan that will provide the organization with actionable steps that won't overtax their budget or their staff. The goal here is to provide the maximum benefit for OzonAction without getting caught up in the fads or hype of the social media movement.  OzonAction's goals are serious, and so their use of social media should be directed in a way to reflect that sense of gravitas.

2010 Human Development Report for Vietnam

United Nations Development Programme - Hanoi, Vietnam

Over the past two decades, with the rise of globalization, Vietnam has experienced unprecedented economic growth. With one of the fastest-growing economies in the world, Vietnam has graduated to a mid-tier economic power. For this nation in transition, the current global economic downturn has left Vietnam with both options and opportunities. Countries in the United Nations need to provide a Human Development Report (HDR) to guide policy and funding both internally and externally. In many cases, the HDR can be several years between issues, and Vietnam is no different. For this project, UNDP and the Vietnam Academy of Social Sciences (VASS) have gathered researchers and scientists from several different agencies within and outside Vietnam to create the HDR. The goal of this project is to have a full-fledge HDR, with detailed and directed recommendations, ready for the Vietnamese General Congress in October. Modus Cooperandi is facilitating this effort by implementing a collaborative management system, coaching researchers on collaboration as the document is authored. Rather than merely having a document constructed of distinct sections authored by independent researchers, the goal here is to bring all the researchers together and inform the sections with one voice, and in real-time. This should result in an end-product that makes consistent points throughout, as opposed to individual points in each section. Recommendations will then be bolstered by coherent arguments threaded throughout the entire document.

Bigger Ears Make You Dumbo

Consider how the movement of a meme across the social media landscape spreads what looks good on the surface, but is fetid logic underneath.  A few months back I spoke at Social Media Breakfast, Seattle about Social Media, Lean and the CIA. A big part of that talk covered the danger of companies assuming that merely listening to people through Twitter was a standard of success.

Now let me tell you a little story about a recent experience I had with Delta Airlines, and how it relates to Chris Brogan's quote regarding assumptions on the Internet.

I was flying back to Seattle from Viet Nam. I had a ticket, but no seat assignment on the leg from Tokyo to Seattle. I was told that this wasn’t a problem, I could get one when I checked in at the desk in Tokyo.

My layover in Tokyo was nearly 10 hours long, before my 10 hour flight back to the States.

No problem, I thought. I would quickly check in, and then enjoy the day exploring the city.

I wend my way through the intricacies of Narita Airport, finally finding the transfer desk. It was unmanned. It was about 7 am at this point, so I went to the information counter and asked when the Delta people came to work. 

They told me 11:30.

Well, that’s pretty inconvenient. But I got myself some breakfast and proceeded to wait. 11:30 came and went, and yet there was still no one at the Delta transfer desk. A little after noon the desk finally opened. It took 15 minutes for them to process my request, after which they informed me I would get my boarding pass and seat assignment 15 minutes before departure.

I inquired why, and was told my ticket was so cheap I didn’t get a seat assignment. I said that this was leg four of a ticket that went from Paris to Beijing to Hanoi to Tokyo to Seattle and all the other legs had seat assignments. At that point I was told tersely that I simply didn’t have a seat assignment.

“Okay, how do I avoid having this happen in the future?” I asked.

I got my papers pushed back at me and never did receive an answer. I have no idea how to make sure this doesn’t happen next time.

So, I’m stuck in Narita for 10 hours now because I need to make sure that the moment they open the gate, I’m first in line for a seat assignment. I do what any red blooded netizen would do. I tweet that I’m annoyed with Delta.

The next day, Delta’s big ears hear my pain and tweet to me:

So they heard me.

And so I DMed them. Now…look up.

My story wasn’t short. But I had to mash it into several 140 character statements because Delta didn’t actually give me a higher bandwidth way to have the conversation.

I told them the fastest possible version of that story. Without any further communication, Delta gave me 2,500 frequent flier points. I don’t even fly Delta! This was pretty much the equivalent of Charlie Brown winning 5 free haircuts. “My dad’s a barber and besides, I don’t have that much hair to cut!” he lamented.

 Delta’s ears might have been big, but their execution sucked. No, their listening is not what I will remember them for, but rather, it is their consolation prize I will forever associate them with. I still have no idea how to not get stuck somewhere waiting for a seat assignment. That was all I really wanted: simple information.

What should Delta have done? Let me now share a story from an earlier part of that trip.

Due to a communication snafu, Orbitz messed up part of my flight. At one point, I was in real danger of being stuck in Paris with no way to fly onto to Hanoi or, to return home.

I tweeted my frustration and Orbitz responded within minutes.

They immediately gave me a direct email address and a phone number to Kristi, a real person, who could help (and who could take the time to get the whole story). Orbitz then fixed the problem I had and one other I didn’t know I had. Then they told me how I could avoid having that ever happen to me again.

Orbitz had big ears, but more importantly, they also had helping hands.

Delta’s system is built on productivity. They feel they did a good job by moving me through their process and giving me something. Orbitz is build on effectiveness. (I cover the difference in this post). They found the real problem, solved it, and made sure I was taken care of. Rest assured, both experiences will have a lasting impact.

(Oh, and Kristi later wrote to say she was glad I made it safely to Hanoi, and to thank me for the tweet.) 

Personal Kanban Discussed on the Business 901 Podcast

In late March, I had the good fortune to be on Joe Dager's Business 901 Podcast.  The topic, of course, was Personal Kanban. Joe edited the conversation into two parts which can be found below:

Part 1

Powered by Podbean.com

Part 2

Powered by Podbean.com