Annotated transcription · 12 min read
How to Build a Billion-Dollar Public Sector Tech Business
Lessons from building AWS Government Services from zero to $10 billion and transforming how regulated industries adopt cloud and AI.
Creating a Market That Didn't Exist
When Amazon Web Services decided to pursue government customers in 2010, there was no playbook. Cloud computing existed for startups and developers, but the federal government had no framework for purchasing it, no security protocols to govern it, and no real understanding of what it even was. Building the public sector practice at AWS required literally inventing the market from scratch.
The early approach was grassroots and educational. With a team of just two people and zero revenue, the strategy centered on demonstration rather than sales pitches. Small evening sessions—pizza and cookies included—brought government IT leaders into a conference room where solution architects would walk them through the basics: how to access the console, spin up an instance, use storage. For technical professionals accustomed to months-long procurement cycles and hardware installations, the ability to deploy a data center in five minutes felt almost impossible.
Resistance came from multiple directions. System integrators worried about losing consulting revenue. Chief Information Officers, accustomed to controlling infrastructure, hesitated to cede authority. The term used internally was 'server huggers'—leaders who saw the shift to cloud as a threat rather than an opportunity. Overcoming that resistance required shifting the conversation from IT control to mission outcomes, demonstrating that cloud actually gave technical teams more flexibility, not less.
One critical insight emerged early: mission owners, not CIOs, would drive adoption. Organizations like NASA's Jet Propulsion Laboratory had urgent problems—like a Mars rover transmitting far more data than anticipated—and needed compute and storage immediately. These mission-driven teams became the beachhead customers, proving that cloud could solve real operational challenges quickly and cost-effectively.
Defining Cloud for Government
Beyond technical demonstrations, the federal government needed formal definitions and compliance frameworks. AWS worked directly with the National Institute of Standards and Technology to establish the official definition of cloud computing. That NIST definition became the global standard—other governments, including Australia, adopted the same language when building their own cloud strategies.
Security and compliance presented a larger challenge. Paper-based audits couldn't accommodate distributed computing. In partnership with the General Services Administration, AWS helped create FedRAMP—the Federal Risk and Authorization Management Program—which established an ongoing security model tailored to cloud architecture. FedRAMP became more than a government standard; highly regulated industries like healthcare and financial services adopted the same framework, recognizing that if federal agencies trusted the model, it met the highest bar.
This created a feedback loop. As government agencies validated cloud security, commercial enterprises felt confident adopting it. Regulated industries began aligning their compliance processes with government standards, creating a unified approach across sectors. The work done to enable government cloud adoption opened pathways for entire industries.
The CIA Contract That Changed Everything
Winning the Central Intelligence Agency contract in 2012-2013 marked a watershed moment. The contract wasn't just for the CIA—it was for the entire intelligence community. The stakes were enormous, the competition fierce, and the cultural shift required within Amazon significant. Building classified cloud infrastructure meant personnel clearances, secure facilities, and entirely new operational protocols for a company built on agility and openness.
Despite having only a small team bidding against organizations with massive proposal operations, AWS won. The intelligence community had studied cloud computing extensively and understood they couldn't sustain cutting-edge infrastructure through traditional government contracting. They could build something impressive once, but keeping it current with the pace of technological change was impossible under existing procurement rules.
The impact extended far beyond the intelligence community. When commercial enterprises learned that the CIA trusted cloud infrastructure, skepticism evaporated. If the nation's most security-conscious agency could use cloud computing, any organization could. The CIA contract became the ultimate reference point—proof that cloud was secure, reliable, and suitable for the most sensitive workloads imaginable.
Building Teams for Consumption-Based Business Models
Traditional enterprise software sales operate on a transactional model: configure a product, negotiate a license agreement, close the deal, collect payment. Cloud computing inverted that model entirely. Customers only paid for what they used, which meant revenue came from delight and consumption, not contract signatures.
This required a fundamentally different type of account executive. Early AWS government sales teams discovered customers were spending literal dimes and dollars—spinning up instances just to experiment, then shutting them down. An account executive paid on commission would have found this model unworkable. Instead, the role demanded consultative patience: understanding customer missions, whiteboarding solutions, bringing in solution architects to demonstrate capabilities, and waiting for usage to grow organically.
Hiring shifted toward people who loved solving mission problems rather than closing transactions. The best candidates had technical depth, intellectual curiosity, and strong emotional intelligence. Solution architects needed both technical fluency and the ability to listen, translate, and collaborate. The team that ultimately scaled AWS Government Services to $10 billion looked nothing like a traditional enterprise software sales force.
This model extended to internal operations. Forecasting couldn't rely on pipeline deals. Instead, business operations teams built sophisticated data systems—using tools like Tableau—to track usage patterns, understand capacity needs, and predict growth based on workload deployment rather than contract close dates. Capacity planning became critical: if large customers came online without adequate infrastructure ready, mission-critical systems would fail. This required tight coordination between field teams and infrastructure engineers, creating a feedback loop that shaped what AWS built.
Scaling Through Operational Discipline
Rapid growth demands constant adaptation. One principle became a mantra: 'We'll do this till we know better.' This mindset allowed teams to move quickly with imperfect information, knowing they could iterate as they learned. Amazon's leadership principles, particularly around diving deep and being right a lot, reinforced this approach.
Amazon's internal culture demanded clarity and precision. PowerPoint presentations weren't used; instead, every proposal came as a written narrative. Leaders read these documents in silence at the start of meetings, then discussed. This forced clearer thinking—narratives require logical flow and expose weak reasoning that slides can hide. Writing style had to be crisp, with minimal filler and direct answers to questions. When asked a yes-or-no question, the answer had to start with yes or no, followed by explanation only if requested.
Risk assessment was non-negotiable. Amazon leadership expected thorough risk analysis, not because they avoided risk, but because they wanted to understand it completely before committing. Hiding risk signaled dishonesty; outlining it thoroughly signaled competence. The framework of one-way versus two-way doors helped prioritize decisions: one-way doors—irreversible choices—required extensive analysis, while two-way doors—reversible experiments—could move faster.
Operational reviews extended to profit and loss. Leaders needed to think like general managers, understanding cost structures, margin implications, and return on investment across their entire business, not just their immediate function. This created accountability but also autonomy—deliver results, demonstrate sound judgment, and you earned the freedom to build new business lines globally.
Getting Customers to Tell Your Story
In traditional government contracting, customers rarely spoke publicly. The risk of appearing on the front page of a major newspaper if something went wrong created a culture of silence. At Microsoft, the default approach was avoiding customer references entirely. AWS needed to change that.
Leadership challenged the assumption that government customers wouldn't talk. They did—enthusiastically—once they experienced success. The strategy shifted to making customer stories the core of credibility. Public sector summits and industry conferences featured government leaders explaining how cloud transformed their missions. NASA discussed the Mars rover. Intelligence agencies discussed modernization. Mission owners became advocates.
This approach recognized a fundamental truth: a company's superpower isn't what it builds, but what customers accomplish with those tools. Usage and outcomes validate technology far more effectively than marketing claims. For startups entering regulated markets today, this lesson remains essential—land the right customers, help them succeed, and let them tell the story.
AI Adoption Is Moving Faster Than Cloud Ever Did
Building AWS Government Services from zero to $10 billion took a decade. AI companies are reaching comparable scale in a single quarter. The velocity is unprecedented—and it comes with challenges. Where cloud required years of education before regulated industries felt comfortable adopting, AI is being purchased aggressively by governments and enterprises without the same foundational frameworks in place.
Federal government still lacks a clear definition of AI comparable to the NIST definition that standardized cloud computing. Security and compliance regimes remain fragmented. Different agencies approach AI procurement differently, creating a patchwork that makes it harder for startups to navigate. This mirrors the early cloud era—but the stakes are higher and the pace faster.
One prediction: AI spending will follow the cloud optimization curve. Early adopters are consuming heavily, experimenting broadly, and spending aggressively. Eventually, organizations will demand optimization—understanding which workloads genuinely benefit from AI, which models deliver the best cost-performance trade-offs, and where token consumption can be reduced without sacrificing outcomes. Just as cloud customers eventually demanded better cost management, AI customers will too.
The General Catalyst Institute's Mission
Most venture-backed startups operate in highly regulated industries—financial services, healthcare, defense, energy, manufacturing. These companies have incredible technology but often lack expertise in policy, government relations, and regulatory strategy. Large enterprises have entire teams for this work. Startups don't, and the gap puts them at a disadvantage.
The General Catalyst Institute exists to close that gap. Backed by General Catalyst and working across roughly a thousand portfolio companies, the Institute educates policymakers, advocates for startup-friendly regulations, and teaches founders how to navigate government. This happens at the industry level—not lobbying for individual companies, but shaping the environment in which all startups can succeed.
Tactically, this means bringing curated groups of founders to Washington. Sessions with White House officials, Pentagon leadership, and Congressional staffers give startups direct access to decision-makers. The Institute prepares founders: how to tell a story to a lawmaker, what questions to anticipate, how to follow up. Founders learn not just policy, but go-to-market strategy for government—how contracting works, how to structure deals, how to build relationships that lead to adoption.
One example: a robotics founder from upstate New York had never visited Washington. After his first trip, facilitated by the Institute, he testified before Congress twice and secured government contracts. Lawmakers began calling him for input. This is the model—giving founders who build transformative technology a voice in shaping the policies that govern their industries.
Why Founders Need to Show Up Seriously
Tech culture prizes informality. Hoodies, flip-flops, and t-shirts signal authenticity and a focus on building rather than appearances. In Silicon Valley, this works. In Washington, it doesn't—at least not until you've already established credibility.
Government officials, military leadership, and congressional staffers operate in a formal environment. Showing up underdressed signals a lack of seriousness. Early in the AWS government business, an infrastructure lead arrived at the CIA wearing jeans, a Hawaiian shirt, and flip-flops—with no other clothes. The visit proceeded, but it required intervention and set the wrong tone. The lesson: respect the culture of the room you're entering.
This isn't about conformity for its own sake. It's about recognizing that policymakers meet hundreds of companies. First impressions matter. A buttoned-up appearance demonstrates that a founder takes the opportunity seriously, respects the institution, and understands the stakes. Once credibility is established—once you're known—informality becomes acceptable. But in the first meeting, professionalism opens doors.
What's at Stake in the Next Year
Three priorities define the near-term opportunity: AI adoption at scale, an AI framework for federal government, and faster permitting for critical infrastructure.
AI adoption is accelerating, but without clear standards, every agency and enterprise is navigating independently. An AI framework—analogous to what NIST provided for cloud—would give organizations a common foundation. It would clarify security expectations, define procurement processes, and reduce the compliance patchwork that slows startups.
Infrastructure permitting remains a bottleneck. Building data centers, securing critical minerals, and deploying energy infrastructure all require navigating complex regulatory approval processes. Streamlining permitting doesn't mean eliminating oversight—it means removing unnecessary delays that slow deployment without improving outcomes. As the U.S. competes with China on AI and advanced manufacturing, speed matters.
The current administration has opened contracting opportunities and reduced barriers in ways not seen in decades. The window to shape policy, influence frameworks, and position startups for long-term success is open now. Capital is available. Founders are building transformative companies. The question is whether policy can move fast enough to support them—and whether startups will show up prepared to engage.
Key takeaways
- → Building markets in regulated industries requires education first, sales second—early AWS government work focused on teaching what cloud was, not just selling it.
- → Landing high-credibility customers like the CIA validates entire markets—commercial enterprises adopted cloud once government proved it was secure.
- → Consumption-based business models demand consultative teams focused on customer mission success, not transactional deal-closing.
- → Customer references are the ultimate credibility—getting users to tell their success stories builds trust faster than any marketing campaign.
- → AI is being adopted faster than cloud ever was, but without equivalent regulatory frameworks—creating both opportunity and risk for startups.
- → Startups in regulated industries need policy expertise and government relations strategy, not just great technology—the General Catalyst Institute exists to provide that.
- → Showing up professionally in Washington matters—informal tech culture doesn't translate well to government and military settings until credibility is established.