5 ms·

The traditional model in the defense sector is: - Military or gov't produce exact specifications for something - Contractors bid to create that something - T

The traditional model in the defense sector is: - Military or gov't produce exact specifications for something - Contractors bid to create that something - The end product ends up being the result of macro-management and even sometimes micro-management from the very top, which would be the equivalent of SV tech startups being instructed on what to build by Oracle and Microsoft But since the military and gov't are open to working with independent parties when said parties come to them with an offer, Anduril and similar companies have more freedom to develop tech as they see fit and then go and sell it to the military/gov't, and judging by this article, with considerable success.

gnopgnip 7y ago
How does palantir fit into this
- ganoushoreilly 7y ago
  They sort of started out solving an internal problem and then took that domain knowledge to build their platform. Their success early on relied on being able to put together a really good presentation. I would hardly look at their tech as being extremely cutting edge though, they're simply a package solution with a decent enough outcome with minimal competition in what SV would consider an "unsexy" industry. Getting a foot in the door with Govt. Contracting is probably the hardest and most expensive part. Most won't go through the hoops and it creates fewer competitors or alternatives (as OP alludes to).
austincheney 7y ago
The new defense model is the Air Forces Kessel Run project.
rmah 7y ago
While what you write is true in a way, but saying "military or gov't produce exact specifications for something" may be interpreted by some people involved in software development in the wrong way. I've worked on a couple DoD related projects long ago and they don't put out specifications as much as requirements. If anything, the requirements are annoying vague. They will ask for something like "a light truck that can carry at least 1 ton while overcoming vertical obstacles 1 meter high and climb 50% grades". Or "software to track and manage electrical usage of a base at the building and circuit level. It should includeoff-site historical data storage, an interface for reporting and the ability to transfer data with existing reporting systems." Obviously the real RFPs have a long, long set of requirements, often conflicting :-). Each vendor is responsible with coming up with their own approach to the stated problem, their own designs and all the rest. And while there is certainly far too much micro-management -- and a healthy does of mismanagement -- a naive read of the rules makes it clear that most of the bureaucratic rules were created with good intentions. That is, they were created to fix "bugs" in the procurement system, to reduce corruption, to try to reduce errors, etc. Sadly, as you implied, the mass of contract bidding rules is now literally inches thick when printed out (I know because I printed out one set of them from the GSA) and probably create more problems than it solves. Ah well, such is life.

gnopgnip 7y ago

How does palantir fit into this

ganoushoreilly 7y ago
They sort of started out solving an internal problem and then took that domain knowledge to build their platform. Their success early on relied on being able to put together a really good presentation. I would hardly look at their tech as being extremely cutting edge though, they're simply a package solution with a decent enough outcome with minimal competition in what SV would consider an "unsexy" industry. Getting a foot in the door with Govt. Contracting is probably the hardest and most expensive part. Most won't go through the hoops and it creates fewer competitors or alternatives (as OP alludes to).

austincheney 7y ago

The new defense model is the Air Forces Kessel Run project.

rmah 7y ago

While what you write is true in a way, but saying "military or gov't produce exact specifications for something" may be interpreted by some people involved in software development in the wrong way. I've worked on a couple DoD related projects long ago and they don't put out specifications as much as requirements. If anything, the requirements are annoying vague. They will ask for something like "a light truck that can carry at least 1 ton while overcoming vertical obstacles 1 meter high and climb 50% grades". Or "software to track and manage electrical usage of a base at the building and circuit level. It should includeoff-site historical data storage, an interface for reporting and the ability to transfer data with existing reporting systems." Obviously the real RFPs have a long, long set of requirements, often conflicting :-). Each vendor is responsible with coming up with their own approach to the stated problem, their own designs and all the rest. And while there is certainly far too much micro-management -- and a healthy does of mismanagement -- a naive read of the rules makes it clear that most of the bureaucratic rules were created with good intentions. That is, they were created to fix "bugs" in the procurement system, to reduce corruption, to try to reduce errors, etc. Sadly, as you implied, the mass of contract bidding rules is now literally inches thick when printed out (I know because I printed out one set of them from the GSA) and probably create more problems than it solves. Ah well, such is life.