McGee's Musings

Our family moved to St. Louis in the Fall of 1964. I was 11. Mostly this was hugely disruptive for a bookish, introverted pre-teen. A year later, I was switched from the parochial school just up the hill to a private all-boys school, a 40-minute drive away.

One of the saving graces in all of this turmoil was my dad’s new job. He had moved to St. Louis to become one of the lead test engineers for the Gemini spacecraft built by McDonnell Aircraft.

How could it get any better for someone absorbing every science fiction title he could lay his hands on at the local public library? Everyone was following the space program. My dad was part of it. I had pictures of him working with the Mercury and Gemini astronauts. I was a nerd before there was a word for it.

All of this directed my gaze outward. Not terribly unusual for a young boy in that time and place. What I also had was a glimpse at the complexity behind the scenes. Everyone saw the show on TV. I saw the testing and rehearsal and adapting that happened before or on the side. I didn’t have the words or the concepts for it at the time, but these were the seeds that grew into my fascination with innovation and creation.

Efficiency is boring. It’s interesting only to those who like piling things (money) up. Efficiency is isolating and inward looking. It stops at the edge of the system. You can’t even begin to think about it until you’ve worked out all the hard (and, therefore, interesting) problems.

The first few times you try anything new, you have to settle for effectiveness. Did it work?

That means looking at the bigger picture. How does this new thing fit in with and interact with the larger system? Effectiveness is about constantly running experiments in the real world. Can you make some predictions about what might happen next? What potential catastrophes do you have to guard against?

To me, I’ve always been mystified by those people who settle for efficiency. Who are content to do the same thing once again. Where’s the fun in that?

You get the behaviors that you reward. A truism of management.

A quick glance at my resume would persuade most people that I’m book smart. I got rewarded for doing things that schools find easy to reward; taking tests, making the teacher look good, saying clever things (at the appropriate time and place). So I continued to do those things.

There’s an implicit (and unexamined) assumption that the things that get rewarded correlate with underlying knowledge and skills in a broader way. Doing well on the tests was taken as a marker that you were putting in the necessary work employing (and developing) the more general learning and study skills that would stand you in good stead later on. Not necessarily the case. I got a lot of things on raw horsepower rather than on good work habits.

Other elements of the surrounding environment are meant to provide guard rails. Study groups, working with fellow students on problem sets, socializing with the group who had ways to police those who varied too far from the norms. For a variety of reasons that don’t bear on this tale, those other elements didn’t apply to my circumstances. I wasn’t part of the “classes” that took place outside of the classroom. I was in front of a pack that I didn’t know existed.

For a long time, I found myself in settings where I could prosper operating inside of systems that I couldn’t see. I would hit speed bumps that I attributed to other people being stupid or to me not being smart enough to outthink the problem. I was glib enough to talk my way out of most of the problems I found my way into. I wasn’t insightful enough to see how many of those problems were of my own creation.

I started building a theory built around stupid people and how to avoid them. There is enough actual stupidity in the world to make this a dangerously seductive theory. Fortunately, as a scientist at heart, I was committed to following the evidence. Everyone else couldn’t be consistently that stupid. It wasn’t stupid people, it was me being people stupid.

There’s a longer version of the quest to follow this line of thought. For now, it’s enough to note that looking inward was the essential step. For all that I was a quick study in knowledge intensive settings, I was slow to grasp how to navigate this terrain. The tests weren’t something I could power my way through. Not alone. I had work to do on learning to balance my head with my heart. Complicating that was an additional factor; attention deficit disorder. We can save the discussion of whether ADD is over diagnosed or not really a disorder. What was important to me was learning that there were things others found easy that I found nearly impossible. Raw IQ points and a quick wit were not the answer to every problem.

I didn’t discover any of this until well into my career. Raw IQ points and a quick wit can take you a long ways. Just not all the way. I’m still working to develop skills and compensating techniques to deal with the limitations of my brain.

The essential step to dealing with any problem effectively is to be able to name it.

Alan Kay has been one of my heroes for a long time. Feel free to Google him if the name doesn’t trigger anything for you. One of my favorite Alan stories comes from his early days at Xerox PARC. Xerox PARC comes from the days when smart organizations carefully walled off the crazies from the rest of the organization in search of new ideas.

Xerox PARC was situated in the heart of Silicon Valley, a continent away from Xerox headquarters in Connecticut. A team of executives was on site to review the work going on in Palo Alto. Alan and his team of software engineers walked through one of the research projects underway. Alan carefully explained that this was ongoing research; experiments were as likely to fail as to succeed and the goal was to learn something interesting that might lead to the next experiment.

The suit from Stamford nodded along in approval. His closing remark was “I understand, but you’re only running the experiments that succeed, right?” In his universe, “failure is not an option” was not a motivational challenge, it was a risk to be avoided at any cost.

If you commit to the path of asking questions, you also commit to the reality that you often won’t get answers. You’ll certainly get answers you don’t want.

The false promise of efficiency is that you can guarantee control. You carefully limit the questions and the answers to obtain that control. And, that can work for a time. If nothing important changes.

Reorienting from efficiency to effectiveness is, at heart, accepting that important change always happens. There are no guaranteed answers but you have to keep asking the questions anyway. Your only salvation is developing deeper skill at asking more effective questions.

I’ve spent a lot of time in and around theaters, most of it behind the scenes. Everything you do is about the experience you want to evoke from the audience.

There’s no point to paint the back of a set.

If the audience can’t see it, it doesn’t exist. You often spend a good bit of time figuring out “sight lines.” Can everyone in the audience see what you want them to see? Not see what you want to conceal?

This is at the heart of learning to be effective. What is the end effect you want to accomplish.

I went to business school long enough ago that Fed Ex was still a relatively new company. We had a case study in our marketing class about the rollout of a new service called the Courier Pak (Yes, this was a long time ago).

