Wednesday, November 14, 2018

Galambos on Innovation, Systems of Systems, and Logistics

Here is Jim Galambos on Voices from DARPA, talking about platform design and cost disease:
What do we mean by system of systems? It's really this idea that as our defense has matured over the last few decades and we make more and more capable platforms--and a good example of this would be, say, an airplane or a submarine--these are becoming very sophisticated platforms, very capable, but they're also expensive. They also take long time to make and what we're finding is, to make them even better costs a lot of money and time and you don't necessarily get that much more capability than you had. If you will its kind of creating an asymptote, as you put more effort into it its getting incrementally better.
This problem has been recognized for a while now. The 1972 COPG Report provided an illustration of what, over the prior decade, had been referred to as the "technological plateau." It finds that the marginal benefit of R&D investment decreases in a specific technical approach. It implies that disruptive innovations, new ways of doing things, are the only source of long-run progress.
Reproduced figure from the 1972 Commission on Government Procurement (COGP) Report, depicting the leveling-off of performance gains as more dollars are expended on a specific technology. The figure suggests the importance of discovering new technologies, the only source of progress in the long-run.
DARPA's program manager Galambos recommends dis-aggregating functions from major platforms as one way of decreasing cost while increasing performance. However, if you take, for example, sensors off of a platform, they need to operate and communicate reliably. Then you have more signals that must be processed. Here's Galambos:
So we talk a lot about, hey, how can we have machine learning and [artificial] intelligence help pull this stuff together and interestingly what we almost always end up with is logistics, because one of the issues is, now I've got more things spread apart, how do I get them there and how do I sustain them.
The body works well, the eyes come with the head, its a nice package. Now I've got these two extra eyeballs out there. Whose going to hold on to those and keep them cared for, fed, etc.
So if you can have multiple sensors located in different areas, you can "see" more, it's harder for the enemy to countermeasure, and the system's performance degrades "gracefully" when a sensor is taken out because you can employ them redundantly. 

But the downside is logistics, and in war, the logistics associated with physical and informational goods is precarious. For example, Russia is building a drone-jamming force. Maybe the dis-aggregation concept, for now, works better in a counter-insurgency context than near-peer warfare.

Different environments create unique forces toward centralization and decentralization. It reminds me of how slime molds can exist as independent cells when times are good, but they work together under stress. As Steven Johnson writes in Emergence:
When the environment is less hospitable, the slime mold acts as a single organism; when the weather turns cooler and the mold enjoys a large food supply, “it” becomes a “they.” The slime mold oscillates between being a single creature and a swarm.
In the market economy, I like to think of the price mechanism as a system that intermediates information on a decentralized basis. It provides feedback about whether it is efficient to pursue more centralized coordination (increasing the scale of firms), or whether it is efficient to pursue more decentralized coordination (more contracting, start-ups, etc.). Prices also discipline firms, which determines whether they decentralize themselves such as found in subsidiaries, or 20% time at Google, or the 2-pizza rule at Amazon.

How can a military system of systems overcome the logistics problem in a sufficiently far-from-equilibrium environment? How does the system flex between decentralized and centralized structures? Galambos recognizes the challenges but also the payoffs of success.
This is why we're doing this at DARPA. It's not 100 percent certain that this is the way to fight in the future. It's our hypothesis, and there's a lot of evidence to suggest that if you can do it it's a great way, but that's a big if and that's why we're doing the research...
For slime molds and in nature more generally, it appears that environmental perturbations and feedback loops create coordination whose processing power is decentralized. This form of coordination might then beat out competitors in the evolutionary filter. It does not take a centralized processing system with fail-proof communication.

