Milo Medin [VP Wireless Services, Google]: Impact is the big thing everyone wants from their life. And that’s true for software professionals as well. If you can give someone the opportunity to actually have meaningful impact, they may stay a long time. People work in the open source community, put an enormous amount of energy and work, and they do it because of impact. Not because it’s the most lucrative way of monetizing their skill set.
That was from a YouTube conversation hosted by DAU called “Changing Software Acquisition in DOD — Roundtable with the Defense Innovation Board.” One of the most important aspects to a feeling of meaningful impact is the feeling that one is genuinely contributing expertise and creativity.
Often, DOD programs are outlined by numerous layers of bureaucracy that partial or no responsibility for getting the program accomplished. The program offices and the contractors are expected to “do” what has already been “planned” with little deviation. Execution to plan, on time and on cost, is considered the mark of success. It leaves little room for the ones who are “doing” to discover what really works, and how they can truly contribute to solving difficult and important problems.
It was noted by several contractors in the 1940s and 1950s that it was difficult for them to hire the best talent from the government, despite offering much higher pay, because they couldn’t offer the same job satisfaction — that their employees couldn’t make important decisions as to how the program is executed. Much of that satisfaction was in fact removed by Robert McNamara’s policies associated with centralization and the PPBS.
Here is some additional discussion from the DAU conversation about the importance of delegating decisions to the lower levels, and how the specification planned by the consensus-building bureaucracy shouldn’t be sacrosanct:
Jeff Boleng [USD(A&S) Special Assistant for Software]: We should never have a spec that is detailed enough that it’d take 5 years to go execute.
Richard Murray [Professor, CalTech]: We want to think of a spec as “this is a goal for where we are going.” But, you know, 100 percent compliance with that spec is not the goal. The goal is to get functionality out in the field that is useful. And maybe we can get part of that working, and then do the next piece, and the next piece. By the way, that will then change what we think of as possible.
Jennifer Pahlka [Code for America]: One thing we don’t talk about enough is that making a judgment call like that requires risk-taking, and we’ve got to back people to make judgment calls. There’s a very good reason people are risk adverse. They decide not to keep the legacy requirement, and everyone’s all over them. We have to make choices. And we need a culture that says, “OK, I could call you out for this because its not what’s technically on paper, but we can see that you’ve used your judgment, made a choice, and now we’re moving forward.”
Milo Medin: I’d just pile onto that by saying we have to be willing to kill things. One of the great opportunities by having an early set of deliverables is, is this team actually capable of delivering? If not, put a bullet through it and restart. We do this all the time. I cannot tell you how many failed projects we have a Google… and we’ve tried a new approach. That’s OK. And is has to be OK. And if its not OK, then you’re going to end up sticking with things for way too long and end up with ineffective systems.
That willingness to make incremental decisions, kill non-performing projects and start new ones, is simply impossible in today’s acquisition process, regardless of rapid acquisition authorities. Ultimately, one has to look at how funding is made available to these projects, which is the key roadblock. After all, money is what makes the world go around (quipped General Joseph McNarney, the head of the budget advisory committee for the first SecDef, James Forrestal).
Leave a Reply