Why It’s So Hard To Write Federal Technology Policy

Bill Hunt spent two years as the cloud policy lead at the Office of Management and Budget, working on the government’s most important IT management policies. Most notably, Hunt served as the lead on OMB’s update to the data center policy—now called the Data Center Optimization Initiative—and the administration’s Cloud Smart policy, which replaced previous guidance outlined in Cloud First.

Hunt left OMB on Sept. 13 and took a new role as chief enterprise architect for the Small Business Administration. As he transitions, Hunt spoke with Nextgov about his time at OMB, reports of dysfunction in the Office of the Federal Chief Information Officer and why it is so hard to write federal technology policies.

This interview has been edited for length and clarity.

Nextgov: To level-set for our readers, what does the role of “cloud policy lead” entail?

Hunt: At the end of the day, the cloud policy lead is just one of the program areas that we distilled down from the vast catalog of things that OFCIO does. Pragmatically, it was a role that oversees everything related to cloud, federal infrastructure, data centers—all of those responsibilities and policy areas we condensed down to a single role.

That was a natural evolution. Everyone there is a policy analyst of one sort or another. We all get assigned a portfolio based on our given skillset. My particular background—coming from the private sector, working many, many years with clouds and doing a lot of IT work—it was kind of a very natural fit for me taking over one of the more technical aspects of our portfolio.

We grew the responsibilities that I was taking on as opportunities presented themselves. I started with just the data center piece of the portfolio. And working with [then-acting Federal CIO] Margie Graves very closely there in the first days and then [current Federal CIO] Suzette Kent when she came on, we identified that there were more needs to fix the problems we were having with data center policy than just data centers themselves. We really needed to clear the slate with regard to a lot of the policy areas we were facing. That’s where you see what eventually became Cloud Smart.

Why is it so hard to write these policies? Why does it take so much time? For instance, the changes on Cloud Smart from draft to final were significant—such as the addition of application rationalization, but it didn’t take months to write that paragraph. The words in the document are not what takes time, so what is it that does?

There’s a lot of pieces that go into policy-making—there’s a lot of stages, there’s a lot of steps. Moreover, when you’re dealing with policy at the federal level, there’s a lot of large players, there’s a lot of major stakeholders who have a lot of vested interest in these things. It’s not as simple as having the Federal CIO write down what she believes is the best direction for America and just assuming everybody can then execute on that.

Instead, it’s a very difficult negotiating process to make sure that all the stakeholders involved are brought in to the direction and understand the vision. And moreover, that once you’ve gone through that extensive process of negotiating what’s important, what the priorities are, making sure everybody agrees with the language and how you go about saying it so that it can approach the widest audience in a coherent fashion.

There’s a little bit of trying to get everybody at the table; there’s a lot of getting everybody to agree that the direction is sound; there’s a whole lot of polishing that has to go on for any federal policy to make it into something that makes sense to the audience you’re trying to address. Which, uniquely, is not just the CIOs that we’re writing it for, it’s also the American people overall. We need to make sure that everyone understands the vision and the direction coherently for a document as large as the Cloud Smart policy or the Federal Data [Strategy] policy, things like that. It’s really important to make sure that all the audiences are being addressed, and that takes time.

I’ll also mention that, particularly with Cloud Smart, we had the lapse in appropriations in the middle of it, which, as we all know, can significantly impact timelines. Particularly when people are scrambling to do multiple jobs simultaneously to cover some of those gaps. [OMB Deputy Director for Management] Margaret Weichert was detailed over to [the Office of Personnel Management], and other people were also sharing multiple roles. All of those things have a direct impact on policymaking. When the government isn’t funded, frankly, it’s just hard to get things done and to get all of that buy-in that you need from all the component agencies.

There’s a lot of moving pieces that you have to manage and, obviously, not having everyone that you need able to report to work is one of the core things that can slow that down.

From start to finish, what is the process for developing a federal technology policy?

This is something that I’ve been thinking about for a while now. Anybody that’s starting this journey of thinking about federal policymaking—everybody tends to go to the [Eugene] Bardach “Eightfold Path” book.

For me, the experience of crafting IT policy isn’t that different from the normal journey that you go on when you’re doing any sort of agile software development practice. It’s really very similar. You start by sitting down with your stakeholders and finding out the problem you’re actually trying to solve. You go out, not just to the leadership of OMB, but you also start going to the practitioners. You start holding working group sessions. You do an introductory discovery sprint where you go out and find out what the needs and requirements are.