Here's Steven Johnson again on the aggregation and dis-aggregation of slime molds:
Cells would being following trains created by other cells, creating a positive feedback loop that encouraged more cells to join the cluster...
If each solo cell was simply releasing cyclic AMP based on its own local assessment of the general conditions, Keller and Segel argued in a paper published in 1969, then the larger slime mold community might well be able to aggregate based on global changes in the environment – all without a pacemaker cell calling the shots. [Emphasis added.]
Slime molds, such as Trichia varia shown here, can aggregate and dis-aggregate according to the environment, but each cell does so according to local conditions and positive feedback loops. It doesn't require centralized command such as a "founder" or "pacemaker" cell, which requires logistics and communication.
"The response was very interesting,” Keller says now. “For anyone who understood applied mathematics, or had any experience in fluid dynamics, this was old hat to them. But to biologists, it didn’t make any sense. I would give seminars to biologists, and they’d say, ‘So? Where’s the founder cell? Where’s the pacemaker?’ It didn’t provide any satisfaction to them whatsoever.” Indeed, the pacemaker hypothesis would continue as the reigning model for another decade, until a series of experiments convincingly proved that the slime mold cells were organizing from below. “It amazes me how difficult it is for people to think in terms of collective phenomenon,” Keller says today.
That's as far as I'm willing to speculate on systems of systems. Here is Galambos on his early days experimenting at Los Alamos:
It was the first time that I was in a laboratory and we were trying to do something that we did not know how it was going to turn out. Previous to that, in classrooms and laboratories or science fairs in high school, you were usually just trying to make something work that you knew the answer to but it was just could you make it happen. And it was at Los Alamos where I finally saw, we were doing experiments and I realize these really bright people, they hoped they would know what was happening, but the reality was we we did experiments to find out. That was very exciting to me.
More defense policy needs to be based on the idea that, even in engineering development, smart people cannot predict exactly what will happen. As Michael Polanyi argues, if we demand of an idea that it be completely articulated before it be given the appellation “knowledge,” then we will find we know nothing at all.

This was interesting too:
We were looking at was can I create an undersea shock-wave, which means basically light off an explosive under water, but do it in a way that we could shape those shock-waves to all pile up on top of each other and smash something like a mine. So we were actually looking at mine clearance doing that. 
Because the concept deals in fluid dynamics, outcomes depends on the unpredictable nature of turbulence and can only be arrived at experimentally. Good luck having tried to calculate that design before experimental data.

Tuesday, November 13, 2018

Fighter Mafia emphasizes simplicity of design

Pierre Sprey testifying to Congress in December 1971:
… it is possible to increase complexities of a weapons system to a point where it is very easily counter-measured. I can’t go into the details here because the rest of the subject matter is classified, but there are a number of examples of that.
Pierre Sprey designed the first paper lightweight fighter, the FXX, in 1968 when at the Pentagon under the Assistant Secretary for Systems Analysis in OSD (OSA). It evolved into the F-16 and F-18.

In 1971--before those planes ever flew--Mr. Gloeckler and Mr. Spangenberg in the Navy openly criticized Sprey for "many fallacious assumptions, half truths, distortions, and erroneous extrapolations."

See page 268 of “Weapon Systems Acquisition Process” Hearings Before the Committee on Armed Services United States Senate, Ninety-Second Congress, First Session, December 3-9, 1971.

Broad Considerations for Entering the Defense Market

A few days ago I discussed the saga of the JEDI cloud computing contract, which engaged tech firms like Amazon, Oracle, Microsoft, IBM, and Google. One has dropped out and two others have filed a protest before the contract was even awarded.

But news stories don't really give you an idea for what its like working for the DOD. I'll give some considerations for firms looking to enter to defense market.

(1) First thing you want to consider is being a subcontractor. This allows you to avoid most of the regulatory burden of dealing directly with the Government. Prime contractors are similar to the Big Pharma in this way, they specialize in compliance.

The way the DOD pays profits, it incentivizes the firms to outsource.

The most important step is strategically hiring former employees at big primes or in the DOD. They can get you a foot-in-the-door. But this courtship can take some time, especially if it's for a new platform or concept.

How about dealing with the Government itself? Strategic hiring is again the first step, let them guide you. But what else?

(2) Avoid the large platforms. Much of the budget goes to Cold War era platforms like carriers or aircraft. Bureaucrats and military men are risk-averse. They want demonstrable proof that your firm has the capabilities to participate before you get a contract. This isn't just as a lead-systems integrator, but for subsystems and critical components as well.

