Playing a bigger game

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.

I’m the problem

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?

Managing while creating; deadlines and deliverables

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.

Striking a dynamic balance

Bottom Line Program Cover

During my second year in business school, I co-produced the annual student variety show. My co-producer and I ended up dipping into our own shallow wallets to cover budget overruns.

To the best of my knowledge, it was the first time the show produced an artistic success and a financial failure. That was a decidedly un-business school result. Although we named the show “A Bottom Line” in homage to “A Chorus Line,” we lost sight of our bottom line in pursuit of our vision.

It’s taken me years to sort out the lessons contained in this experience. At a systemic level, it’s impossible to cleanly separate efficiency and effectiveness. It might have its merits as a rhetorical strategy but real world situations demand that you attend to the balance between them.

Efficiency concerns dominate because we’ve worked out most of those details. Effectiveness was the purview of a handful of decision makers near the top. Now, effectiveness matters to a wider swath of the organization. I believe this is true but, ironically, I don’t know how to make that argument effectively.

Yet.

What’s the point of mediocre ideas?

The best way to have a good idea is to have lots of ideas
Linus Pauling

This is an old observation, bordering on bromide. I’ve used it before and will most likely use it again.

This comes to mind as I was thinking about a chance encounter with my CEO as he came out of a meeting. Clare, another of our partners, had brought up a technique from on old self-help book and Mel wanted to know what I thought.

I was familiar with the book and the technique. I had read to book years ago and didn’t find the technique terribly helpful. I’m not naming the book, the technique, or the author because that isn’t the point. The point in the moment was that Clare had scored a small status point with Mel and I had lost a point. It comes to mind today as another aspect of trying to balance between efficiency and effectiveness in a work world that runs on ideas.

Linus Pauling isn’t the only fan of lots of ideas. We’re all familiar with brainstorming and the exhortations that “there are no bad ideas”, despite the mounds of evidence to the contrary. For all the popularity of brainstorming inside organizations, few seem to be aware of the evidence that it isn’t a particularly effective technique. How do you bring that evidence into an organization that is fond of brainstorming?

In an efficiency world you fire out ideas to ensure that you get credit for them. In an effective world you make choices to not waste other people’s time at the risk that your decision to skip the stuff you deem unimportant will never garner any recognition or reward.

I’m not generally a fan of sports metaphors but there’s something here akin to hitting in baseball. You can’t get a hit if you don’t swing. If you do swing, you’re more likely to miss than to get a hit. Swing and miss too often and you’ll lose the opportunity to swing at all. One challenge is learning to choose your pitches. Another is to figure out how to get enough at bats to get pitches to look at.

Operating from Values

 

Photo by rawpixel.com from Pexels“We need you back in the office now, Anthony’s team just got fired.”

Although not quite the crisis it might appear, I still had a problem to deal with.

Anthony was one of my partners. He was leading a training simulation with a team of our new consultants. The simulation was a recreation of one of our client engagements. We had taken a 12-week project and compressed it into a one-week scenario. The scenario attempted to recreate both the business issues and the look and feel of working in the field.

Anthony was leading a team of six junior consultants. The team would interact with the client via email, phone interviews, and face-to-face interactions with “clients.” The “clients” consisted of my small team manning the email and phones plus a couple of retired senior executives playing the role of the client CEO and CIO. We had a timeline, an outline of how the week should play out, plus a collection of documents and exhibits that could be shared with the consulting team as the work unfolded. Think of it as a giant case study that would unfold as the week progressed. It was more of a map than a script.

Whether a map or a script, there was no part of the scenario that included pissing off the client enough to get fired. Nevertheless, Anthony managed to do precisely that on Day 2. Moreover, my client CEO had ordered Anthony to vacate the premises immediately.

Bad time to have gone to lunch.

