Quality and Innovation

In July, Paul Graham posted an article called “Maker’s Schedule, Manager’s Schedule“. He points out that people who make things, like software engineers and writers, are on a completely different schedule than managers – and that by imposing the manager’s schedule on the developers, there is an associated cost. Makers simply can’t be as productive on the manager’s schedule:

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.

I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning.

This concept really resonated with us – we know about the costs of context switching, but this presented a nice concept for how a developer’s day can be segmented such that ample time is provided for getting things done. As a result, we attempted to apply the concept to achieve more effective communication between technical staff and managers. And in at least one case, it worked extremely well.

Case: Ron DuPlain (@rduplain) and I frequently work together on technical projects. I am the manager; he is the developer. More than we like, we run into problems communicating, but fortunately we are both always on the lookout for strategies to help us communicate better. We decided to apply the “makers vs. managers” concept to meetings, to see whether declaring whether we were having a maker’s meeting or a manager’s meeting prior to the session would improve our ability to communicate with one another.

And it did. We had a very effective maker’s meeting today, for example… explored some technical challenges, worked through a solution space, and talked about possible design options and background information. It was great. As a manager, I got to spend time thinking about a technical problem, but temporarily suspended my attachment to dates, milestones and artifacts. As a developer, Ron got the time and attention from me that he needed to explain his challenges, without the pressure of knowing that I was in a hurry and just needed the bottom line. As a result, Ron felt like I was able to understand the perspectives he was presenting more effectively, and get a better sense of the trade-offs he was exploring.

We had the opportunity to meet on the same terms, all because we declared the intent of our meeting up front in terms of “makers” and “managers”. Thanks Paul – this common language is proving to be a powerful concept for achieving a shared and immediate understanding of technical problems.

I’m out in Colorado this week working with the NEON cyberinfrastructure team to put together presentation material for a big review meeting they’re having in June. It’s a challenging project, chock full of interesting and complex envisioned science experiments, elaborate engineering to design, construct and collect data from sensors scattered all over the country (and even airplanes), and the need for a high-performance interconnected software and hardware architecture to keep it together and maintain the data flow.

In short, it’s a hugely complex project – and for these presentations in June, we may only have an hour to condense all that technical information down into something understandable, well-organized, and compelling. How do we do it?

The answer: using effective storytelling. Quite randomly and serendipitously, I ran into a blog post by Chris Spagnuolo this morning (Twitter: @ChrisSpagnuolo) called “12 Things I learned from Story Time”. Apparently he went to the library recently with his 3 year old, and while listening to the story and observing the behavior of the children and the storyteller, extracted lessons for professional presentations. (I have a 3 year old too, so this post really connected with me!) Here’s a snippet of his insight into how to give a high quality presentation:

Ah, the expert mind…it always convinces us that we can’t learn from “simple” experiences. But after it was over, and I reflected a bit on Story Time, I realized that there were valuable lessons to take away from it that we can all use in our presentations. Believe it or not, librarians and others who read to children at Story Time may be some of the best presenters in the world, and we’ll never see them on TED or hear much about them (plus they have some of the toughest audiences in the world). If you really want to get your presentation game on, maybe you should start reading books to the itty-bitties at your local library.

I’ll encourage you to click through to read the 12 lessons. The suggestions complement Stephen Denning’s insights into storytelling as a leadership tool as well. Thanks for sharing, Chris.

Two days ago I commented on how technical jargon can either enhance or impede communications. I ran across this quote today from the 1987 book Thriving on Chaos by Tom Peters along the same thread, and thought I’d share:

Mostly, it’s the dumb, elementary questions followed up by a dozen even more elementary questions that yield the pay dirt. Experts are those who don’t need to bother with elementary questions anymore – thus they fail to bother with the true sources of bottlenecks buried deep in habitual routines of the firm labeled “We’ve always done it that way.”

We can only uncover changes in our expectations, and changes in our underlying assumptions, by asking simple questions over and over. The “5 Why’s” – that I mention in Real or Not Real – are another way to figure out what rudimentary questions to revisit to unlock insight. Remember that unlocking insight is a critical step for you or your organization to increase innovation.

I was talking to a group of professors from James Madison University yesterday, when the topic shifted to “discrete event simulation”. They asked me if I knew anything about it – I said no. I don’t think I had ever heard of those words strung together in the same phrase, and so immediately assumed that this domain was just something I had never been exposed to. They also told me that they were using ProModel to do a lot of their discrete event simulation.