SpaceX is an interesting story where a billionaire wanted to break into the space launch industry characterized by monopoly. A 2006 merger of launch capabilities from Boeing and Lockheed Martin created ULA, the single remaining U.S. launch supplier. Though ULA had high launch costs, never once has it lost a payload.

SpaceX has had two fatal accidents, mostly recently losing a classified payload likely worth billions. SpaceX may be weathering the storm because of public faith in Elon Musk.

Remember, bureaucrats do not stand to gain much from any value gained through new technologies or lower costs. But they will lose much if they let a contract without checking all the boxes, or if they accept a deficient delivery. This makes bureaucrats risk-averse by nature, even though they really want to do the right thing.

(3) You want to start in emerging technologies or low-end products that defense contractors haven't captured. Cloud computing is one. Artificial intelligence, machine learning, robotics, and cyber are others. Many types of sensors as well. 

General Atomics made UAVs work in the early 90s riding along with DARPA. Establishing a reputation with DARPA or service research labs is perhaps the best way to start out. Transitioning that work into the project offices will be hard.

Small-scale projects can fly under the bureaucratic radar, and use Other Transactions Authority to bypass burdensome regulations in the FAR/DFARS.

Even if you find a customer willing to take a risk on you, they will need to line up funds from Congress. Getting a budget line-item in the President's Budget basically assures you that a customer will have big dollars for decades to come. But this is unlikely for you, plus it will force you into scaling problems discussed later.

Just because OTAs are the flavor of the week in the DOD doesn't mean that they have money to draw from. Most unprogrammed dollars still goes to promised technologies, like hypersonic vehicles. But if you get a wedge, it can grow fast. For example, Project Maven's AI work for UAVs (which Google exited due to moral concerns), received $16 million in FY 2018. That amount went to $93.1 million in FY 2019.

(4) Help your customer help you. Moral of the story is that finding a customer isn't enough, he or she is going to have to find funding, most of which is being lined up for traditional contractors. The pool of prototype funding is relatively small and ad hoc.

Use third-party tools to discover where the budget is going. Or, just go through public budget documents yourself (especially the service justification docs).

Give them some "marketing" briefs that'll help them frame requirements documents. Or, point them to streamlining authorities to bypass requirements process all-together. Shape the requirement without getting bureaucracy involved. Think about your customer who must justify life-cycle cost estimates, Test and Evaluation plans, program management plans, human integration plans, and so forth.

Again, this is the courtship. It takes "patient capital" to receive the DOD's "patient capital".