After a bit of strategizing with my team, we broke character and I facilitated a debrief of the “firing” with Anthony, his team, and the client. This offered the junior members of the team a peek into the dynamics of managing client relationships they wouldn’t otherwise have seen and gave us a path back into the simulation for the remainder of the week.

The ultimate test of this training strategy came a few months later as team members went out into the field for real client engagements. Their consistent report was “we’ve seen this before and we know what to do.”

Our training design was born of resource limitations. As much by luck as by design we had stumbled on deeper lessons for our work. We were learning how to navigate environments without a script and without rehearsal time. We were developing perspectives and practices oriented to an improv logic as the world demanded more responsiveness and adaptability.

I’ve come to believe that navigating this environment requires a shift in perspective and a set of operating practices and techniques that can be most easily described as improv adapted to organizational settings.

In place of detailed scripts, we were learning to operate from core principles and shared values. Our learning environment gave us a safe space to experiment with and work out how to apply those principles and values.

Racing ahead to what?

I went to an exceptionally good high school. That was courtesy of a nun in my parochial school who recognized I wasn’t being sufficiently challenged in the school I was in. That school got me into Princeton University. Moreover, it got me credit for enough college level work that I was on track to graduate in three years. I opted to major in Statistics on the theory that I could use that to pursue a graduate degree in any number of fields.

This seemed like an excellent plan for a kid from the Midwest on a mix of scholarships, my parents digging deeper than I ever appreciated, and work study jobs (including one as a dorm janitor). Going into my second year, I found better jobs as an electrician and stage carpenter at the university’s McCarter Theater. I also made time to get involved in student theater, so I wasn’t just grinding away at classes. Sleep was occasionally hard to come by but that was more about enjoying the experience than about working.

Midway through my second year I started to ask what was next. Not whatever argument I had made to get permission for my three year timetable but what was I actually thinking would happen when I did graduate. In my quest to move through the process as efficiently as possible, I had given no real thought to what that efficiency would buy me. I was approaching a finish line to one race with no real sense for what the next race was going to entail.

Nor did I have any words or concepts to bring to bear on these questions. My father had gone to college on the GI bill after serving in the Navy during WWII. He was the only one of his siblings to get a college degree. I was the first in my generation to think of college as a path to follow. My cousins were baffled; why would anyone spend the time and money for college when there were good union jobs to be had?

There was a huge amount of tacit knowledge I lacked. I was so ignorant I wasn’t even aware that I was ignorant.

Fortunately, I did something sensible despite my ignorance. I hit the pause button. I dropped back to a four year timetable. Slowing down was a necessary step. It bought me time to start figuring out the questions I needed to be asking.

Learning to ask better questions

In the Spring of 1979, I was wrapping up my first year in the MBA program. I had just agreed to serve as the President of the Computer Industry and Technology Club the following year. Clubs were a big part of the MBA experience and strategy for impressing prospective employers. My next task was to meet with the club’s faculty advisor and sponsor, Professor Jim Cash.

A fateful meeting.

Visicalc, the first spreadsheet program, wouldn’t hit the market until October of that year (far too late to help me with my Finance class). Computers in general were something that happened down in the engine room, not on the bridge. Information technology was low on the list of priorities of the aspiring CEOs who were my classmates.

Professor Cash was part of a small cadre of faculty working to change that thinking. I had spent the three years between university and business school working as a consultant and systems analyst. I thought information technology belonged pretty much everywhere in the organization. We bonded quickly.

During the course of my second year in the program, Jim tried to persuade me to go into the doctoral program. It took another five years before I finally agreed, which is another set of stories in its own right.

Central to Jim’s persuasion process was taking me behind the scenes of “the case method.” Every class session was organized around a written case study of a specific business situation. Should we invest in another Jumbo Sorter to speed up the processing of cranberries? What do we do about the supervisor on the plant floor who is harassing female workers on the line? How do we move more diners through our restaurant tonight? The case writeup might include some background on the company and the industry (or it might not). Perhaps there would be some exhibits with budget numbers or forecasts. No textbooks. No syllabus with clues about what the underlying topic might be.

