Picking an organizational stack

I suspect my early experiences with organizations were similar to most. Most of what we encountered was pretty simple to see and understand. We were students in a classroom, there was a teacher in the front of the room and a principal down the hall. Add a librarian, a school nurse, and the cafeteria ladies and you pretty much had it all.

At the other extreme, we tried to get the phone company or the Department of Motor Vehicles to help with a simple problem and encountered bewildering complexity. Why organizations looked the way they do wasn’t a question that occupied much of my attention.

My path to organization change and design was by way of programming and information systems design. What I learned in systems design was that complexity was the enemy. You had to understand the complexity of the problem you wanted to solve for there to be any hope of crafting a solution. The biggest mistake you could make was to miss some essential element of the complexity. The second biggest mistake was to add complexity by accident with your solution.

My technology training and experience tackled complexity with notions of designed modularity and looking for the natural places to carve the overarching system into discrete pieces.  There’s a rich assortment of models for thinking about problems of organizational design. I’ve taught them and I’ve used them. What I’m working through now is whether I can articulate a stack of organizational ideas that might help keep the complexity under control when looking at a new problem.

One organizational stack that intrigues me is

  • Purpose
  • Power
  • Process
  • Practice
  • People

I like the alliteration and I think the layers are largely self-defining/self-explanatory. I can see how I might map what I observe onto layers and how I might navigate up or down the stack while exploring a design question.

I’m now curious whether this cursory perspective is enough to generate some reaction.

Turtles all the way done: hijacking stories to your own ends

Turtles all the way down
Terrapin stack

There’s an old parable that I first remember encountering in Stephen Hawking’s A Brief History of Time. It often surfaces in explorations of the collision between science and myth. In Hawking’s retelling, the story goes like this:

A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the centre of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever,” said the old lady. “But it’s turtles all the way down!”

With the recent resurgence in adherents to belief in a Flat Earth, this tale is offered as a cautionary reminder of the power of compelling myth in the face of plain old evidence. That’s an important reminder in a world buffeted by change. Whatever your commitment to reason and evidence, you only replace a story with a better story.

I want to see if I can hijack the turtles metaphor to my rational ends.

My interests are in connecting technology and organizational realities. I’ve used the obvious image of building bridges but that may be too simplistic to be helpful after everyone nods that a bridge would be nice to have. Perhaps a stack of turtles can help us navigate the space between.

The realm of computing and communications technology is still a relative newcomer in organizational settings. Learning to wrestle the complexity to the ground is a key task in developing comfort and proficiency with technology. One of the principal methods of getting technology under conceptual control is the notion of a stack; of discrete layers of technology the interact with one another in sharply constrained ways.

There is a well known observation about dealing with technology first offered by computer scientist David Wheeler that:

All problems in computer science can be solved by another level of indirection

When things become too complex, we hide the complexity underneath a new layer of abstraction. Tim Berners-Lee invents a scheme, the url, that hides the details of reaching out to another computer and grabbing a file or document. Pretty soon, we’re watching reruns of I Love Lucy in our web browsers.

The number of layers you might traverse in  any given technology environment can become quite deep. The design challenge in new technology often revolves around how cleanly you can define and navigate the stack of layers.

Which brings me back to my turtles. What if we extend the stack upwards from the technology into the organization? Don’t think of the process as a single step across one bridge. Think in terms of what new layers (or turtles) make sense to cross the span. Now your problem is one of working out how to move up or down a layer at a time.

You can’t win. Play anyway

Holloman AFB F-4 Phantom II

One of the first office jobs I held was the summer after my freshman year in college. I worked for McDonnell Aircraft Company. as a material accounting cost clerk. MDAC was a defense contractor that made F-4 Phantom Jets and the Gemini space capsule among other things. Today it is part of Boeing.

I was a very lowly cog in a large complex system. My job was to write up the accounting entries to make sure that the inventory systems were in sync with the actual inventory. Some auditor would go out on the factory floor and count how many left-handed wing tips were sitting somewhere along the assembly line. My entire job was to compare the auditors count of actual inventory with the number recorded in the accounting system and then write out the journal entry to adjust the number in the accounting system to match the number that the auditor had found on the factory floor.

It was as mind numbing as you might imagine. I wrote the entries by hand onto paper forms that had to be reviewed and approved by my supervisor and then sent off elsewhere to be punched onto punch cards and fed into the computer located three buildings away.

