There's a scene from the movie "Fletch' when Chevy Chase is posing as an aircraft engine mechanic and is being grilled about why he'd need ball bearings. His reply: "Come on guys, it's all ball bearings these days!"
\No, I'm not going to talk about ball bearings or even Fetzer valves (inside joke for the Fletch fans out there).
To paraphrase, "Come on guys! It's all patterns these days!"
But before I do, a bit of history. First, the earth cooled. Then dinosaurs roamed the planet.
Too far back? OK. We'll just set the wayback machine to 1977.
An architect by the name of Christopher Alexander published a book titled "A Pattern Language: Towns, Buildings, Construction". Although reports vary on the influence it had on the Architecture industry, it is commonly cited as the inspiration design patterns in software architecture, interaction design and many other fields.
So what was the big deal? He introduced the concept of a Pattern Language. Pattern languages gave a structure to identifying common problems along with their best practices solution(s) in specific disciplines. This allowed valuable information about common problems and solutions to be communicated much more rapidly and reliably than ever before.
As a software architecture-ish kinda guy, I cut my teeth on the Gang of Four's Design Patterns book. Then as I started looking around at other disciplines I realized that they had their own pattern languages, and if I took the time to understand them I'd have a much better understanding of the problems and problem solving approaches to these other disciplines - think of it as an abstract version of the Rosetta stone
Imagine my delight when I discovered that there were organizational patterns - a pattern language devoted to problem solving challenges in organizational structures, something we have to do from time to time in this business.
Odds are good that you're very familiar with at least one of these, even if you don't know it as an organizational pattern. Ever hear anyone say "We're running a skunk works team"?
Yep. It's an organizational pattern.
During a recent Agile Roots 2014 planning session I was talking with Lory Maddox (RN extraordinaire and mother of Ruby guru and Clean Coder evangelist Pat Maddox) about her current job, which is taking new patient interaction innovations and operationalizing them to work within the highly regulated environment of clinical medicine.
As she was telling a story about how her team averted a logistic nightmare by stopping the release of a new communication solution that had not been adapted by her team for deployment into the highly regulated clinical medicine environment, I realized that her team (whether they realized it or not) were implementing an organization design pattern I like to call "Operationalizing".
Operationalizing: A team with deep experience in a specific (usually highly regulated) environment that has the skills and the responsibility for adapting new solutions (software, process, etc) in such a way that the new solution can be deployed successfully within the target environment.
Note: I have not found definitive literature on the name of this pattern, so I get to call it what I like for now. Comment if you can point me to something authoritative.
I know what you're thinking. No, we haven't gotten to the actual point yet. We're close, I promise! Don't get me wrong, the concept is very interesting, but it isn't the one I wanted to talk about. So why did I even take the time to mention it?
Well, because thinking about how the Operationalizing pattern would play out was the trigger for putting my finger on how I've failed to properly apply the Liaison pattern.
Let's go back to the SkunkWorks pattern for a moment (quietly, we don't want Lockheed suing us).
The SkunkWorks pattern is a very common organizational approach these days to attempt to solve the problem of innovation. Look at any large company you'd care to point to. Odds are very high that they have at least one SkunkWorks team running, maybe more. My former employer Walmart was no exception.
When I was with Walmart this was the organizational pattern that we used to restructure the Mobile Applications group. Or was it?
On the surface, yes. But we broke a few key rules of the SkunkWorks pattern - we did not completely segregate the team from the rest of the organization, nor did we completely decouple our infrastructure from the larger organization. Although I'm of the opinion that we could have done more to segregate the team the same was not true regarding the infrastructure. Because we were building live mobile apps that customers were using to buy real things from Walmart, we didn't have a lot of choices regarding our production infrastructure.
And this is where the Liaison pattern comes into the story. If you were paying attention a few paragraphs back you'll see that I actually used the dreaded "F" word in reference to myself.
One of the first external teams I met with was the InfoSec group - this was the team responsible for insuring that all production code met industry and company security standards. As you'd expect with any large organization, the InfoSec team was a single siloed team that evaluated and validated the output of several teams including our Mobile Applications group.
Here's the sad part. In my first meeting with them I explained how we were departing from the previous practice of months-long release cycles to a much faster cycle. When they indicated that their process didn't allow for that fast of a cycle I told them about the Liaison pattern and how it could be used to great success. After confirming that they all liked the idea I assured failure by making the foolish assumption that they'd actually do something about it.
What I should have done in that situation was to put "find a way to get InfoSec to give us a liaison" at the top of my priority list.
Back to the Liaison pattern. Never heard of it? You'll have to be a student of military organizational logistics to have come across the same definition that I have. In military circles, a Liaison is a person (or persons) that are a member of one group within a military organization but are assigned to be part of another group for the express purpose of helping that group to effectively interact with their "home" group. The pattern is most often implemented in situations where the "other" group operates at a much faster pace than the other group (e.g. Special Operations teams conducing operations in the same areas as conventional forces).
Examples: Forward Air Controller, Liaison Officer
Had I made it a priority to work with InfoSec to have a member of their team assigned to ours it probably would not have made much of a difference in the early days of that engagement, namely because we were successful at pushing back on their process thanks to Executive Sponsorship (yet another organizational pattern). Where it would have made a huge difference was when that same executive sponsorship shifted and we were no longer able to keep InfoSec from slowing down our cycle time.
By the way, that whole slowdown thing? That's an organizational pattern too - Organizational Antibodies. I'll be talking about that one in a future posting.
The moral of the story - Organizational Patterns! Learn them, learn to use them if you care about being effective. Most importantly, learn how not using them will have a negative impact on your team(s).
No comments:
Post a Comment