[NB: I wrote the original version in about 1995 while still at NSA, but I don’t think I ever published it. I believe the lessons still apply]
Subtlety is a one deep-process. Say what?
A "one-deep process" typically refers to a process that involves only one layer or step, rather than a multi-step procedure. This can be applied to various fields, including computer programming, and psychology, and general problem-solving.
I say this every once in a while at work, usually during some deep and painful leadership team discussion, and often concerning some issue of change management or strategy. At NSA, we have lots of very smart people, very tough mission problems to solve, and an organizational culture that values discussion and complexity. We also suffer from an “angels on the head of a pin” culture, where we love to endlessly debate the esoteric.
So I've been in countless settings where, after very long and tedious debate, we reach some grand conclusion. And then we find that we’re unable to successfully share this conclusion with anybody else, especially our own workforce and our own customers. Takes too much time, it’s too complex, “you had to be there”.
Hmmm. What's going on here? Well, subtlety is a one-deep process. That is, two rational people talking (a “one-deep”conversation) can usually reach agreement on complex and tough issues. But, when you try to convey this to anyone else, or any group of people, it's almost impossible to convey the context and the many variables required to get the point across.
The lesson for me is that the original conclusion was too complex, too nuanced. That might be true in a technical sense, but it’s not helpful. Sorry, I'm a simple-minded guy.
Especially in matters that must scale, like business strategy or customer relationships or change management, I think we need to keep things simple.
During the Business Process Reengineering boom of the mid-90's, much of the Information Assurance Directorate discussion was about how we were moving to become a “Services” organization, versus our history of product development. “Hmmm, we're a Services organization – we'd better come up with a list of our services.”
And so a team surveyed every Division in IAD, and generated a list of (I think I recall) 150 “services”, which they proudly whittled down to 100 or so. I think someone even made a nice tri-fold brochure. And of course, we could (and did) talk endlessly among ourselves (a “one-deep” discussion) about the subtle differences between “evaluation” and “assessment” and “profiling” and “testing”, etc.
I don't think this list ever left the building, thank goodness. Can you imagine the poor, shocked Customer who would have been subjected to the horror of picking from such a fine-print, massive list filled with terms that only we know, with deep and subtle differences between esoteric topics? That's why folks like me work for the government - such a goofy business approach would drive any company to bankruptcy.
For example, right now in the IA Directorate we're trying to define and execute a significant strategic business shift. And we're going through those endless, painful hours of debate that inevitably are a part of this process. But at the end of the day, we have to convey this to a large, smart, and sometimes skeptical workforce, and to an even larger and more skeptical customer and partner base. And despite the incredibly complex challenges and risks involved, if we can't describe this essence in a paragraph to a page, there's no hope of success.
My advice? I've spent much of my career trying to simplify the problem, the discussion, and the message. Don't fall for the cultural trap. The issues might legitimately be complex, but there are probably only a couple of variables that really matter. Smart and dedicated people arguing endlessly and reaching complex and subtle conclusions might be part of the journey and might make for good entertainment (I am easily amused, of course), but it doesn't make for good business or good communications strategy.