There is one entry that sticks in my head. The auditors reported that they had counted three Pratt and Whitney jet engines on the floor. The accounting system thought there were four. How do you lose a 16-foot jet engine? Not my problem and no one else seemed terribly concerned. I wrote up the journal entry and it happily flowed off into the system.

You don’t design and build fighter jets with a handful of smart people. You need a complex system of people and processes and technology working together to pull it off. People, process, and technology is one of those cliches that gets thrown around a lot in organizations. I didn’t know the cliche at the time, but I was living in the middle of its reality.

This was when I began to grasp the complexity baked into large organizations. There are two choices for how to play in this environment. One is to be content with occupying a particular niche in the greater whole. The other is to wonder how it all fits together. Clearly, I opted for door number two.

I chose the word “play” intentionally. There is another lesson that I found in my time as a clerk. You have to accept that systems don’t always match reality. You have to build in mechanisms for correcting when systems and reality fall out of sync. And those mechanisms have their own weaknesses. Complexity and perfection are not reconcilable. Order is always battling chaos.

When I was learning physics, we learned about the second law of thermodynamics and the notion of entropy. There was some nasty math involved but our teacher summed things up this way:

Life is a game. You can’t win. You’re going to lose. You can’t get out of the game.

That leaves you with the option of playing simply for the sake of playing. A good lesson for all seasons.

Ritual by design

My first experience with ritual was as an altar boy when being a boy was a prerequisite and you had to memorize the responses in Latin. Others may have thought about the ritual aspects; I was mostly concerned with not tripping on my alb.

Ritual, and superstition, was a major component of life in the theater. Learning to say “break a leg” instead of “good luck” as an actor took the stage. Discovering what the “Scottish Play” was. Remembering to leave the ghost light on when you were the last one out at the end of the night.

As a techie, I did these things because that was what you did even if they seemed silly to my fiercely rational side. Fitting in and being part of the company was far more important than pointing out the essential illogic of these rituals.

Despite my fundamental skepticism I found myself drawn to organizations and settings that valued rituals. I started my professional career at Arthur Andersen & Co, part of what was once the Big 8 accounting firms. Gray suits and white shirts were the uniform of most days. Andersen was one of the professional service firms that invested heavily in training. I spent many days at their training center outside of Chicago as both student and faculty.

The activities that happened after classes wrapped up each day gradually chipped away at my skepticism. Andersen’s training facility had previously been a small Catholic college campus. It was far outside of Chicago proper. We were pretty much prisoners during the week but Andersen was shrewd enough to invest in its own liquor license to keep the natives from rioting. Classes were filled with practical lessons. Evenings were devoted to knitting people into the culture.

Smack me over the head enough times and I eventually catch on. Perhaps the “soft side” of organization is worth paying attention to. An MBA and a Ph.D. later and I finally grasp that it’s more effective to look at organizations as socio-technical systems. Which is an ornate way to say that both the people and the machines matter.

At the outset I viewed this through the lens of an anthropologist. Organizational culture and the methods and rituals that bound people together were objects of study. They were aspects of the organizational environment and had come into existence through the passage of time. You could nudge things at the margins if you worked hard enough at change management.

I had an odd lesson on organizational stability and flexibility early in my career. The theater group that occupied all of my free time and a good bit of my class time in college was about 90 years old at the time. Shortly after I graduated I was asked to serve as a trustee of the group. Instead of the four years that most people spent connected, I spent an additional ten. I saw a curious thing about history vs. tradition. For students, whatever had happened during their few years in the club was all of history. Traditions just sort of existed; they were only loosely connected to the longer history in students minds.

That came back into play when I was part of the founding group of a consulting firm. We had no history but came from places where history and tradition was a key element of success. We understood that we were not simply growing a new business, we were laying down the experiences and stories that would become our traditions and our rituals. We could be intentional about what stories we chose to celebrate or to ignore.

One example comes to mind. We spent most of our time on the road at client sites. We had virtually no infrastructure of offices to hang out in between assignments. Fortunately for our economics, we also had little down time between assignments. You worked with your team during the week and you went out with your team after work in whatever city you happened to be in. But you might not meet your colleagues on other teams for months. They would only be an email address or a disembodied voice on a conference call.

We were smart enough to invest in monthly All Hands Meetings where we flew everyone into Chicago for a meeting to talk about the business and our work. While there was always a formal agenda, we were more interested in providing space for conversations between and after the official meeting. And we were always on the look out for stories to share.