You may have to help the government through its own contracting process (see DIUx's contracting guide). Get it moving fast if they want you. Help them understand OTAs or other vehicles.

Two problems here:


  1. Usually marketing in defense needs long, very long, lead times. So you'll have to do R&D and marketing for years before the government can secure funds for that purpose. Hope you can carry high overhead for a while.
  2. Your customer will be pressured to compete the work in an open advertisement. The decision will go to a source-selection board. If your proposal was good, they might re-issue the RFP and advertise parts of your solution to the other bidders to see what will happen to the price. The rule here seems to be, if anything goes wrong, just protest the contract.

Once you get a wedge, it can grow and give you credentials for expanding to new markets.

(5) Barriers to scaling will hurt but power through. OK, now you've broken in somewhere. Hopefully, it is dual-purpose technology that has civilian uses like sensors. But we start to hit the scaling problem that vastly increases oversight.

Two obvious barriers are:

  1. When you hit $200 million in sales to the Government, you have to go through Forward Pricing Rate negotiations. All your accounting ducks need to be in a row. These will be the rates you propose on all contract bids, and be the categories (but not rates) that allowable expenses will be reimbursed according to .
  2. Contract value, often in conjunction with Acquisition Category (ACAT) levels, is a major trigger. Certified cost and pricing data must be presented for all contracts over $2 million (up from $750K). When your contract is R&D or early production, it will often require Earned Value Management reporting, and a certified system. When the contract is greater than $50 million, regardless of contract type, you'll get a Contractor Cost Data Report, and if there's $20 million or more in software, another Software Resources Data ReportSome of these requirements flow down to subcontractors. Some dictate your business management processes. You can't avoid them forever.

These business regulations are my bread and butter. In later posts, I'll help you execute these regulations with minimum cost.

Once you break through these matters, you are established. After this point, you'll never go out of business. The reason is that you will have mountains of documented processes and reports that will envelop any outsider trying to provide oversight, like the GAO. They want to know whether you met the processes, not whether you are delivering value. 

Still, delivering value will make you in high demand. Our purpose here is to deliver value for national security and the taxpayer as reflected in earned profits.
_____________

That's a quick intro to considerations for breaking into the defense market. Start small. Grow your wedge. Help your customer. Make sure your business systems are clean and reporting because this will save you when oversight comes. The reports won't help you do your work. Their benefit to the Government is a "warm fuzzy feeling" rather than helping in real decision.

After all, with progressing technology, how useful is historical accounting data? But this is what is meant by accountability today.

Monday, November 12, 2018

How should we react to China's rapidly improving fighter aircraft?

However, Bronk added, most Western air forces have concluded that the usage of thrust vectoring for an edge in a dogfight is generally not worth the extra cost, weight and complexity, given “most modern dogfighting missiles have lock-on-after-launch capabilities, 50 G turn rates and relatively large no-escape zones.”
That was a DefenseNews article on China's J-10B fighter aircraft. It has thrust vectoring which increases its ability to turn.The new stealthy J-20 seems to be adding that capability too.
China' J-10B fighter aircraft with thrust vectoring.
Unlike the America's F-22, the F-35 doesn't have thrust vectoring. But worry not! Us Westerners think it'll all be missile engagements, no gun-shooting dogfights here.

Well, that's also what they said when developing the F-4 Phantom II in 1958. Here's one article describing what happened later in Vietnam:
The aerial dogfight was not supposed to happen. On May 20, 1967, eight U.S. Air Force F-4C fighters were patrolling over North Vietnam when they spotted as many as 15 enemy MiG-17 fighters a short distance away...
But the Air Force had assumed that wouldn’t be a problem — that its then-brand-new twin-seat F-4s would never even get into a close-range dogfight. Instead, the F-4s — and other Air Force and Navy fighters — would always destroy their enemies from long range, using the Sparrow and other air-to-air missiles.
It was a flawed and dangerous assumption that got scores of American aviators shot down over Vietnam. But 49 years later, the Air Force is assuming the same thing … with regards to its new F-35 stealth fighter...
The F-35A has an internally mounted gun (because it's supposed to replace the A-10), the F-35B and C variants have an external pod. Unfortunately they don't seem to work.

What's worse is that it appears that the F-35 got dogged in a dogfight against an F-16.

The point here isn't to debate the merits of the F-35. But we should be worried about the rigid biases in weapons choice. Air Force command has an ingrained culture about stealth, missiles, speed, and so forth, which denies the relevance of agility and dogfighting. It turns out they were wrong before. Perhaps they are right this time. But then it'll be some other technology or concept that they missed entirely.

It took an amazing act of defiance by John Boyd and the fighter mafia for us to get highly maneuverable fighters in the 1970s, including the F-16, F-18, and the F-15. The F-15 was supposed to be swing-wing behemoth like the poor performing F-111 until Boyd came around. The F-16 and A-10 weren't even wanted by the Air Force, nor did the Navy originally want the F-18.

What is needed is an acquisition process that budgets to individuals (like a Program Executive Officer) with potentially non-consensual ideas. They should be able to have wide latitude, so long as they produce results that can be tested. If the new system dogs the old in practice, and it is cheaper to maintain, then it should be put into the force structure regardless of cultural biases towards particular systems.

As Karl Popper recommends, we come up with ideas by conjecture then rigorously test them and discard the failures. We attempt to falsify ideas using experiment. We do not reject conjectures out of hand because of our personal biases. Yet such biases decide program requirements independent of technological evidence.

What is most worrying is not China's planes, but their rapid ability to prototype and learn.
Meanwhile, high-resolution photos taken at Zhuhai reveal the low-rate initial production models of the J-20 operated by China’s air force are showing signs of what Bronk calls “rapid quality improvement.”
Whether or not the F-35 can turn itself around, the point is that we're needed faster adaptation in defense acquisition. If air superiority is an important mission requirement,  it's inconceivable that we wouldn't hedge our bets with parallel development or prototyping.

Usually, the reason is that we cannot prototype freely in major systems because of expense (a funny kind of argument given how far we outspend other countries). But it's one kind of learning process to start austere and simple, then advance your way to a complex system through trial-and-error. 

Its another learning process all together to promise as complex a design as possible, try to get it right on the first try, then spend 20 years patching up the deficiencies because the requirements were not physically possible.

Sunday, November 11, 2018

US has something to learn from Europeans in austere development

It may well startle one of the 439 Lockheed engineers, say, who worked on the P3A Orion modification of the Electra, to learn that in Holland the very successful Fokker Friendship airliner was developed from scratch by a team of 50 engineers, supported by 200 draftsmen, technicians and craftsmen. Or that the French Mirage 3 fighter required 53 engineers, 50 draftsmen and 95 craftsmen to get from contract award to first flight In 13 months. It's doubtful if today any U.S. company could prepare a proposal for such a plane without a staff larger than that.
With the typical French or German project team varying from 5 to 50 engineers on an aircraft project and from 3 to 10 on an electronic project, development costs in these countries naturally are considerably lower than in the U.S. Typical European lead times also are somewhat shorter than ours 1-1½ years as against 2½ - 3½ years….
Unlike ours, the French or Soviet project leader is first and foremost a designer and spends by far most of his time doing actual design work. Success or failure is attributed to him by his management and by the general technical public.
Shapero, Alert. “Life Styles of Engineering.” Space Aeronautics Magazine, March, 1969. 

Emphasis added.

Saturday, November 10, 2018

Russian Dry Dock sinks while repairing Russian Aircraft Carrier

PD-50, a huge floating dry dock at the 82nd Repair Shipyard in Roslyakovo, Russia, accidentally sank on Oct. 29, 2018 while Admiral Kuznetsov, Russia’s only aircraft carrier, was inside for repairs. Kuznetsov is still afloat but the dry dock could be a total loss.
That was from War Is Boring. People may have been killed. Russia doesn't seem to have good options to get the carrier back in shape.
Russian aircraft carrier Admirla Kuznetsov
Here's something on the cost of an overhaul (not production).
Estimates about the cost of the Kuznetsov overhaul have varied from 20 billion rubles, or $326 million, to 65 billion rubles or $1.14 billion.

Friday, November 9, 2018

What can we learn from Eric Schmidt and apply to defense acquisition?

Xerox PARC came out of a similar structure [as Bell Labs]. Xerox at the time was a structural monopoly and not a legal one because they were the only ones building xerographic copiers at the time. They had the ability to build these research centers and during this golden age of research centers; this is where a lot of American science happened, because they had enough money and universities didn't have it.
Today you wouldn't have a separate lab on a hill. We'd been through this. In my career, now over 40 years, I tried to set up these research labs and they don't work when they're separate. At Google when we did the same thing, we created integrated labs where there's not much distinction between the research part and the product development part. What you need is the researchers and developers working as a team.
That was Eric Schmidt on Conversations with Tyler.

The discussion goes right to the heart of technology transition and defense acquisition reform. Just this year, Undersecretary of Defense for AT&L split into two undersecretaries.
  • USD(Research & Engineering) takes over the technology labs and focuses on innovation. It is limited to studies and prototypes.
  • USD(Acquisition & Sustainment) controls everything from full-scale development to production and logistics. It is supposed to be cost conscious.
Splitting one office into two conflicting cultures is essentially doing the opposite of what Eric Schmidt recommends, which is to get "researchers and developers working as a team." The DOD reorganization may worsen the "valley of death" problem. 

It's kind of like the problem that Xerox faced. Xerox headquarters on the east coast picked what technologies to develop and market. It had a very different culture than PARC on the west coast, which was more free-wheeling. Of all the amazing disruptive innovations at PARC, Xerox headquarters could only bring itself to pursue laser printers. Here is one account of what happened at Xerox:
They hired the smartest people and built Xerox Palo Alto Research Center. PARC researchers invented the Ethernet, windowed computer applications, screen icons, and laser printers. Of the 10 most important developments in computing, Xerox PARC birthed at least half of them.
And how did Xerox management handle this windfall? They blew it. Choked. Perhaps the biggest screw-up in technology history. Almost every other company in Silicon Valley benefited from PARC’s innovations, but the only one Xerox managed to cash in on is the laser printer.
And that's because Xerox's business had been printers. Headquarters had no vision for a future of desktop computers, or whatever it might be. Luckily there were other Silicon Valley companies that saw the potential for disruptive innovation. Unfortunately for the defense monopsony, no such start-up competitors are allowed.

USD(R&E), the innovator, isn't the one formally picking technological winners and losers. USD(A&S) controls the milestone decision process, though it doesn't participate in the actual research in traditional S&T budget activities (BAs) 6.1-6.3. The technology labs typically don't perform on BA 6.4 activities like advanced prototyping. That gets handed off across the valley of death to the system project offices under USD(A&S). Here is the GAO.
The acquisition community, as opposed to the S&T labs, traditionally bears the responsibility of maturing technology through advanced prototyping, which is in contrast to how the companies with whom we met operate.  
USD(R&E) controls 18% of the RDT&E account and 7% of investment (includes procurement). USD(R&E) is kind of like PARC in that way, innovative but small and distant.
Milestone Acquisition Process. USD(R&E) performs up until Milestone A. Then, it is handed off to USD(A&S) when it goes into full-scale development (something more than a prototype).
Buried in the conversation, Eric Schmidt elaborates a little on what might bridge the valley of death, because surely, cultures don't have to be across the continent to conflict with each other:
Often in companies, if you see executives who--because things are happening so quickly--don't build common knowledge, things go off the rails. The marking people are doing one thing, the sales people are doing another...
In reproducible goods production on the manufacturing line, tasks are easily partitionable and required little communication. Today, intangible investments in software and platform design requires workers to have a clear goal with common knowledge.

For example, tasks in RDT&E are highly interrelated and require a lot of communication between participants. This means you can't throw money at a problem to solve it. It takes time to on-board the right people and manage their communication.

Yet projects have to scale, which means investing in communication that appears inefficient. Remember, as the number of teammates grow linearly, the interpersonal links grow geometrically. Eric Schmidt said:
... one day I was talking to Larry, and I said, "Larry, we're building glue people." And glue people is my term for people who are very very nice, who sit in between two functions, and you don't need them, but everyone likes them because they carry a person's bag, and they write memos, and so forth, but you don't actually need them. They make the system less efficient, if you will. 
This is kind of like what the Army is doing to bridge the valley of death. It has set up "cross-functional teams" that will manage the communication process between the technology labs and the systems project offices. It is similar to the "Task Forces" they had in the 1970s.

The biggest problem for getting technologies out of the prototype phase and into a successful development phase is again, the budget. Let's say USD(R&E) successfully demonstrated a new prototype and they want to integrate that with sensors, ordnance, and other components to make a production-ready test article. Not only do they have to convince people in USD(A&S), who will be the ones taking it over to manage the rest of the way, they have to wait around for two years until funding is made available.

Two years is a long time.

Now, just because Eric Schmidt recommends integrating research and development (see ambidexterity) doesn't mean everything needs to be integrated. After all, Google's development choices are held into account by consumers (or advertisers). 

Who's holding DOD developments accountable? When a project goes through Milestone B into full-scale development, it is almost impossible to terminate without an act of Congress. It will get produced and fielded. That is why so much scrutiny from 50 or more offices comes down on any project reaching a Milestone. Once funding is authorized, it is built into a long-term plan. All this before we've seen a working copy.

The DOD needs to separate its production decisions from its R&D decisions. Only those systems which are fully tested should be considered for production. Development should not be merely a prelude to production. If there is no market to hold the DOD into account, then organizationally separate them. 

USD(R&E) should have purview over 100% of the RDT&E appropriation, not 18% of it. Better yet, appropriate directly to the Program Executive Officers like they did to the technical bureaus of old. The purview of USD(A&S) should start at Procurement, deciding which systems are cost-effective. Better yet, give those authorities to the Combatant Commands like SOCOM and CyberCOM now have. Those choices of available alternatives will hold the developers into account. This was Armen Alchian's point (here and here).

A couple more things. The technology labs usually have knowledgeable managers with a wide-range of control over projects. Then, before going full-scale, developments get handed over at Milestone B, and more likely before prototyping at Milestone A, where these projects are often assigned to some manager who has little experience in that technical area. Further, the contractor engineers who worked the Bid & Proposals usually don't follow the project, it is handed off as well. Defense developments will filter though several managers before they get into production. What they inherit was never their idea.

This method of assigning people to projects, whose attributes are decided on by strangers, is probably detrimental. Here is Schmidt on motivation:
The key thing in leadership is how you get people to do things. My father taught me that the best way to get people to do stuff is to have it be their idea. So if you can find a way so that your idea is also their idea then you can go back to working on the people whose idea you don't agree with. 
The ideal manager doesn't ever have to do anything because all the people that they work with are self functioning, they're self-organizing. It's so obvious what they should do and they love it so much they never have any problems. They solve all their problems. 
Of course that's not how it really works, but if you can't motivate people around that then you're not really giving them a chance to be successful.
Consider one example of how the defense project you work on, or even pioneer, may get bastardized. After Bell's tilt-rotor aircraft was prototyped in 1981, the DOD added an absurd list of requirements to the project. The lead engineer went to his company VP and told him that "I wasn't going to do it, that I thought it would be the downfall of the tilt-rotor." But it was the only game in town.

The DOD committed to 1,040 birds at $41 billion in 1983 before development even started. It was introduced to operations in 2007, buying far fewer aircraft for more money. The true believers blamed the absurdity of the acquisition process for the problems.

You get a feel how the energy from the engineering leaders was getting sapped by the acquisition process. The development of that project, the V-22, lasted more than 20 years. The DOD forced incredible survivability requirements on the the V-22 development, leading to compounding problems, but in the end, they said they'd never put a V-22 in harms way, such as in a contested combat landing. So much for the engineering compromises.

Here's the last bit. The DOD wants people with certifications, even if those managers with certifications underperform. The DOD looks for credentials and experience rather than bright ideas and enthusiasm.

Here's Eric Schmidt on Google's early process of only hiring young people who went to top-tier universities:
It produced people that were both young in business, and that were aggressive and ignorant of what they were doing. They didn't know what they were doing and made mistakes. Our argument was that in a fast growing company, we need people who can pivot around whatever the new challenge is and we weren't convinced that the people who had experience, since this was a new field, that that experience would allow them to pivot to new problems.
Not that I recommend only going after elite young students. Innovative people that can pivot come out of state schools and trade schools, and might be young or old. In either case, if workers perform well they should be praised.

A major problem in tech start ups seems to be the scaling issue. You not only need to hire a lot of high quality people fast, but the people that helped you get to where you are might not be the right ones to take you further.

The scaling issue in defense is again, right at Milestone B when you scale up to a fully developed system. The DOD historically overfunds projects right when full-scale development starts. Contractors can't ramp up staff and get long lead items in. Then, it takes much longer and costs much more.

I recently bought Schmidt's book, How Google Works. I haven't opened it yet, but I think that his podcast with Tyler has got me motivated. Later I'll post on insights from that book.