The first days of learning by the case method can be profoundly disorienting. Today you can Google “how to crack a case”; in 1979 you sought advice from older students or compared notes with your colleagues. Regardless, it is fundamentally, and by design, learning by doing (see Learning from cases; getting smarter by design - McGee’s Musings for more if you’re interested).

Like most of my MBA colleagues, I came into the process thinking that business, and learning, was about answers. But you can never get the right answers if you’re asking the wrong questions. Perhaps more accurately, you can’t get good answers if you ask poor questions.

The challenge that Jim laid down for me was did I want to continue to improve my ability to pose better questions.

 

 

 

Struggling with being a cog

One of my earliest jobs was as an accounting clerk with McDonnell Aircraft Company (now part of Boeing). I’ve written about it before (You can’t win. Play anyway). This was the summer after my first year at university. I had elected to major in Statistics.

One morning my supervisor asked me to calculate the mean and standard deviation for a schedule of numbers he dropped on my desk. In 1972, this was a largely manual task that took me a modest chunk of my morning. I turned in the results and asked why he needed them.

His answer was “I didn’t need them but figured you’d like the opportunity to calculate some statistics.” I believe he was being sincere rather than hazing the new kid. I was less than thrilled with how I had spent my morning.

The standard advice in these kinds of situations and settings revolves around “paying your dues” and “fitting into the system.” This advice is based on a hidden assumption; that those paying the dues actually fit into the system. The industrial system was designed around components of fixed intelligence and constrained ambition.

I was not that kind of component.

Distinguishing Maps and Territories

It was September of 1971. I was on a bus leaving the Port Authority Station in Manhattan heading into New Jersey. My day had started in St. Louis. I was traveling with a friend from high school who claimed he knew what he was doing. Our destination was the campus of Princeton University.

In those days you didn’t visit multiple campuses before deciding where to go so I had no idea what to expect. Kevin’s plan was to fly into New York and take the train south to Princeton. I seem to remember that in addition to my suitcase, I had a new typewriter and a tennis racket. I don’t recall that I had ever actually played tennis so why I had a racket seems a bit suspect.

We flew to LaGuardia Airport and took a bus into Grand Central Station where we discovered that the trains from Grand Central went north. Southbound trains to New Jersey left from Penn Station. The ticket agent pointed towards a corridor and told us we could simply walk a few blocks underground to change stations. New York City was not a welcoming place to a couple of naive teens from the Midwest. We wandered through tunnels in the heat and humidity. Eventually, we somehow stumbled our way into the Port Authority Bus Station and bought a bus ticket to Princeton (it was several years later before I ever set foot in Penn Station).

The bus to Princeton travels through the Lincoln Tunnel, through the streets of Newark (a city I knew only as a place that had seen riots three years earlier in 1968), past oil refineries, and onto the New Jersey Turnpike. This naive child from the suburbs in the Midwest was on sensory and emotional overload. I was fingering the dime in my pocket and formulating the call to my mom to come rescue me.

Eventually we left the Turnpike and turned onto Route 206 which winds through the farmland that gives New Jersey its nickname, the Garden State. Route 206 turns into Nassau Street and the bus dropped me at the entrance to the Princeton Campus. The image above is Nassau Hall, my first impression of where I would spend the next four years. The dime stayed in my pocket.

“The map is not the territory” was a dictum offered by Alfred Korzybski, a Polish scientist/philosopher who developed the field of general semantics shortly before WWII. It’s a reminder that expectations and reality rarely coincide and you would be well-served to check how, where, and why they differ.

That day was a series of collisions between expectations and reality complicated by the confounding factor that I didn’t recognize how many unexamined expectations I was carrying in my head. Traveling that territory that day planted another seed in learning how to draw better maps and in recognizing that map-making was a tool I could use deliberately to make sense of the new territories I was trying to travel.