In my particular instance, that meant reading all the applicable laws—you know, reading [the Federal Information Technology Acquisition Reform Act], Clinger-Cohen, all the way down—and seeing what existing policy was already out there that we needed to address and resolve, things like the previous [data center optimization] memo, and so forth. Sitting down with all the people involved—so, leadership at OMB and the leadership of various agencies, sitting down with most of the CIOs across the cabinet level and CFO Act agencies and then start to drill down to the practitioners. In my case, I went out and toured a bunch of the data centers and talked to the people who ran the data centers. I talked to a bunch of the cloud practitioners. Then, started talking to the vendor community about the things that they were struggling with.

[I] started to just work up and down the food chain and try to really distill down the problem space. Just like you’d do in IT: You figure out who has the things and who has the problems and how can we solve the problems that these people have.

From there, you start trying to come up with areas that you can improve on. We really highlighted those three areas in Cloud Smart: security, procurement and workforce. Everything that we kept hearing over and over again could really be distilled down to those three areas. Obviously, aside from budget—which things like the [Technology Modernization Fund] and the working capital funds, we were already working on—but all those other areas could be distilled down easily.

From there, you start writing, you start workshopping. Similarly, as you do in IT, you do it iteratively, you do it as agile as you can. You go to your focus groups and your key partners and you say, “Is this about the shape of things? Does this look like a thing that will help you solve your problems? Have we forgotten a program area that you want us to include that you think would improve the situation?”

You polish it—you do the final steps to get it from an alpha into a beta that you can put out for people. And that’s when, of course, we have the public comment period.

After the beta period where we got all that feedback, we continued to refine. We didn’t start over with the whole process, but went back to the stakeholders, validated the concepts and ideas that we were working on. Then you take it back and actually put that out as your final policy.

When do you think the next cloud strategy should come out?

I don’t want to be overly prescriptive on that topic. Cloud isn’t a destination; cloud is really just one means of changing your IT positioning. At the end of the day, the nature of business is change. That’s what business is: it’s about change. IT is just the way that we manage that change. It’s how we introduce a process for managing change within a business environment. The mission of government will continue to be enhanced by whatever changes happen through technology or otherwise.

I’m not going to say even that there needs to be another cloud strategy in 10 years because cloud is going to be superseded by something else, inevitably. There’s always going to be a constant state of change. Cloud is just a convenient handle that we put on all these things that we’re doing around IT modernization end-to-end.

I’d say there’s always going to be a need for an overarching, large federal strategy that continues to drive the agenda on embracing change across the federal government—that’s something that the federal government struggles with because we have a different evaluation of risk than the private sector, so we’re more change-phobic than the private sector tends to be and we’re always going to need that initiative. But I won’t say that there’s necessarily going to be the need for a new federal cloud strategy to be refreshed in 10 years.

That being said, I believe that the agenda that we’ve set and started with the CIO Council actions, that needs to be refreshed. That is something where we’ll need to continue to find other items that we want to pursue and run down across the entire federal enterprise.

Are there ways that you have identified to shorten the process?

At the end of the day, policy, like everything else, is vying for people’s attention. If you’re asking people to help you work on a policy, that’s taking them away from doing their normal day to day job. You’re always just trying to compete with people who are just trying to achieve the mission while you’re simultaneously trying to settle a larger-scale vision for what you’re trying to improve.

Any time that I’m going to go out and talk to a data center practitioner about how their data center is run, that’s some time that they have to step away from their day to day job, so they can inform me about things I don’t know about. It’s going to be those bits of the process that are going to cause it to be slow.

Ways to shorten it, I’ve found, are primarily about making sure you have the buy-in early. The sooner that you can start educating your stakeholders about what you are trying to do and start really getting that buy-in the earliest that you can, it really speeds up the process downstream. You don’t want anybody blindsided by a policy change that you’re trying to propose.

And the flipside to the previous question: Should it speed up?

There’s always going to be people who want things to go faster. We all just want to get to the end and we all want to say that we’ve done the thing, we’ve launched the product, we have provided the service.

In some ways, I think it can be valuable to accelerate things when you need to respond to an immediate need. Especially in government, if there are immediate barriers that we want to put in place or remove from people’s way, I think that’s a good time to enhance our speed.

