The SLOW Executive

I wandered in to the UC Press bookstore on Bancroft Avenue in Berkeley yesterday and came across a new book entitled “The SLOW Professor” by Berg & Seeber. After riffling through it, I didn’t buy it … the book that is.  However, I did (and do) find much to agree with in the concept.

In the “IT” world we are hearing a lot these days about the wonders of DevOps as a way to get things done really, really fast; as a way to get something done in 3 days instead of 3 weeks … or in 3 weeks instead of 3 months.  I’ve listened to DevOps gurus and come away with a sort of Yogi Berra “Deja Vu all over again” feeling.

Of course we should have a highly collaborative working relationship between the IT Development organization and the IT Operations organization – but what’s new about that? Silo-fication was diagnosed as a terminal disease  fifty years ago – with today’s DevOps being a new name for an old cure, namely “desilofication” – the process by which you get people to work effectively together across functional boundaries.

The word “process” in the previous sentence bothers me a bit since I think some IT executives have overdosed on it.  Too much “process” is every bit as bad (and maybe even worse) than not enough process. Jack Welch was right with his emphasis on keeping things SIMPLE.

Maybe the challenge many of us are facing is one of keeping our processes and our organizational structures appropriate to our needs which, of course, are constantly changing. This gets me back to the point found within “The SLOW Professor” which is that  sometimes – and particularly within the hallowed halls of Acadamia – speed is not a good idea; that slowing down and thinking something through with some care might just be much better. I tend to agree.

At the same time as our IT gurus are advocating DevOps as a way to get things done really, really fast, they are decrying what they see as the increasing pace of change.

One might make a good case for suggesting that these gurus on wrong on both points.

First, DevOps is really not all that new. I encountered the concepts and structures now described as “DevOps” fifty or so years ago. Our challenge today is one of removing the burdensome incrustation of levels of process and levels of structure that have accumulated while we weren’t watching.

Second,  I make bold to suggest that all this stuff about “pace” is a bunch of hooey; that the pace of invention today is about what it was 150 years ago.

Consider a person born in 1877. That person saw in his or her first 26 years, the invention of:

  • 1877 – the phonograph
  • 1880 -the commercial incandescent light bulb
  • 1882 – the power plant for generating electricity
  • 1886 – the automobile
  • 1889 – Movies
  • 1903 – the airplane

By the time that person was 45 years old in 1922, all of these things had become common – but in a vastly changed world. Technology in the form of Computers has been an increasing part of our lives since the first computer-based payroll system (at, appropriately, GE’s incandescent light bulb facility) in 1954, sixty-two years ago.

Thus, we might ask ourselves, “Is today’s pace really all that difference in size and speed from that encountered by that person born in 1877?

The answer comes in three flavors:

  • Pace of invention
  • Pace of adoption has significantly accelerated
  • Pace of impact

I will end this by suggesting that “impact” is the central issue and I will close with a quote from 1966 by Willis Ware:

The computer will touch men everywhere and in every way, almost on a minute-to-minute basis … Every man will communicate through a computer, whatever he does. It will change and reshape his life, modify his career, and force him to accept a life of continuous change.

and – I emphasize – that was said in 1966!