In this episode of Rewiring Government, DOBT’s CTO Adam Becker steps in as guest host and talks to Aidan Feldman, an Innovation Specialist and developer at 18F, which is part of the United States General Services Administration’s Technology Transformation Service. They discuss cloud.gov, some interesting “bureaucracy hacks,” and the remaining barriers to real technological change within the federal government. If you’re interested in learning more about the work 18F is doing, check out Aidan’s talk about IT compliance, 18F’s guide to launching software, and cloud.gov.
Use the player above to listen, or subscribe on iTunes and Google Play! You can also add our RSS feed to your favorite podcast app. If you like this episode, rate and review us on iTunes, and tell your friends.
A transcript of the interview is below, edited for content and flow.
Adam: Welcome to the Rewiring Government podcast. This is your guest host, Adam Becker. I’m stepping in for Josh because, today, we’re not getting wonky, we’re getting technical. I’m going to be interviewing Aidan Feldman, a developer at 18F, which is part of the US General Services Administration’s new Technology Transformation Service. Aidan and I do very similar work, and we could talk shop all day long, but in this interview, we focus on his work on cloud.gov, which is a game changer for the way that federal agencies deploy software.
We also talk about compliance and how we both gained an appreciation for what can be a hand-wringing bureaucratic process. Lastly, we get into the culture of 18F and what makes it so appealing for Aidan to work in the public sector. Well, that’s enough from me. Let’s get to that interview.
Adam: Hi, Aidan. Welcome to the Department of Better Technology’s Rewiring Government podcast.
Aidan: Thanks for having me.
Adam: Before we get started, you seem like you’ve done this podcast thing before. Is that an accurate assessment?
Aidan: I’ve been on a couple in a mix of my personal and professional capacity. I was on Software Engineering Daily, CodeNewbie, and a couple others.
Adam: You’re a seasoned veteran compared to me because I have not done this before. Actually, I’m kind of jumping into the deep end by hosting a podcast before I’ve even appeared on a podcast. The only advice I’ve gotten is that this should be “infotainment,” but I’m not really sure what that means. Any podcast tips for me?
Aidan: I actually just saw a great talk by Saron Yitbarek, who was speaking about all the logistics that go into podcasting, and it is way different to be on a podcast, where you just show up and talk for an hour, than to produce one. [Laughs] There’s a lot more work in terms of thinking about the setup and the equipment, thinking about the mix and cast, thinking about the questions you’re going to answer, how structured you want to be, when you want to chase down rabbit holes. I have not done the hosting, and that seems much harder.
Adam: Gotcha. I made these questions a few weeks ago, and then looked at them again earlier this morning. In terms of equipment, I’m here on my headset (It’s not anywhere near professional.), you’ve got your iPod earbuds, and we’re doing this over Google Hangouts.
If our listeners can’t tell, Aidan and I are pretty good buddies IRL, as well as in [both] the professional and the Internet world. But, I’m back in California now, and Aidan’s in New York, so we’re doing this interview remotely over Hangouts.
Aidan and I met a few years ago in New York City, and, as I remember, Aidan, I think you were coming off of working with some pretty awesome companies like GitHub and Artsy, and you were looking for opportunities in the GovTech space, which is how you and I got introduced. It was one of those half-interview, half-hanging-out meetings, but in the end, you decided to go to 18F. I can’t really be mad about that, since you’re still working for me, just a little more indirectly in my capacity as a taxpayer and not my capacity as a business owner. Can you give your professional background and a little bit about how you got involved with GovTech movement?
Aidan: Out of college, I went the tech company route. I was working at publishing company, then at a blogging startup, and then at Artsy, [an online art collecting and education website]. Then I went to GitHub where I was focusing on education and technology, basically getting open source and professional software development practices into classrooms. I really liked the social-good aspects of that and wanted to go further with it. From there, 18F presented itself as this amazing opportunity—I can work open source 100% of my time, which is really important to me. Plus, I couldn’t ask for a better mission, and I think there’s a lot of room for improvement in the federal government.
Adam: That’s awesome. You mentioned that you can work basically 100% open source; are there any other companies you can think of that have that same benefit to the work that you’re doing?
Aidan: Since I left, Artsy has gained a really strong commitment to open source. There are other companies, like GitHub and a few others, that offer their main products as open source. It’s something that I’m hoping is catching on but [it’s] still not common. There are certainly companies that produce a lot of open source; maybe their main product isn’t [open source], but they’ll create frameworks and [other open source projects]—Facebook with React, Google with Angular, Kubernetes, or any number of projects. They’ll publish a project that they use frequently, but it isn’t their main [offering]. 18F publishes everything.
Adam: It’s not just publishing, right? 18F has put together [an open source policy] that goes a long way above and beyond even the federal government’s recently enacted open source policy, which is kind of a 20% policy. 18F, as far as I understand, is nearly 100% open source, with very small exceptions.
Aidan: Exactly. It’s something that predated me, and this is what drew me to the team. 18F has this strong stance that unless there’s a really good reason why it can’t be, all of our source code and documentation should not only be released in the open, but also be developed in the open. I think [during] some early projects, we were okay with saying, “We’ll start working on this closed source, and then we’ll get around to opening it up later.” That’s never easy, and I think we realized that unless we make a strong commitment out of the gate with new projects, it’s not going to be realistic for us to get things open.
We now write that into our contracts: You have to be okay with us working in this way. We understand the concerns of the agency partners or contractors [or even outside vendors who might contract us to build something] that might feel uncomfortable about this and hopefully that’ll allay those fears.
Adam: Let’s take a step back. (I feel like we dove into the tech talk really quickly there.) Tell me, what’s your official job title at 18F?
Aidan: Almost everyone who works [at 18F] has the title “Innovation Specialist,” which doesn’t really mean anything. There’s a bureaucracy hack, a way that we hire much faster, if we have these specialist positions. Everyone, whether they’re a designer or a developer or a researcher or a content specialist is called an Innovation Specialist, but I’m a developer.
Adam: What does an Innovation Specialist—in reality a developer—do all day? What kinds of projects have you’ve worked on, and what are you working on now?
Aidan: My first big project was a web application to help with purchase approvals. [Purchasing in government requires] a lot of signatures, even to buy something small like a stapler. Two to six people have to sign off. That was all being done through pencil and paper, and we wanted to digitize it, to make it easy for people to keep track of requests and audit. I was doing full-stack development there. Then, I moved to doing some DevOps work, and recently I’ve been doing a lot of work around security and compliance, plus technical [work].
These days being a technical person in the room [means] pushing for reforms but also thinking about how we can do tooling around policies and make dealing with compliance easier for our teams and others.
Adam: I think it’s really interesting to note that a developer [isn’t always] going to be writing code in their text editor, furiously typing at the keyboard like you see in [media representations]. From what it sounds like, your role is [to] interface between the technical developers and the legislative, policy, and operational aspects.
Aidan: It’s going to vary person-by-person. There are certainly people on the team who are coding almost all day, every day, but 18F can cater to your interests and skills. In this case, I don’t think compliance was something that I was necessarily excited about or daydreamed about, but it was something that I saw as an enormous blocker for our engineers and other people on our team.
I can write some code, I can work on a web app or something like that, but pushing on the policy is going to have even more impact. That’s where I’ve been gravitating to.
Adam: [It’s important to] find those areas where you can leverage more than just the ability to make a simple feature or code change and actually enable other developers so that they can make even more bigger changes in the future.
One of the projects that you mentioned is compliance, but I’m also familiar with the project called cloud.gov. How do those two fit together? [How does your team] interface with the other teams at 18F?
Aidan: Cloud.gov is an offering of 18F. 18F does some projects that we call “Custom Partner Solutions,” things that we build for an agency specifically. (Say, an agency wants a new open data portal or wants a new homepage with different ways to access their data and content.)
Cloud.gov is [a project on] our products and platforms side, meaning that we developed it in-house and are offering it to agencies in the federal government as a centralized thing.
Cloud.gov is a Platform as a Service, meaning that’s going to [enable] teams to deploy web applications very quickly and easily and, most importantly, in a secure and compliant way.
Cloud.gov is going through a process called FedRAMP right now. This is where the compliance aspect comes in, where we basically are getting a big compliance stamp of approval on the system itself. Other infrastructure providers have it, but this is a higher level abstraction over something like Amazon Web Services or Azure. By having more of the stack taken care of, applications built on top of it are going [to have a much more streamlined experience during] their compliance process, and they’re going to be able to launch software much faster.
Adam: Let’s break a little bit of that down. I think our listeners probably have some understanding of what a Platform as a Service is, but for me, cloud.gov is by far and away the most exciting project that 18F has taken on. It solves a really serious pain point that I experienced when I was a Presidential Innovation Fellow. We had six months to ship a product (in our case, RFP-EZ, a really simple pilot website), but the hardest thing about shipping that website was not actually writing the code or designing the platform. It was actually getting the server and the authorization to go live, even for this really small pilot project.
What do you think is game-changing about cloud.gov? If you had to quantify the benefits, say to the Deputy Secretary of the Department of the Interior (no offense to whoever may hold that position right now) or someone non-technical. How would you describe the benefits of a platform like cloud.gov? What is it replacing?
Aidan: [We’re thinking about this messaging] a lot right now.
The people who decide what systems to use for things like hosting are not the people who use it. They’ll have contracting officers and procurement officers and CIOs pick infrastructure, and that gets handed to developers. Or the developer says, “I need to deploy something, and none of our existing options serve it.” That requires a large bidding process, and you have to hire [an] outside vendor. Then, you have to hire an operations team to actually run the [project]. [If] you don’t have that experience in-house, the procurement side can really slow down the process, even if you have 100% of the code written.
Then, there’s the whole compliance process. Even if your code is 100% complete, you have to get authorization to run the [project] in public and start getting real users to interact with it. I’ve heard that [process] can take a year in other parts of government, even if the code is done. If you’re like 18F, and you’re trying to build [and release] products frequently, that’s a blocker. Cloud.gov speeds that up. We’re trying to get under two weeks for approval to operate (ATO).
Adam: Wow! Approval time down from years to weeks?
Aidan: Exactly.
Adam: We’ve got increased speeds; we’ve got a clear procurement hack. Can you explain how cloud.gov is enabling agencies to get around that lengthy procurement process? What’s the key difference there?
Aidan: Using outside vendors [is intended to prevent] favoritism, [and there are] good reasons why you want to prevent that within government, especially with large contracts.
To do that, regulators intentionally slow down the process: You need to have an open bid. You have to spell out your requirements very specifically. Then, you have to pick the cheapest [bid] that matches those requirements, even if it’s not the one you had in mind. That’s a dramatic oversimplification of how procurement works, but that goes for the infrastructure providers, that goes for the dev teams, that goes for operations teams, if those are different.
[This complex process] is a disincentive because it’s such a hassle to do those things in order to ship frequently. It’s a disincentive to [build] specialized software, [instead of buying] everything all at once, because it’s such a hassle each time. With cloud.gov offered within the government, the agreements are a lot simpler; you don’t have to do that same bidding process.
I should be clear that cloud.gov is not something that’s forced on an agency. It’s something that’s offered by 18F to the rest of government, but no one is forced to use it. They are welcome to use whatever cloud provider they want; this is just an offering. 18F operates like a business in that way.
Adam: I think that’s really one of the key parts about the work that you’re doing at 18F and the US Digital Service: Things aren’t thrust on agencies. You guys are showing agencies, “Hey, here’s a better way.” I think that’s a key difference between the work here in the US, versus some of the other mastheads in this space, like the Government Digital Service in the UK.
Aidan: Totally.
Adam: Maybe it’s a good time to get into Amazon Web Services (AWS), since you mentioned that cloud.gov is leveraging AWS as a platform. AWS has been a really big game changer for companies in all sorts of industries. It’s been a really big game changer for tech companies, where it reduces the complexity and cost of maintaining servers and other infrastructure by multiple orders of magnitude. I think it’s great that the federal government is getting on this bandwagon (and it’s sorely needed), but [it’s concerning to see government reliance on it] because it’s so ubiquitous in the tech industry.
As you mentioned, the procurement process is in place to ensure that everything is fair, everything is competed. How dependent is cloud.gov on AWS, and how enshrined is AWS in this new platform?
Aidan: First, I should be clear that I don’t want to endorse AWS or any other provider. I think it’s really about having virtualized servers (“treating infrastructure as cattle, not pets” is the mantra), and AWS provides a lot of tools around that, a lot of APIs and a lot of different services. But other infrastructure providers certainly provide these things.
You asked about how strong this reliance on AWS might be. An important thing to us with building CloudFoundry was not having vendor lock-in. We looked at a few open source systems, and we looked at a few commercial systems; what we settled on was this Platform as a Service called CloudFoundry. If you’ve used Heroku, think of it like an open source Heroku. [These services] abstract the underlying servers from the developers and people trying to launch applications on them.
Basically, you say, “I want to deploy this code. I want to run a couple of instances of it. I need to have a database, etc,” and it manages handling the restart, handing down the user permissions, scheduling to all the different servers—it does all that behind the scenes. You don’t even have to think about it as someone deploying to it.
That ease was really important to us. One really nice aspect about CloudFoundry is the way it interfaces with the underlying infrastructure provider or the Infrastructure as a Service. In this case, [we’re using] AWS, but that’s configurable. We could theoretically move all of cloud.gov to Azure, or to our own servers if we wanted, and people using cloud.gov wouldn’t notice.
Adam: [What kind of] change would that represent for your team or for your team’s code base? Would it be 2% of the code, 10%, or less?
Aidan: We’re using this large, open source, infrastructure-agnostic Platform as a Service as a center chunk [of our code base], so we didn’t write most of the code that’s in cloud.gov. Cloud.gov is [being customized with] a lot of documentation and tools for compliance and billing, but none of that is AWS-specific or specific to any infrastructure provider.
Basically, the only things that are custom are the bindings. [For example:] I want to create a PostgreSQL database; where does it find the PostgreSQL databases in the underlying infrastructure that you’re using?
Adam: [And you’re saying that] those can be swapped in and out for different infrastructure providers?
Aidan: Yeah.
We could have made it even more agnostic, in the sense that we could have just said, “Create a PostgreSQL,” and you wouldn’t even know how the underlying database is provisioned. We did make that part a little AWS-specific, just for ease of implementation, since we’re relying on Amazon’s Relational Database Service. By relying on that, we’re able to create a very thin layer that connects them, rather than greater abstraction.
We did make some choices that made us a little more tightly coupled, but I imagine that we could move to a completely different infrastructure provider in a matter of months. We actually just moved within AWS from the US East region to GovCloud, even with all the refactoring and cleanup that came with doing that. It’s not an enormous change. If you’d ask any other Platform as a Service what it would take for them to move infrastructure, I think it would be much longer.
Adam: That’s incredible. You mentioned that you had to make some trade-offs there and perhaps tied yourselves a little closer to Amazon RDS than you would have wished, [but] I think that that’s totally acceptable. 18F is only a few years old in the first place.
[I think about the speed at which] cloud.gov has come together as a product, and now you’re saying that despite all of these benefits that you’re leveraging from AWS, you could still migrate to a completely different provider or to your own servers within a few months. That’s really incredible and a great model going forward. [You’re] making the procurement process work as intended and not letting it slow you down or be a frustration [like it is] for a lot of folks in government.
Aidan: Totally, and vendor agnosticism doesn’t even end there. [Even though we’ve created custom] bindings to the infrastructure beneath the CloudFoundry layer, CloudFoundry itself is an open source project, and there are other commercial hosts for the open source project. That means that teams using cloud.gov could switch from cloud.gov to another CloudFoundry provider; there are probably a dozen well-known companies offering this as enterprise software. If they’ve set it up well, they could probably make those switches in a matter of days.
Adam: You’re saying that you guys made it easy for your clients to fire you?
Aidan: Exactly. There’s a lack of vendor lock-in at multiple levels.
We joke that a goal for 18F would be putting itself out of a job, once there’s enough technical and design expertise within the rest of the agencies that we work with, that our central consulting model is not really needed.
I think that can go for cloud.gov too. If commercial providers are able to offer the same level of compliance help that we offer, there’s no reason that agencies couldn’t use them instead. Commercial providers can probably get even more scale than we could and get cost savings from that. A goal for cloud.gov would be to not need cloud.gov.
Adam: That’s funny. I was going to say that we’ve done the same thing here at DOBT. We’ve tried to make sure that, at all steps of using our software, our clients have the ability to fire us. [We do this by] making it easy for folks to export their data and making sure that nothing is in a proprietary format that couldn’t be used elsewhere. I don’t know if we’ve built it into our business plan that eventually we’ll become obsolete….
Going back to these users that are using cloud.gov, who are they and is this the first time that they’re using a Platform as a Service?
There are two options in my mind. You have users [from] federal agencies who haven’t experienced a lot of these benefits before. On the flip side, you might have folks coming in from the private sector who are already used to platforms as a service. Things like Heroku, or AWS. Where do your users fall in each of those buckets? Or is there a bucket that I’m not even thinking of?
Aidan: There’s two types of people in the world, people that have used Platform as a Service and people that haven’t. [Laughs.]
Our users are federal employees for the most part, or teams contracted by federal agencies.
But cloud.gov started off as scratching 18F’s own itch. We were launching these projects all the time, trying to come up with Chef recipes for every single server that we needed to deploy a new application on. It was just a big hassle to get every new application set up because we have teams of two or five that need to launch something, and they’re almost definitely not going to have DevOps experience, know how to configure a server safely, or know how to set up continuous deployment on their own.
This centralized platform (cloud.gov) standardizes the way that you interact with it. If you have a best-practices-built app, if your Ruby application has a Gem file, or your Python application has a requirements.txt in the home directory, it’s going to know how to install dependencies for you and cache them so that deploys are faster. It’s going to do all these smart things that would be a huge hassle for any one of these small teams to set up.
Because it’s centralized and because we did it off the shelf with CloudFoundry, this just makes our lives at 18F a lot easier. Cloud.gov came out of a need to support all of the projects that we were trying to launch and from there it was not hard to imagine. If we’re solving these problems for ourselves, and we’re hiring some of the smartest technologists to work in government, why not offer it to these other teams that are struggling. They certainly don’t have operations experience, [and they may even be] relying on contractors for development. cloud.gov takes care of as much as possible for them, and it’s going to make an enormous difference.
Adam: Had cloud.gov been around when I was a Presidential Innovation Fellow, I could have gone home three months early. It would have saved us a lot of hand-wringing.
It’s really interesting, you mentioned that your initial users were members of 18F, which is around maybe a 200-person organization right now?
Aidan: Yeah, I think we’re just at 200.
Adam: That’s a great test base of users. If they’re all working on different teams and all of those teams need to deploy applications, that definitely sounds like scratching your own itch. We’re told all the time that this is the right way to conceive of a startup, right? “Solve a problem that you have.”
With cloud.gov, 18F has really done that for yourselves. You mentioned you have users from other federal agencies coming onto the platform. Is there a roll-out plan beyond that? Should we be looking at using Cloud.gov for our federal clients?
Aidan: I didn’t really answer your question before about who the users are. It tends to be people who haven’t used these systems before, people that would not be familiar with this world, with some exceptions (people who happen to be hired in from other startups or places where they were using modern infrastructure tools). So, the more we can take care of for them, the better.
18F works [for and is paid] by agencies. There are some details here that I’m going to miss, but essentially, we can only take federal money or do work for federal agencies. However, there’s a loophole, a bureaucracy hack, where we’re able to do work with states on projects if the money comes from the federal government. In this case, [the US Department of] Health and Human Services is paying for child welfare programs in different states, and because they’re the ones paying us, we’re able to work with states directly.
I can see something like that happening for cloud.gov. This is a lot of the work actually. Our assumption is that we can’t use it with cities and states, but [there may be] some legitimate loophole so that we can do it without breaking any laws. We’re constantly investigating who can use this outside of federal agencies because there certainly is interest.
Adam: It’s great that there’s interest because there’s definitely a big need in local government. There’s a lot of city websites and city-run services running from decades-old mainframes that are sitting in the basement of City Hall somewhere. Cloud.gov would be multiple levels of improvement and benefits. Hopefully you’ll find one of those bureaucracy hacks or loopholes because that would be really awesome.
You mentioned earlier that you’ve been working on the compliance angle for cloud.gov, specifically the FedRAMP authorization. Do you want to talk about what that is? I saw in a blog post cloud.gov is now considered “FedRAMP-ready.” What’s FedRAMP? What’s FedRAMP-ready?
Aidan: In the federal government, IT compliance is really all about security. It’s all about [asking], “Have you done all these things? Have you thought through all these things that would make your application secure?” The [efficacy] is debatable, but that’s the idea of IT compliance.
Most IT compliance happens in a specific agency, so an agency will decide all the requirements for authorizing a system to operate. FedRAMP is an attempt to centralize that by offering a peer-reviewed process for getting software, like cloud services, offered to all federal agencies. For example, Amazon Web Services is approved through the FedRAMP process, meaning that Chief Information Officers from several agencies came together and looked at all of their compliance documentation. (This is a mountain of paperwork that says, “Our system is secure in this area because of this and in this other area because of this, and we’re thinking through our password retention policies, and we’re thinking through contingency planning if our generator goes down or something like that.”)
After, it’s reviewed by the Joint Authorization Board, other agencies can agree that they’ve done their due diligence that the system is safe. That makes it a lot easier for cloud service to be used across agencies.
Adam: In the past, this would be done one time for each agency (of hundreds). Now, it’s centralized into the FedRAMP process so that once it’s done, any agency can access the service?
Aidan: Yeah. Again, this isn’t mandated, in the sense that anyone has to respect the FedRAMP-approved systems. There’s still a ton of systems that get approved agency by agency. FedRAMP is a centralized offering, and cloud.gov is on its way through that [process].
Adam: [So you’re saying that] your paperwork mountain is getting there, but it’s not quite as high as it will be eventually?
Aidan: Yeah, we’re probably in the five- or six-hundred page range, so that’s the amount of effort that goes into proving that your system is secure in the eyes of compliance experts.
Adam: Wow! Five- or six-hundred pages and that’s still not quite FedRAMP-ready?
Aidan: Exactly.
Adam: Let me contrast that with something else that I’ve constantly heard from folks in the federal government, which is that they want new, innovative companies to engage with the federal contracting process. We’ve also seen initiatives like Apps.gov, which is trying to push agencies to leverage pre-built Software as a Service (SaaS) platforms before building a platform or solution themselves. If you go through that list of SaaS applications on Apps.gov, none of them have FedRAMP authorization.
I can tell you, we as a company can put together a bit of documentation, but I don’t think we have the capacity to do a five- or six-hundred page mountain of documentation. What’s the path for smaller companies that want to serve federal agencies, and how can companies like us provide that level of compliance while we’re at an earlier stage?
Aidan: This is something else I’m working on outside of the cloud.gov work. FedRAMP, thus far, has been really focused on infrastructure providers like AWS, Azure, Salesforce, the really big SaaS systems. The smaller pieces of software, project management software, your chat software and things like that—
Adam: I hear that Screendoor is a pretty good form-building software-
Aidan: Screendoor, exactly.
Adam: … although I certainly wouldn’t want to endorse it on this podcast, but I hear that the guy who codes it is really a fantastic developer, a fantastic podcast host…
Aidan: And, extremely good-looking.
Yeah, so FedRAMP hasn’t really been designed for that because it’s not tenable for a small company. That’s something I’m actively working on; we’re trying to make a low impact SaaS process in FedRAMP. Low impact meaning that if the data were to be made public (if not made public already), if it were to get hacked, if it were to go down for a few days or something like that, it would not be the end of the world. Project management is a really good example here. It would be inconvenient if all of our project management tasks and things got deleted, but it wouldn’t be a catastrophe.
Compliance works in these buckets of “confidentiality,” “integrity,” and “availability.” Confidentiality asks what would happen if the public saw this information or if a malicious person saw this information. If [the information is already] in public, there’s no confidentiality concern. Integrity asks what would happen if it got tweaked, if it got changed, if it got hacked into and manipulated. For something like project management, it would be confusing, but it would not grind us to a complete halt. Project management software [wouldn’t generally pose] a very high integrity concern. Availability asks, “If it went down for a couple days, would that bring the entire agency to a halt? [For project management software,] no.
There’s a span of software and really useful tools that aren’t processing your health records or aren’t collecting social security numbers. They can go through a much more streamlined process to get approved, and FedRAMP is trying to offer this. Hopefully, we make room for SaaS [software] that has more security needs by asking how we can streamline that process and tailor it to how sensitive the data is.
Adam: Cool, I’ll be sitting here tapping my watch, waiting on that new process.
You mentioned that part of that streamlined process is only going to be available for those software applications that don’t have a really high score on that matrix of confidentiality, integrity, and availability. How are those calculated?
Aidan: I believe that table was called FIPS 199, [which shows] those three categories and then a low-moderate-high [score] for each one. There’s descriptions there of low confidentiality (it would be a little bit embarrassing or an inconvenience if this became public), moderate (it would be a real problem, and we need to do things to mitigate it), and high (it would bring our agency to its knees basically and cease all operations).
Adam: My favorite explanation of that confidentiality question is, “How embarrassing would this be to our agency if this data got out?”
One of the things that I appreciate about 18F is that you guys have published your assessment of what information is considered personally identifiable. That’s one 18F guide that I’ve pointed a lot of federal clients to before, and I think they find that really helpful. Working in the open has all of these side benefits. It’s nice that 18F is documenting it as you go along.
Aidan: Again, these things are laid out, [and there’s] a lot of regulation around that, but it’s hard to read for someone who’s not a lawyer.
Adam: I’m not able to read NIST documentation. It takes me hours to read each page. Having that translated for me is really useful in my day-to-day.
Aidan: That’s a lot of my work. How do we break down these really large, complicated processes and rules into actionable checklists and, ideally, even automated checks, [so that it’s] less of a burden for our teams, [while still maintaining] the same level of security and compliance?
Adam: We talked about state and local governments leveraging cloud.gov in the hypothetical future. What about FedRAMP? If you’re in local government, even if you’re using cloud.gov and cloud.gov has this FedRAMP authorization, FedRAMP’s not going to be [part of that process]. Any recommendations to state and local governments or a compliance framework for them? What would the focus be on?
Aidan: It’s really up to the state and local government. [If something specific isn’t] mandated by the state, they can say, “We’re going to go buy FedRAMP.” They may not have input to FedRAMP in an official way, but agencies can essentially decide what it means for something to be compliant.
The National Institute of Standards and Technology (NIST) publishes guidelines and frameworks for how to think about these things, but it’s up to the agencies to interpret those and decide what those rules actually mean for them, in their agency. State and local governments could say, “Anything that’s FedRAMP-ready is fine with us.”
Adam: I think that’d be really interesting, as FedRAMP gains popularity and [as] we have more SaaS companies go through this lightweight ATO process that you mentioned. It seems like it’s a no-brainer for other levels of government to start using FedRAMP if it’s already in use and already led to the authorization of all of these platforms for the federal government.
Aidan: At the very least, the documentation that a service would produce for a program like FedRAMP would make going through any state and local compliance processes easier. The structure would be very specific to FedRAMP or to whatever ATO process you’re going through.
Working with these compliance processes has made me respect them, and coming from the startup world, it’s easy to be cavalier about security, to be quite honest. [To say,] “I want to deploy to this service, I want to try it out,” and just do it. You are held accountable [only] by the money that customers are paying you.
In government, you don’t have that because your customers, the taxpayers, have to pay you. Accountability mechanisms are important to ensure that people in government are thinking really carefully about security. The mentality and the place that these [regulations] come from are very valid and, I think, probably something the commercial sector could learn from. [Though] they’re really overbearing at the moment, I think everyone would agree.
Adam: Speaking as a victim of the OPM hack of 2014, I certainly appreciate your dedication to this cause. Before we go, let’s switch topics one last time.
You’ve been at 18F for a couple of years now, and I know that the terms there are limited. Technically it’s a two-year term, that then gets extended up to four years.
How does it feel knowing that your time there is limited, and how does that affect the culture of the organization?
Aidan: Hiring in federal government, like basically everything, is very slow. It can take nine to 12 months to get hired for a position. That doesn’t even count all the time that goes into getting the position made available, which is probably another six months. This can be an enormous process to get one person in the door.
One of the key things that 18F figured out early was that we can use special hiring authorities, special methods of hiring people to get people in the door faster. This is not specific to 18F—it’s available in other parts of government—but it’s unusual for everyone in a team to be hired this way.
With these term limits of two years, renewable to four, we’re able to get people in the door in two to three months instead of nine to 12. Other people in government might scoff at not being allowed to stay forever, but that means the government isn’t committing money indefinitely to hiring someone, which makes the hiring a lot simpler and faster. That also really works for people coming from the technology industry, where I know very few people under 35 that have stayed at any job for more than four years.
Adam: I’m coming up on my fourth year here at DOBT, so you basically just called me a 35-year-old.
Aidan: [Laughs] Exactly. People don’t have lifelong careers in one agency or department [anymore]. It’s just decreasingly common. I don’t think it’s been a big drawback for us, and honestly, knowing that everyone is somewhat temporary makes us really good about documenting. Anything we figure out, we need to document, talk about in a blog post, get in front of people on podcasts, [or] write guides, so that if I’m not around, someone else can learn from that.
Adam: So, ten years in the future someone’s going to be listening to this podcast, trying to figure out the origins of cloud.gov and how it became a focused solution for SaaS companies to deploy their apps to local government, and they’re going to go, “Hey, it’s Aidan on that podcast, on the DOBT podcast.”
Aidan: Exactly. Knowledge permanence is something that doesn’t happen in a lot of places. Expertise gets tied to individuals, but if you can get things out of people’s heads and into documentation, that means that the next person can learn if that first person isn’t around anymore.
Adam: Another thing that contributes to that culture is having the remote team, which I think has got to be a topic for another podcast because we could go on about that for a while. Even if I am here for another four years, I’m not always around to answer those questions, and having that documentation there is really really important.
Aidan: Yeah, [documentation] can support a team working asynchronously. Ideas aren’t just locked up in my head, and I don’t need to be available on chat or video to answer questions. You go and find [that information in an] intuitive place ideally.
Adam: What do you think you’re going to do after 18F? You’ve got two years under your belt already. Are you going to dance full time, or find something more similar to what you’re doing now?
Aidan: Yeah, I don’t know if we’ve mentioned that my other life as a dancer yet.
I really liked working for government. It’s been really reassuring. Everyone’s there to do a good job, people outside of 18F included. People really want this change to happen. [They’re starting to ask,] “Does it have to be this way?” and “Are we doing this because it’s the way we’ve always done it, or are we doing this because that’s actually the law?” If you’re an audacious person who doesn’t mind sticking your neck out a little bit, I think you can create some really big change. Teams like 18F are popping up all over the place.
If [I don’t stay] in the federal government doing open source advocacy, something I’m really passionate about, maybe [I’ll start] another team like 18F in city or state government. Something like that could be really interesting.
Adam: That seems great. We’ve seen a lot of state and city innovation teams pop up. I know there’s a great one in New York City, where you’re based, and hopefully, we’ll have one here in Oakland, California before too long. (I want to get that request on the record.)
Let’s go back to that dance thing really quickly. You mentioned (or I mentioned, and you confirmed) that your other life is as a dancer. Are you the only software developer/dancer out there?
Aidan: It’s pretty rare, but because it’s so rare, I feel like I always hear about the people who are also doing it. Someone will say, “Wow! I met someone else that does this.” It’s really not very common.
There are some cool people doing arts and technology things, but I keep them pretty separate. I wouldn’t say it’s intentional; it’s just the way things have shaken out. But having 18F and GSA, to their credit, are very flexible about hours, so I’m able to maintain outside hobbies and side-careers.
Adam: I promise this isn’t just a giant advertisement for 18F, but 100% open source, flexible work hours, you can go dance and have other hobbies outside of work…. That’s a really a great contrast to what I see here in Silicon Valley and elsewhere, where they’re driving themselves to the points of exhaustion with work. And all of it’s proprietary, of course. It sounds like there’s a really great mission there and a great team that you have supporting it.
Aidan: It’ll take a whole other podcast to [talk about] things that we’re not doing well; I think that would be actually a really important story to tell.
Adam: Well, we’ll ask for the press authorization for that now.
Aidan: Sounds good.
Adam: Anything else you want to add before we take off? Maybe any way that our listeners should get involved? Obviously I don’t need to give the URL for cloud.gov, but [are there] any other resources that they should check out?
Aidan: Yeah, if you want to learn more about how all this compliance stuff works, I gave an internal talk that we ended up publishing, and there’s a whole site, a guide, for people on our team that I can put in the show notes. I’ll also provide my email address for people to reach out.
Adam: Great. Aidan, thank you so much for coming on the Rewiring Government Podcast. It’s been a pleasure to catch up with you.
Aidan: Thank you, Adam. Likewise.