We already know that the government is one of the largest IT buyers, but in many ways it is also an IT builder. Especially for areas where the government is doing something that no one else is doing, like running Medicare and Social Security -- i.e., unique services no other company out there is building software for. That's where the USDS comes in. Now almost two years old, the United States Digital Services is "a startup at the White House" responsible for mission-critical, citizen-facing services like improving Veterans' Affairs healthcare applications and benefit claims appeals, or student loan repayments. But can one really operate as a startup while embedded in an entity as complex and huge -- remember, each agency would be like a Fortune 500 company -- as government? It may not be move fast and break things, observes Mikey Dickerson, Google engineer-turned-administrator of the USDS (and one of the fixers of the original healthcare.gov), but "There's a world of difference between moving a little slower than you're used to and not moving at all." And it's not like large companies don't have huge, bureaucratic structures either. In fact, argues USDS co-founder and deputy administrator Haley Van Dyck, both government and big companies are going through the same shift right now, one where technology is moving "from what used to be the periphery into the core mission of business". So what are the similarities and differences between operating in government vs. big companies? How to draw talent from the private sector into the public sector while avoiding adverse selection (hint: through tours of duty)? And finally, what about fixing the procurement process (because "you don't buy software the same way you would buy a battleship")? Dickerson and Van Dyck share their thoughts on these issues, as well as peacetime/wartime tactics, in this episode of the a16z Podcast.

Do we need a new pay system for the way startup employees are compensated? While many people agree that the current 90-day exercise practice — an outdated relic of when companies used to go public/get liquidity in a much shorter timeframe — is far from ideal, neither are some of the other solutions proposed so far. Because incentives matter, and behavior follows incentives. Which is fine as long as you know all the implications around what you’re incentivizing for and it aligns to what you want as a founder for your company and employees. So “let’s get it out from under the rug, let’s talk about it, and let’s design a system that works for whatever you want your company to be”, argue a16z partners Ben Horowitz and Scott Kupor in this episode of the a16z Podcast. The discussion goes beyond just the question of a 10-year exercise to other configurations — such as Snapchat’s model and Tesla’s model for timing options, as well as radical experiments like “progressive equity“. What are the tradeoffs of each approach? How does the type of company you’re building (a complex hardware or infrastructure-heavy startup for example) change things? How does the broader environment affect all these considerations (and might plans to create a new long-term stock exchange help)? Finally, is it fair to treat tenure as a proxy for the actual value a particular employee contributed to building the company? Or to optimize for earlier vs. later employees, particular if the earlier ones de-risked the company and later ones helped scale it? And what do different employees want — more options, more RSUs, cash, more ownership, more stability, more mobility? All this and more in this episode…