I’m addicted to learning new things, so I checked out to see what ProModel was all about so I would know what “discrete event simulation” was. And guess what! That’s the term for plant layout, for simulating new manufacturing processes, for designing kanban systems, for designing supply chains and other networks, for setting up queueing systems, for doing SPC and for managing your Six Sigma analytics. So I guess I do know something about “discrete event simulation”! I’m also wondering why I’ve never seen this product advertised in Quality Progress – it looks like it’s pretty good, and pretty comprehensive.

This reminded me that jargon can impede or enhance communication, depending upon the capabilities and understanding of the communicators. Neil Ward-Dutton, in a December 2006 post, collected some articles on this theme and reflected on them in “On jargon, and creating a common language.” He contrasts a message about the benefits of Web 2.0 presented in two ways: one filled with technical jargon, explaining the way it came to be, and one explaining the same thing but from the perspective of how Web 2.0 influences and affects people. The use of jargon – or the avoidance of jargon – can either communicate competence in a field or alienate people who need to know more about it.

Awareness of whether a term or a phrase is jargon can help us understand whether we are communicating accurately.

If I was aware of the nature of the term “discrete event simulation” I would have said “Sure! I really like discrete event simulation. In fact, I really enjoy designing plant layouts (which can be useful for designing software systems too), I am insanely enthusiastic about inventory models, and these are the kinds of analytical things that we do in Six Sigma projects all the time.” But no, I missed an opportunity to communicate – and maybe even to learn new things about modeling – because of jargon.

It reminds me of when I was a meteorology student several years ago. In one of our dynamics classes, I was dumbfounded by the number of times the professor referred to “zonal” and “meridional”. I had no idea what these two words meant – I could guess, but I might be wrong – so I searched all through our textbooks to find anything that would tell me about these two words. They were NOWHERE. And the dictionary was no help either. So one day I asked the professor, in class, what “zonal” and “meridional” meant. Her response is etched in my psyche forever: “If you don’t know what those words mean, then you shouldn’t be in this class.” Now this was in the days before Google, so I couldn’t just go look it up. What do you think I did? I felt totally embarrassed, crushed because I didn’t know something that was apparently so easy, decided to hide my lack of knowledge, and struggled through the class. I was even too embarrassed to ask my classmates. Years later, when I figured out the answer to my simple question, everything fell in place and I understood what went on!
The far more constructive answer from my professor would have been: “Zonal refers to the east-west direction and meridional refers to the north-south direction. So if we have zonal flow, it’s oriented predominantly east to west, and if we have meridional flow, it’s oriented primarily north to south.” My response would have been “Excellent! That’s simple! Now I understand what the equations are trying to say!”

The lesson here: no questions are stupid. Sometimes, a stupid question just reflects that someone’s trying to break through the barrier of jargon. This is a positive thing – it means they’re trying to figure stuff out! After this experience with my dynamics professor, I vowed that I would never think someone was totally stupid if they were asking (what I thought was) a simple question. I hope my coworkers and staff members feel that I’ve followed through on this.

(It reminds me of another time in that same course. We did a lot of multivariate calculus and differential equations, and the professor kept referring to “zed,” but for the life of me I couldn’t find the “zed symbol” in any of the equations. And none of my books would tell me what the “zed symbol” looked like. I’ll leave this joke as an exercise for the reader.)

The title above comes from a Newsweek article published on October 14, 2008. The moral of the story is that recent research in neuroscience indicates that use of modern technology – in particular Web searching – actually exercises the decision making and complex reasoning parts of the brain. The end result is that younger people who are more attuned to life in cyberspace have more finely developed skills in these areas, whereas those who are not as steeped in the web are better at social skills and reading emotions from facial expressions.

“The more time you devote to a specific activity, the stronger the neural pathways responsible for executing that activity become.”

Gary Small, who leads a research team at UCLA, recently published an article in the American Journal of Geriatric Psychiatry that explains these finding in depth, and suggests that a “simple task like searching the web appears to enhance brain circuitry in older adults.” What does this news have to do with managing your organization? It helps you understand how to manage change by pointing out that certain activities can be strategically applied to develop specific parts of the brain.

These phenomena are comprehensively explained in the 400+ pages of Schwartz & Begley (2002). By studying obsessive-compulsive disorder, Schwartz learned about how the brain rewires itself to deal with problems and heal from wounds and uncovered much of the theory that’s being refined and developed by researchers like Small.

