/kevinbehr/home

Have you ever read “The Mythical Man-Month: Essays on Software Engineering“?

If so you are a rare bird (or over 45) in today’s tech zoo.

I wish I could drop this book (among many others such as The Goal, Critical Chain, The Machine that Changed the World, Great Boss Dead Boss, and Chasing the Rabbit  - see the right side column to buy them!) out of airplanes and organize study groups with my IT; operations, security, audit, project management, executive management and yes especially development brethren.

I was reflecting on this text and several other seminal management books I have collected over the years and I decided I needed to write a series for my blog on this topic. As of late Gene Kim and I are working on some amazing projects for fun and exciting internet 2.0 companies. We have been writing a new IT management novel with George Spafford (think “The Goal” for IT) , and helping a bunch of IT shops solve the quality, reliability and cost reduction realities that have now become must-do (all at the same time mind you).

Just yesterday we began working with long time collaborator and joyful subversive, Eileen Forrester, from the Software Engineering Institute at Carnegie Mellon University.

We are shaping up a few writing projects for the newly released CMMI-Service model.  Eileen has been in charge of getting the new model released on time and has actually over-performed and it is out much earlier than expected for the first time in history.

I relish the opportunity to exchange ideas and approaches for improving the delivery of services with folks from all sectors of the economy (especially those disciplines outside of the IT world).

Many of these industries and business disciplines have a long history of systems design and improvement that reads like rich history.

Where is this similar lineage taught and practiced for IT today?

As I work with many IT executives and teams around the globe I often find myself wondering if the collective “we” has forgotten more than we have learned up to this point.

For a community that not only leans towards scientific interest our entire profession exists on the shoulders of science (knowledge and technology are the output) so little of the way we actually do IT is built on the scientific method or around what I have dubbed the “System Building and Continuous Improving Arts” (SBCIA).  We often are just reacting rather than treating every request as a hypothesis and making sure we have built a repeatable response that correctly satisfies all of the implicit assumptions in the request.

To better explain what I am talking about I will use the Japanese term RYU, which denotes the flow of water.  The idea represents formal Japanese traditions such as the Martial Arts.  In Karate fluidity and finding one’s path are compared.  Water will find its own path in balance with the terrain it is surrounded by, just as the Karate student must advance through his or her path by practice and training.

Bringing me to the point of my concern in this post…

Much of “the path” for IT practitioners and managers of all levels travels through the acquisition and appropriation of myopic technical domain knowledge (yes even auditors). In other words “what we must know” so “we” know how to react in a given technical situation”.

What is missing?  What we need to understand holistically (see) to decide how we should work together as a system .  This information is both timeless and too time consuming to amass through trial and error in our own life experience. The old adage applies here “Time may be the best teacher but it kills all of its pupils”. In order to amass the collective wisdom about how to see the work in order to build an effective system to do the work, we need the collective wisdom of our predecessors and our current community at large. We also need to look outside of our industry and find analogs to improve our execution, quality and safety with larger and scientifically validated levers. Stop chasing consensus based “Best Practices” and start purpose-building systems around scientifically proven practices.

There is much room in IT to build a new flow of knowledge about the “System Building and Continuous Improving Arts” (SBCIA).  This economy is shaping up to be the ultimate Dojo for us to do so.  Let’s just say performance is no longer optional but survival is.

So pick up a copy of “The Mythical Man-Month: Essays on Software Engineering” and start a study group and learn from your ancestors.  Create a culture of Kung-Fu, a Chinese term that means “individual accomplishment or skill cultivated through long and hard work” .  Set the tone with your team and define skill from a systemic and improvement standpoint rather than merely a technical one.

Check out the books in the far right column on this blog to find a handy DOJO compendium to get you started on this journey.  If you are serious about improving IT flow, reaping the drastic cost savings, increases in project execution and infrastructure reliability that result, feel free to contact me about mentoring and staff coaching.  It really does make a huge difference!

If you have stumbled upon a nugget on your journey please let me know I am @kevinbehr on Twitter - join the conversation!

*Put down the Blackberry. Step away from the Blackberry please.”

When I read this article about Obama’s Blackberry use, I rolled my eyes at some of the intellectual stretches it was taking. While I agree with the premise and I do certainly understand the Blackberry-jones (nervous separation anxiety and the compulsion to thumb it when the little red light blinks) premise, I was far more interested in the work that Gloria Mark was engaged in.

“When Gloria Mark, professor of informatics at the University of California, Irvine, shadowed employees at two high-tech firms, she found that the average worker spends only 11 minutes on any given project before being interrupted and asked to do something else. IT workers have it worse, switching attention every three minutes, on average.”  - Newsweek Magazine, 2/16/09

Over the last ten years, Gene Kim and I have been inside of and benchmarked hundreds of IT organizations, conducted numerous research studies and written a LOT about this very topic of unplanned work. We have come to believe that, largely, IT management as a whole has not built an effective system for “Doing IT.”  This study from the University of California dovetails with some of our findings from benchmarking nearly 1000 IT organizations.

Namely, the first finding that Unplanned Work, which by definition is the IT equivalent of task assignment by drive-by-shooting (fire-fighting outages, urgent security patching or compliance related work, essentially anything that takes a worker off of the planned task list of things that are important) is virtually non-existent in high performing shops compared to everyone else.  This is evident both by the low amount of it (expressed as a percentage of labor opex often as low as five to ten percent, compared to the rest at twenty to fifty percent of labor opex lost to heat) and by the advantage high performers have over everyone else in project execution. High performers get up to 8X the projects done, 14-16x times the infrastructure changes with one-half the change failure rate.  Also, their mean time to repair an outage is as low as 1/10 the time of low performers!  All of this creates higher availability and the ability to execute more projects in a more controlled manor with less negative business impact.

Oh yeah, did I mention that they do this with as little as 1/4 of the system administrator staff when compared to low performers?

By building an effective execution flow system it is not only possible, it is probable that you will outperform your competitors and actually help your company meet its goals.

Over the last ten years Gene and I have learned:

1.       Constant fire-fighting  and uncontrolled change weakens infrastructure and creates security problems,

2.       The hero culture that ensues accelerates the rate of outage entropy because little information and visibility in to the known good state exists for others to draw on,

3.       Your best and most talented people are stuck on the fire-fighting line instead of solving business problems,

4.       Your ability to demonstrate proof of compliance diminishes with the more outages you have,

5.       More fire-fighting = less project and planned work = less credibility with business peers = shadow IT = failure,

6.       This can all be fixed by building a system based on Flow and controls.  No, I am not speaking of a never-ending-death-march of process analysts and skies darkened by consultants. I am talking about building a deliberate discovery based system that illuminates what is actually happening versus obscuring it. This type of system learns from every mistake and seldom repeats the mistakes made in the past.

Sound interesting?  If this is the direction your organization wants to move - Dramatically Lower Cost structures, Drastically Increased Project Delivery capability, and Rock Solid Reliability, then contact me here and let’s talk about how we can help!

We are currently doing just this for some of the most advanced and largest IT operations in existence today.

You can download the PDF of the article here.  This is a great overview of Visible Ops for execs.  If you want to talk to your boss about adopting Visible Ops, ITIL or just some of the concepts in the book. This document is nice and portable and has pretty colors (hint: execs love color).

If you are interested in improving your IT organization’s ability to focus on and complete planned work, such as projects and proactive info sec work, feel free to contact me here to find out about the workshops, benchmarking and briefings I do to help get folks started!