But the clever thing that happened was an end of the day ritual that took place after work at client sites. There was an online trivia game available in many sports bars at the time. It had a leader board that showed who doing well and it showed the leaders across all the bars and restaurants playing the game that night. The game allowed six characters for a name. Our project teams would agree on a time to play (adjusting for multiple timezones) and they would choose a team name that was “GEM” (short for Diamond, which was the firm’s name) plus the airport code for the client city. So the team working in Wichita would be GEMICT and the team on Wall Street would be GEMLGA. We had pretty smart people on our teams and the goal was to see how many slots on the leader board would belong to GEMXXX teams. If your team grabbed the top spot for the night, we picked up the bar tab. Small outlay, but important bragging rights for the next All Hands Meeting.

The final observation I would make is that we learned not to force these things. Instead, we looked for ideas from the field that we could amplify. Learning to discern what could be amplified versus what would be rejected took time.

Finding a Guiding Principle

I used a picture of a woodpecker last week and I promised the story that went with it.

Jerry Weinberg was a computer programmer and author who wrote often about the impact of information technology. He was pretty sharp with his observations. One I encountered early in my career building technology was:

If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

This was a plea for programmers to get better at their work but it also planted a question about what makes some systems stable and others not. That’s the kind of open-ended question that can get you in trouble and eventually lead you back to graduate school for a deeper dive into all kinds of systems–technological and organizational.

One of my advisors was a deep thinker about systems. He was also a decidedly non-linear thinker and lecturer. My notes from Jim’s seminars were typically a wild profusion of boxes and arrows attempting to discern his train of thought. The aha! moment would sometimes arrive at 3 in the morning, but it did arrive.

As those aha moments accumulated, I developed some facility at making sense out of complex systems, whether they were constructed out of technology, organizations, or some blend. While I was getting better at figuring systems out, explaining what I was doing or seeing was more difficult. People prefer simple stories. If I couldn’t find simplicity in the systems I was exploring, perhaps I could find some in how I thought about my underlying process. I eventually found an answer in the title of a 1981 essay by Wendell Berry, “Solving for Pattern.” It nicely captures the clarity of the goal and the complexity of the journey.

No one is the villain in their own story

If my mother were still around, I’m sure she would be a Bernie Sanders supporter. At heart, she was a communist. Dad was your classic engineer. Both were from blue collar roots. In that environment, business in general and big business in particular was the enemy.

Against this backdrop, working with technology was acceptable. It was a form of engineering. It was inherently rational. Rational was good. Good was opposed to evil.

Business, on the other hand, was not good. It might even be evil. Big businesses were led by selfish and uncaring people. The system was rigged against the little guy.

This was the environment I swam in. Like a fish blind to the existence of water, I happily built systems anchored in rationality. But I was also building these systems inside business organizations.

When you are a junior member of the team, technical rationality prevails. When organizations reject technology, it is easy to fall back on stories of rigged systems and selfish leaders.

I tried this path.

As I took on more responsibilities and rose within organizations, that story started to fall apart. I didn’t feel as though I was becoming uncaring or evil. And my colleagues seemed to be fairly normal as well. I needed a better story about why the leaders in organizations did what they did.

I recall of conversation with my thesis advisor in the early days of my journey to understand technology and organization. He wanted to know what version of organization I believed in. Were organizations about power and politics? social relationships? technical rationality? economics and strategy?

All of these elements are at play in any organization. In healthy organizations, the play is balanced. The dominance of any one perspective is an indicator of underlying trouble.

The place I arrived at is to  view organizations as complex systems subject to one major constraint. The systems perspective trains to you look for and see how elements interact. The constraint is the idea of bounded rationality. Most of us would prefer to base our decisions and actions in the systematic analysis of facts and data. But there are always boundaries and limits on our ability to discover or do the most rational thing. This perspective is what has evolved into today’s notion of behavioral economics.

When I take these notions into actual organizations populated with real people, I remind myself that no one is the villain in their own story. For all that my mother liked to start her complaints with “that’s crazy,” you’re better served by looking for what makes things look sane for each of the players.

A big story is just a collection of little stories

Above my desk is a wall of pictures. It’s not the “brag wall” of executives or politicians showing off all the famous or important people I’ve met. No, it’s pictures of family and moments going back over thirty years. It’s a practice my wife taught me. We’ve had one in every place we’ve ever owned.

There weren’t very many pictures around the house when I was growing up. There were occasional photo albums but hanging fragile things on walls wasn’t a great idea in a house with lots of boys moving at high speeds.

My professional curiosity centers on how technology changes how organizations function. I started that exploration from the realm of technology. One of the appeals of technology is that it does only and just what you tell it to. Working that out can be tricky but it is ultimately an exercise in rationality.