Someone in the class thought it would be a clever idea to send a Courier Pak to our marketing professor. It would contain items from earlier case studies. We went to the local Fed Ex office to arrange to send the package and have it delivered during the next day’s class session.

The manager of the local Fed Ex office was a very smart person. Rather than send the package through the Fed Ex system and risk a late delivery, they stored the package in the safe overnight and delivered it personally to class the next day. We got our joke and Fed Ex protected its image. Actually sending the package was an unnecessary risk.

The first step is always to work out what the problem actually is.

Back in the mid-1980s I was running an internal project for the consulting arm of Arthur Andersen & Co, before it split off to morph into Andersen Consulting and then Accenture. We were creating a system development center to provide all of the tools and facilities to support large scale systems implementation projects. This was in the day when serious development was done on mainframe computers and setting up an environment for productive work could chew up a lot of time and fees without adding value for Andersen or its clients. The centers turned out to be a successful venture for several years.

Setting up the first one was a large scale project management problem in its own right. There were some challenges in creating a work plan and work breakdown structure for something that hadn’t been done before, but nothing out of the ordinary.

One odd conversation from that effort still sticks with me. It was Monday morning, well before 8AM, and I was parked in a partner’s office. I had learned that the only way to guarantee Mel’s attention was to catch him before he got wrapped up in anything else. He rolled in a short time later and the conversation unfolded like this:

Me: I’ve been going over the project plans for the development center. We’re on track, but I’m worried about the scheduled install of the mainframe next month.

Mel: So?

Me: Do we deal with it now or wait until it’s a full blown crisis?

Mel: Wait until it’s a crisis

You need to understand that Mel was an excellent manager and leader.

I was greatly puzzled.

Isn’t management supposed to be about anticipating problems and dealing with them before they get out of hand?

Working out why Mel was right and I was missing a bigger picture took me back to graduate school and eventually a Ph.D. in organizational design and innovation. It isn’t enough to have the right answer for the problem at hand. The right answer, deployed at the right time, gives you the opportunity to continue to play the game. Eventually, it may give you the opportunity to shape the game to make it a better game.

It was an actual shower aha moment.

My business card said that I was the Chief Knowledge Officer for the hot consulting firm. We had a NY Times bestseller on how to compete with this new thing called the Internet. We had our pick of clients and our pick of MBA graduates. In seven years we had grown from 25 people to over a thousand.

I was trying to solve the problem that all knowledge management people were fighting. How do you get smart people to share what they knew with the other smart people in the organization? Incentives didn’t seem to work. Neither did measurement and reporting systems. Or formal systems and practices.

One morning in the shower it hit me. I was the problem. Not that I was doing a bad job as CKO for the organization. I was doing a bad job as a knowledge worker sharing knowledge with myself. Until I could share knowledge with myself, I wasn’t likely to share it with anyone else.

The smart people in my organization weren’t hoarding knowledge out of some Machiavellian desire to enhance their position. At best, they were struggling to identify what it was they knew that was worth sharing. At worst, they were embarrassed at how woefully haphazard their personal practices and systems were at surfacing knowledge and insights that felt worthy of sharing.

Adopting a new perspective on a problem sets off a chain of reasoning. Knowledge management as a personal problem rather than an organizational one pushes you away from questions of efficiency and towards questions of how to think about outcomes and effectiveness. Can you put systems and practices in place that nudge individual knowledge workers towards finding more effective ways to learn from and leverage their experience?

I’ve told the end of this story before (Preparing to be bold in the moment). Two days after my 20th birthday, I told the director of the show I was stage managing to “get off my stage” as we were about to raise the curtain on our final dress rehearsal before opening night. Tony was one of three paid professionals working with us to produce and stage an original Broadway-scale musical. Brave and bold, I was asserting my legitimate authority as the stage manager. The curtain went up on time. The show did indeed go on.

Let’s back up about six weeks. So, for starters, I’m 19. It’s my second year in university, although I’m enrolled in classes as if its my third year. As stage manager, I’m responsible for scheduling and managing all the rehearsals for a cast of 40. I’m also coordinating with the set designers, technical director, and band leader over all the activities that go into getting the show onto the stage. A show that is still being written and has never been done before. Also, I’ve never done this before. Opening night is a fixed target but little else is.

To my professors, I was a name on the class roster that they hadn’t seen for weeks. To Tony, I was the guy he yelled at when he wasn’t stoned. I can’t remember the specific incident, but there came a day. I had failed at some element of my job that I didn’t know existed and got chewed out once again.

I left a note for the President of the group and disappeared. I was done. I was going to go back to school and see exactly how far behind I was in all of my courses. Brian found me several hours later deep in the recesses of the University library. He figured out it was the one place no one would think of looking for me.

I got talked off the ledge. Tony was still an ass. But, “the show must go on” is a very powerful argument. I did make it clear that I wasn’t likely to take any more crap from Tony. Which I demonstrated six weeks later.

This was also a critical incident in defining how I think about deadlines and deliverables. Deadlines are concrete. Deliverables are squishier. Sometimes, you tweak the deliverable to hit the deadline. Sometimes, you squeeze more effort in as the deadline looms. Renegotiating the deadline is a sign of failure.

All of this is premised on being able to describe and define deliverables with precision. Pretty straightforward if you’re turning out the next black, Model T. Manageable if you are delivering your 100th audit report. Things get more complicated if you’re inventing a search engine for this new thing called the Internet.

The more you move toward the creative end of the ledger, the more tenuous the connection between effort and outcome. It’s possible to force the process into a deliverable model. This is why, for example, so many consulting reports gather dust. Asking what answer could make a difference in this specific set of circumstances means risking real failure. Building the courage to face that risk takes time.