Loose cultures, tight cultures, and the USD(AT&L) break up

Loose cultures have a great benefit in terms of creating ideas but they’re not necessarily great at implementing them. So you think of innovation, it involves two different things that relate to tight-loose. One is creativity–the one that’s really helpful when you have whose norms. But the other is: tightness helps you to actually scale up and implement. And those two factors are what I say we need to be ambidextrous about. I call it tight-loose ambidexterity–that leaders in companies need to actually have the kind of vocabulary of both tight and loose and help to deploy them as needed.

 

And tight cultures tend to have people who are more careful and more risk avoidant. And they have more standardization and efficiency and hierarchy to help coordinate; and they have leaders who are calling the shots. And loose companies have different people, practices, and leaders. They have people who are more open and more impulsive and risk-taking. They have more flexibility, discretion, and dogs walking around in some cases and ping pong; and they have charismatic and visionary leaders who are driving the ships.

That was from an EconTalk episode with Michele Gelfand, “Rule Makers, Rule Breakers.” The discussion reminded me of the USD(AT&L) split-up, where it was presumed there would be a “looser” and innovative culture in USD(Research & Engineering) and a “tighter” and more cost conscious culture in USD(Acquisition & Sustainment). However, many observers noted how such a split would only widen the “valley of death” in transitioning new technologies from the labs in USD(R&E) to the program offices in USD(A&S).

Gelfand’s insight into ambidexterity is important. You don’t want a culture moving too far towards looseness or tightness. It seems like another way of speaking about ambidexterity in technology exploration vs. exploitation. Loose cultures allow for exploration. Tight cultures permit exploitation.

It seems that successful companies are not those where you have a serial founder who creates something new and then sells it to the “adults” for scaling. In ambidextrous companies like Google the founder stayed on and transitioned with the company. Sure, “adults” like Eric Schmidt came in for Google, but they did not supplant the founders. Here is Jerry Yang, one of the founders of Yahoo, speaking about the time when CEO Tim Koogle came on-board:

… he didn’t come in with any preconceived notions. He guided and steered us rather than pushed us… it never felt like we were being supervised. We were part of a team.

At any rate, USD(A&S) controls programs from Milestone A/B onward, which is before full-scale development. USD(A&S) must be innovative. It is a mistake to signal that USD(A&S) needs to be a tight culture, just like USD(R&E) must be super loose because it needs discipline in making new technologies relevant to defense needs and maturing them.

Moreover, the rise of DevOps means that there isn’t this nice break between development and operations — there is a continuous nonlinear interaction. Perhaps the fact that USD(A&S) control basically the entire system, including most of the RDT&E budget, one can claim that DevOps is the realm of USD(A&S). That would leave USD(R&E) squarely in the science & technology area, without a role for creating operationally-bound prototypes. But I don’t think that’s anyone’s intent. Remember how DARPA was largely responsible for scaling the Predator drone.

And so I’m not sure what to think about the USD(AT&L) split. Generally, I would have preferred USD(R&E) to have control over almost all of the RDT&E budget including milestones. But that might be counterproductive from a DevOps view. Perhaps another way of thinking about it is that the linear Milestone process — as well as budget appropriations by RDT&E, Procurement, Operations & Maintenance — are out-dated.

I’ll throw out an idea. Provide funding directly to tech labs, systems commands, and combatant commands organically. These are equivalent to incubators, venture capital, and mature firms. Funding then gets allocated by chiefs to individuals rather than programs. And as the individual/team’s concept becomes promising, they transition from a lab to a new program office with “adult” support from the systems command. Program offices then need to find “buyers” from the Combatant commands — it isn’t preordained — and so they partner in DevOps. Successful programs might then transition to the Combatant command — or perhaps if the portfolio at the system command evolves to an operational extent the whole command becomes a combatant command — something like CyberCOM.

Here’s a bit more from Michele Gelfand, perhaps pointing to the acknowledgement for mission command:

I’m doing some work for the Navy where they need to run a tight ship… But they also recognize that maybe this has been counterproductive. Maybe making people wear certain types of socks and having certain types of haircuts is maybe not really productive to allowing those creative juices to flow. That, the idea was that traditionally that if they learn to follow those rules, they’ll follow the more important rules on the battlefield. But now there’s a lot of questions on that. And, how do you get leaders to run that tight ship but insert some discretion in non-safety domains?