One of the lessons from this tome is that “practice really does make perfect”. You should give your employees time to build their capabilities and continually refine their skills – try not to rush them. “We have the ability to bring will and thus attention to bear on a single nascent possibility struggling to be born in the brain, and thus to turn that possibility into actuality and action.” There is a biological basis underlying the idea that people need the time to focus to turn an idea into action.

I remember a few years ago hearing about a study that claimed using Microsoft PowerPoint makes you dumb. On the basis that effective communication can either enhance or hinder quality improvement efforts, I decided to look back today and see a) where that information came from, and b) if it’s accurate. Given that over 400 million people used PowerPoint in 2003, the number of people who use it today (or other comparable presentation software, like OpenOffice) is probably even larger.

A December 14, 2003 article in the New York Times referred to a NASA report which examined the root causes of the Columbia disaster. Among other issues, PowerPoint was implicated:

”It is easy to understand how a senior manager might read this PowerPoint slide and not realize that it addresses a life-threatening situation,” the [NASA] board [reviewing the project] sternly noted.

My advice would be for senior managers preparing these presentations to communicate more deliberately, in words like “THIS IS A LIFE-THREATENING CONDITION!! IMMEDIATE ACTION REQUIRED!!” Unfortunately, that might be perceived as “too easy” or alternatively, the senior managers might not have wanted to admit a problem for fear that they would lose their funding. In any case, respect for human life should come above all, and should certainly be a reason for bare, clear communication – regardless of whether the message is delivered by PowerPoint, in person, or as part of a 40-lb., 500-page treatise.

The same New York Times article references a brochure by Edward Tufte, a well-regarded information theorist who has written a book on effective data visualization and gives seminars across the country on that subject. You can get his brochure, The Cognitive Style of PowerPoint, at AmazonAccording to the New York Times:

Ultimately, Tufte concluded, PowerPoint is infused with ”an attitude of commercialism that turns everything into a sales pitch.”

I would think that the burden of communication is on the communicator. There are many times where we only have a few minutes or an hour to convey a complex message, and for this, PowerPoint can be effective. However, if there’s a message that cannot be conveyed in simple terms, it’s up to the communicator to say so, and in really simple language, e.g. “this is a grave concern, and you need to review the complete report, now!” Easier said than done, I know.

But a far more complete review of the Tufte brochure at http://contactsheet.org notes that Tufte specifically argues against this position, noting that communicators are just victims of the product’s lack of user-centered design. Is the criticism of PowerPoint accurate? Possibly – I didn’t read the in-depth study so I don’t have a reason to believe or disbelieve the causal link between PowerPoint and stupidity. However, the recommendation ignores one critical element: that if the material is indeed comprehensively described in a much larger memo, people may or may not read and comprehend it.

However, let’s say you’re a patient in the hospital facing a life or death diagnosis, and a team of physicians is charged with solving your mystery. Do you want them making a decision based on the PowerPoint version of your case, or on all 800 pages of your medical history? Personally, I’d vote for the latter. But I would also insist that the medical team be given appropriate time to review, internalize, and reflect on the information before making a decision. This is a step that unfortunately has become a luxury in many organizations! Bottom line – the burden still remains with the communicator for now.

Buss (2006) doesn’t argue with the premise, and just writes about ways to use PowerPoint effectively. His article provides five tips from a professor in the Graduate School of Business at SUNY Albany. Starting with the premise that PowerPoint is ubiquitous in training sessions and presentations, the author first recommends that we subvert the linear “title and text” format that everyone is accustomed to because it does not capture peoples’ attention. Though this point is a sweeping generalization that is not substantiated, one opinion of the author is to remedy the situation by “switch[ing] the display order of the presentation. Present supporting data with points on the first slide and show the data and draw the conclusions on the next.” He also suggests that PowerPoint first be used to outline a message, and then a report should be written to expound upon the details, rather than the other way around. Buss also recommends to keep the information per slide short (though he does not suggest a “good” length for training slides), and provides the clichéd guidance that one should not merely read out his or her slides. The best advice is given in the author’s fifth point, where he recognizes that the presentation begins well before you start talking, and ends until your meeting is over. He suggests that the presenter mix with the audience to get a sense of their needs, and target those needs in the spoken presentation.

A related article, discussing Talking Heads vocalist David Byrne’s view of PowerPoint as art, is also entertaining.