I came to the exploration of organization with a naive assumption that rationality was enough. I am less naive now but I still want to make sense of organizations. When the complexities seem overwhelming, I can look up at that wall. It reminds me that the complexity is built on the stories behind each picture. The big story is built up from the unfolding of each little story over time. You grasp the big picture by working your way through each individual story.

Tech Rehearsal and Organizational Change

I’ve talked about the interplay between actors and crew during a performance; how everything needs to come together to deliver an experience to the audience. None of that experience is accidental. All of it is designed; the actors’ lines, where they move, sets, costumes, props, lights are all the product of careful thought.

All of these elements first come together during tech rehearsal. Tech rehearsal is when you work out all of the details that the audience won’t be  aware of yet are essential to their experience. As an example, consider just the lighting in a scene. Is it a beautiful morning in Oklahoma? The lights won’t simply be bright; the color balance will be some version of straw or amber. That level and balance gets worked out and adjusted during tech.

In the theater, those environmental elements are designed and controlled. I think this is where I first began to tune into the role of the environment on performance. We tend to think of the organizational environment as a fixed background if we think of it at all.

The theater teaches a different lesson. Any element is potentially mutable. And it is the interaction of multiple elements that contributes to the overall effect. Eventually, this leads you to a systems perspective on performance. Sure the lights need to be bright enough to see the performers, but what color balance do you want to set the tone?

One of the particular challenges in organizational settings is that we lack the theater’s appreciation for the complexity of how elements interact. Or for the time it takes to understand and adapt to a new arrangement of elements. Instead, we are likely to turn down the lights or move the sets in the middle of a live performance and wonder why the actors are angry and the audience has left.

Don’t Walk: Applying the Rules in a Volatile Environment

On days that I teach, I take the train into Chicago and then walk from Ogilvie Station up to the Loyola Watertower campus. Generally takes me about 30 minutes. Yesterday, as I was mulling over what to write here, I came to an intersection. The “Don’t Walk” sign was lit and several other pedestrians were waiting patiently. I looked both ways, saw that there was no oncoming traffic, and continued on my way.

It always strikes me as odd that Chicago pedestrians simply comply with the traffic signals and don’t adjust their behavior to the actual environment in the moment. I used to think it was simply because I learned to be an urban pedestrian in New York City, where getting from train station to office on foot was a blood sport.

I don’t think I can be accused of being a scofflaw; someone who is merely rebellious by nature. If anything, as an eldest child, I am a rule follower. Courtesy of my parents and a string of enlightened teachers, however, I also learned that rules are elements of larger systems. In good systems, there is a deeper logic; rules exist to advance the goals of the system.

One choice is to simply comply with the rules and assume that the goals of the system remain relevant and the design of the system matches the realities of its environment. In stable and slow-changing environments, that is a reasonable strategy. Waiting for the traffic signals to change doesn’t hurt, although it might slow the world down a little bit.

There is another choice, which is to look at the design logic driving whatever system you are engaged with. This is the dangerous path you set people on when you start teaching them how to program. Programs are the explicit rules for realizing the design goals of a bigger system.

The differences between a working computer program and a working organization are differences of degree not of kind. As you learn to see how rules, information, structure, and goals interact, you learn to see the commonality that unites systems across disparate environments. It can take time to work out the value and the limits of the analogies, but it gives you a path.

Things are the way they are because they got that way

I remember my parents as being light drinkers. One beer at a Saturday barbecue would be typical. I never thought too much about it, even as my peers began their introductions to alcohol.

Extended families became a larger element of my environment when we moved to St.Louis, where my mother’s siblings and their children all lived. Dad’s family was back East and weren’t part of my life. While it was never a specific topic of discussion, I eventually pieced together that my father’s move west was a very deliberate act. His two older brothers and his twin brother were all essentially functional alcoholics. Leaving that environment was his plan to avoid the same fate.

I think this must be one of the seeds of my sensitivity to context and the environment. The environment–social, organizational, physical–sets boundaries on what is easy and what is hard. And history shapes the environment.

Technology pretends to be ahistorical. We are here now and the future looks bright. There is nothing to be gained by wondering how we got here; press on.

Organizations are all about history. Jerry Weinberg was fond of reducing his insights into aphorisms or laws. There’s one he attributes to economist Ken Boulding;

Things are the way they are because they got that way

Understanding how things “got that way” is a necessary step to making things better. And that is true for organizations, technology, and their intersection.

[There’s a reason for the woodpecker but that is for another day]