For instance, with the work that’s going on around artificial intelligence. There’s a big opportunity here to speed things up so that we can set guardrails on how the federal government will be using AI moving ahead because it’s going to have a dramatic impact on the American people, for good or for worse. Having those guardrails in place quicker makes a lot of sense.

Another thing that has had an effect on the process over the years: reports of dysfunction within the Office of the Federal CIO. How have those issues—and public reports of those issues—affected the process?

I don’t know if “dysfunction” is the appropriate term here, necessarily. There are a lot of challenges with running an extremely high-performing, functional office when you’re dealing with a topic that moves as quickly as IT. That is always a struggle. And it’s also a struggle to make sure that you consistently maintain a performance level when you also have to consider staffing continuously high-performing individuals with technical backgrounds. That is always going to be hard—it’s hard in the private sector, it’s hard in policy and it’s definitely one of the challenges that the Federal Chief Information Officer’s office definitely faces.

I will say that those struggles to maintain the appropriate staffing levels, making sure that the appropriate budget levels are being provided so that you can have the sort of staffing and support required to do that job, that’s always going to present problems. Making sure that you attract a diverse workforce of candidates that have the deep subject matter expertise, the policy expertise, that’s difficult. In the public sector, we call it looking for unicorns. This is a particular flavor of unicorn: to find somebody who can understand both technology and policy at a deeper level.  

I am glad to see that we’re seeing a lot of the same people staying within government. We’re seeing a lot of people who continue to find other, higher roles. But continuing to staff an organization like OFCIO, where the demands are so high, where the pressure is extremely high, and being able to find people who can navigate technology, policy and politics simultaneously, and do it with aplomb is a struggle.

With all that said, why are you leaving? Sounds like they would need you to stick around.

I’m proud of the work that I was able to achieve working for Suzette Kent and Margie Graves and the opportunities that I was given during my tenure there. I’d say that where I’ve left things is in a pretty good state. We achieved a lot of the goals that I set out to work with them on—to revise what we’re looking at as far as the governmentwide infrastructure policy. We’ve kind of set things in place.

Frankly, I came over to OFCIO two years ago after serving a tour with [the U.S. Digital Service] at the Department of Veterans Affairs and I just really like agency work. It’s great writing policy, and I feel very excited for the opportunity that I had to improve so much federal policy in so short a time. I really got to get my hands dirty on a lot of topic areas and really improve a lot of areas I thought were lacking. But I was eager to get back to the implementation. Having written so much policy, I wanted to see how it would actually play out and whether or not the things we had written were going to be as effective as we’d hoped.

I was immediately excited for an opportunity to come over and join the team at SBA and [CIO] Maria Roat and the fantastic team she’s been putting together over here to really implement the more aggressive parts of that agenda and really try out the things that we had only been talking about.

Policy is fine and dandy. It’s certainly useful to tell people how you think they should do the things. But unless you have the experience actually doing the things, it’s really hard to consistently create good policy. I had been away from an agency for two years, and even if I’m doing my stakeholder interviews, even if I’m talking to the vendor community, nothing is going to replace the hands-on experience you get being at the agency and seeing how it actually operates and translating that policy into real-world learnings.

What are you going to be doing at SBA?

I have been brought over as the chief enterprise architect. Enterprise architecture is a discipline that has been around for many years and I’ve spent the last two years working pretty closely at OFCIO with the previous federal chief enterprise architect for the United States, Scott Bernard, and learned a lot from him about the overall practice.

I’ve also spent a lot of time in the technology community over the years looking at the modern evolution of how we’re doing management of the IT portfolio. I’m really eager to see what we can do bringing a more customer-focused lens to the overall management of IT. I’m really interested in bringing customer experience, the practices we’ve been developing around CX—both by the amazing [cross-agency priority] goal team but also what we’re seeing in the private sector—to the overall portfolio management of enterprise IT.

Do you expect that you’ll ever go back to OMB or to policy writing in any way?

I don’t know. Frankly, I would love the opportunity if it presented itself to go back and to get the opportunity to continue to improve federal policy at that level. I thoroughly loved the experience and loved the collaboration, the community building that comes along with it. I found it to be one of the most exciting and interesting jobs I’ve ever had. I would be eager to pursue that in the future.

But, that comes with a caveat that I think you have to have that constant rotation. People malign the revolving door pretty often. But I think that the only way you get the necessary experience to write policy that’s going to impact the entire federal government is by having a combination of policy experience, private sector experience and public sector experience. If you’re not constantly evolving your skillset and growing, it’s impossible to write good policy.