Transitioning from private to public sector:
Lessons learned from those who experienced it
Who can afford to move fast and break things in democracy? No one. You’re here to move carefully and fix things.
Takeaways:
- Government has different structures, incentives, and culture from the private sector that are not evident to people newly entering government.
- People who have made the transition from private to public sector said it took 6 months to 2 years to learn the ropes and feel effective.
- Lessons learned by our interviewees should feed into preparing people transitioning into government through training, orientation, or other resources.
The U.S. federal government employs millions of people. By some counts, at least a third of the federal workforce is at or near retirement age. In addition, there has been mass attrition over the last several years in key agencies. This trend coincides with Millennial and GenX — and the generations after them — being frustrated with the way things are and wanting to make change in the world. What better mechanism than to do public service?
In the spring of 2020, we conducted a series of interviews to learn what it was like for people new to government work to start their positions and be effective in those new jobs. We used the data from these interviews to inform our design decisions for what ultimately became the Tech Executive Leadership Initiative (TELI).
We heard across the interviews that working in government is really different from working in the private sector. We heard that building trusted relationships and clear, open, continuous communication were the most important tools for getting things done. And that, while tech in government is often old, it is not the biggest problem to be solved in delivering services to the public.
Discovery research:
Interviews with former federal government employees
Let’s say you’re working in tech in a bank or insurance company — or even a tech company. Let’s also say that you are mission driven, see that public services could be better, and are ready to step up to help fix things.
Now imagine you get placed in your dream government job. You might be making it easier for people to get benefits, or advising on national security, or helping people become citizens. Or running an innovation lab in state government. Or being CIO for a large city.
How different could working in government be? What challenges are you likely to encounter in moving from private sector tech to public sector tech?
In March 2020, Project Redesign conducted interviews with people who had made the transition from tech in the private sector to leadership positions in the federal government.
Our interviews showed that the shared experience of people entering government from the private sector was one in which newcomers took months or years to learn what they needed to be effective in improving public services.
Our research question centered on whether it would be possible to help technologists who wanted to enter government prepare to work with their new partners, teammates, and vendors to be more effective, sooner than previous entrants.
Participant characteristics
We interviewed people who had transitioned from private to public between 2012 and 2016. One was a national security advisor. One went into leadership in an international development agency. Another was slated to be a CIO in a federal agency. So, not necessarily technologists, but definitely highly technically skilled, successful and notable in their respective fields, and sought out for their skills, knowledge, and experience. These were some high-powered experts. They were adept at learning new domains, interacting with executives, and navigating power structures. They had not worked in public service before their first assignments in the federal government.
Method and questions
Over the course of a few weeks in March, 2020, the Project Redesign team interviewed people over Zoom about their early experiences in their then new government roles.
We asked interviewees (interview guide) what they wished they’d known before they started their public service — what advice they would give their past selves and future new public servants. But we also asked them about specific important experiences they had in their tenure.
Results
Interviewees told us that significant achievements took years, but small wins in the short term showed progress
There were certainly things that our interviewees were proud of, but every person told us that accomplishments happened long after 6 months. In one case, our interviewee told us that the significant wins happened after they left — but that they were happy to have been a part of making progress possible.
Everyone acknowledged that they went into government to improve government services quickly, hoping and expecting to implement change at the speed of Silicon Valley. But the overriding observation from all was that change happens slowly, in small increments. Often for good reasons. When interviewees realized this, they shifted their thinking and their strategy.
In some cases, the significant achievements — the things our interviewees were proud of — were either quite small or not visible to the public. Often, the achievements were in the service of setting up a larger program for long term progress. Interviewees had made stepwise improvements, or established infrastructure or frameworks for the next person or a government partner to move the project forward. As others have described, the work is much more like a relay than a sprint or a marathon.
The reason government is powerful, the reason to go work for government is to change things. You can’t do it in 2 years. …
There was a seed planted and it was growing.- agency head
The culture of government is foreign territory for private sector technologists. You can’t be a tourist in government and be effective.
Some interviewees had time to prepare for their new government assignments. Some didn’t know what they would be doing until after they arrived. For those who could get ready, the homework focused on learning about a policy domain or getting background on a specific tech or policy problem. You might get some passive learning about vocabulary and laws, but there was apparently no truly effective way to get ready for how government addresses problem-solving.
This is where culture comes in. You can learn about organizational structure through org charts. You can learn about processes and procedures through documentation. But understanding how those elements (and more) interact and play out every day in government was a far bigger challenge. Our interviewees told us that they believed there was no way to study for that ahead of time.
You can learn about organizational structure through org charts. You can learn about processes and procedures through documentation. But understanding how those elements (and more) interact and play out every day in government is a far bigger challenge.
Learning government culture was a deep dive that took commitment, and in some cases, help from a person who acted as a guide. Interviewees talked about how someone they met when they first arrived helped them be successful by guiding them through what was happening, who was who, and what the words and behaviors meant.
For example, one interviewee told us about the first meetings she was involved with about problems she might be pulled in to help solve. The vocabulary wasn’t the same, even though she came in as an expert in her field. The expectations were different from what she was used to. She hadn’t been given any background on who was who in the room and what her role was. Afterward, people who she met on her first day helped her interpret what she was hearing and seeing. They translated and drew parallels where they could from government priorities and ways of working to what happens in the private sector.
Another interviewee told us that, while she was a renowned expert in her field, when she arrived for the work she’d been invited to do by a high ranking government official, she had a hard time breaking into a group of federal experts who clearly knew one another well. There was a lot of trust among them, already, and a shared understanding of the landscape that she didn’t have. One of the trusted group members observed this gap and took it on to “sponsor” her to the group. Before and after meetings with the group, her guide worked with her to brief her on what was happening and what the history was. Having the guide was invaluable, our interviewee told us, because her guide was willing to lend their credibility to her to gain the trust of the incumbent group.
The language was different in this new territory, and interviewees had to learn a new vocabulary to be effective
“RFI” is a request for information, but an RFI is at the beginning of a procurement, often to learn which vendors might be interested in bidding on a contract. Contracts are “vehicles.” Technology must be approved and given “Authority To Operate” before it can be deployed. The names of laws and regulations are all shortened to collections of capital letters that don’t convey meanings: FISMA, FITARA, TECHFAR. And government loves its “cyber,” which translates roughly to “information security.”
Every policy domain has its own language (is LEO “law enforcement officer” or “local election official”?), and there are sometimes local dialects of tech terms that evolve within agencies.
Likewise, some tech terminology is very new to government: API, CI/CD pipeline, devops, user-centered design. Concepts like product management and service delivery are also new to most government partners.
Risk has a different meaning in government from private sector, especially in tech
Interviewees found that their new government co-workers operated in a culture and compliance bureaucracy that left little room for experimentation.
On technology implementation projects, interviewees encountered what, at first, felt like massive and unnecessary roadblocks to modernization. Interviewees told us that, as time went on, they started to understand that many of the obstacles were well intentioned. Hurdles, such as extensive requirements gathering and onerous procurement procedures, had emerged over time to spend taxpayer money appropriately, ensure ethical standards and fair practices, and implement secure systems.
Incentives and compliance concerns in private sector companies revolve much more around developing value for shareholders and meeting minimum regulatory requirements. Interviewees found themselves reorienting their thinking around risk mitigation.
Navigating new kinds of explicit and implicit power structures was challenging
Learning a given org chart to understand chain of command and hierarchy was important to interviewees. Of course, the hierarchy reveals who in leadership makes what kinds of decisions, but it also shows the priorities of the organization. This was relatively straightforward.
However, like every organization, there’s a shadow power structure in addition to the explicit hierarchy that can hold sway on what moves forward and what gets blocked. The concept was familiar, but learning who had this soft power and how they used it was challenging. As a newcomer to an agency, you might encounter passive resistance or a “slow walk” from peers and partners who were concerned with protecting territory or simply didn’t trust the new person brought in to solve a particular problem.
Change happens through influence and that works through building trust
The Project Redesign partners had observed this ourselves in our own, similar transition, and we heard it loud and clear from interviewees, too: effecting change in government organizations took time, in no small part, because it takes time to build rapport, relationships, and trust. “Influence” feels like a dirty word in American English, but influence and persuasion are powerful tools. As interviewees told us, the small wins adding up to larger changes in culture and service delivery often came down to persuading people in government agencies that the risk is low and the outcomes will be good. Developing trust among peers, teams, and partners helped move projects faster. As one interviewee concluded, “The people part is important.”
While they wished they had time to get to know the territory, there was work to be done at the same time. This dynamic made it tough to do both and map what they were learning. How much of what they were experiencing was this project or this part of government, and how much of it was Government?
“If this fails, it’s not going to be for technical reasons. It’s going to be because there isn’t trust.”
- lead software engineer
It is easy to take on too much because there are so many problems to solve and processes stretch out over time
After you’re inside a government agency, it’s easy to become overwhelmed with all the possible things there are to work on. As one interviewee told us, “there’s always too much to do, so I couldn’t always provide leadership, strategy, and direction. I could only be reactive” a lot of the time.
In government leadership roles, interviewees told us, there is always too much to do, and the stakes always seem high for the public you are serving. You’ll need to delegate decisions downward as much as possible, which means you need a great team that is highly skilled and self-directed. Develop trust and respect in the team, and help your team use their time well.
Executive and leadership support and cover are important for success, but relationships at the worker level is how things got done
Getting into the room can be hard if you’re seen as an outsider or someone who wants to shake things up. The power centers don’t always show up in the org chart. The people who hold power might not even appear in the org chart. So much of what gets done is through persuasion and gentle influence. As interviewees told us, building relationships in your direct team was important, but also reaching out to folks further out in the organization makes a huge difference for getting support for your agenda. Developing those relationships will help you cultivate trust and respect more widely, and it will be easier for you to get things done.
Lessons learned
Among the questions we asked interviewees was one around what they might advise newcomers, given the experience they had. Usually, the question was something like:
If you were giving people coming into government from the private sector advice about getting things done in government, what are the 3 big things you’d tell them about? Let’s start with your biggest takeaway from your time — what was that?
Rolling up the results to actionable guidance, here’s what we heard from our interviewees:
Dig in to learning the laws and policies you’re implementing
- Dig into the policy domain you’re working in, even if you’re not a policy person. If you’re a software developer, policy is business rules. If you’re a designer, policy is a brief. If you’re a data scientist, policy is your strategy. Learn the language. Be patient. It’s going to take awhile.
- Learn the policy priorities of the leadership in the agency and align your priorities with those. Only go where you’re wanted, and don’t go alone. Learn about the agency and department budgets.
[You will be] faced with scenarios where you have assumptions that you realize are not shared. And you don’t realize that it was just an assumption on your part until something happens to dispel that assumption.
- senior technologist
You are here to make friends
- Getting things done is all about building trust and relationships. Knowing who has official and unofficial power is crucial to getting support for your agenda. Find someone with power and social capital to connect with and who will vouch for your expertise and skill.
- Pre-wire decisions through individual conversations and using the relationships you’ve built to exert soft power and influence (see vouching, above).
- Learning how to surface information is a skill. Be crisp, clear, and concise in your writing.
- Learn, respect, and use the hierarchy. Government organizations have a clear chain of command. You’ll need to know who your peer-level counterpart is and who is above you and below you in the chain to get meetings, hold effective conversations, and get decisions made.
- Your position in the hierarchy conveys authority on you. If you’re in a leadership position, be clear about what is brainstorming and what you want action on. People will take your word as a command.
Don’t underestimate how important it is to meet with real human beings. You have to get to know people to get them to trust you and understand what you’re talking about.
- lead software engineer
Urgency, good. Rushing, bad.
- Be humble and curious. Take the time to learn what’s going on, how things work, and what has been tried before. Invite people to coffee.
- Don’t rush it. Don’t expect to transform an organization in a short tour of duty. Government operates slowly for good reasons. “Fail fast” is irresponsible in this environment. You’re there to move carefully and fix things.
- Pick a doable thing out of a larger problem that you can clearly define.
There are demonstration things that you do that are tangible. I tried to be more data and evidence driven, adaptive, and nimble, implementing feedback loops.
- agency head
Treat your first year like a research project
- You’re going to be uncomfortable a lot. It might be because you’re in a new situation, or because the situation is ambiguous, or because you’re frustrated or stuck. It might also be because you’re on a project with an urgent mission and high stakes. Sit with it. Look at where the discomfort or frustration are coming from. If you’re frustrated, it’s likely that your government partners are, too.
- So much is not written down. Unwritten rules, norms, and expectations are part of the character of the culture of the organization you’re in. For example, protocol at the Department of State might be different from Health and Human Services. Observe the culture and work within it.
You have to believe that continuing work would mean small changes over time. Pick a thing that will make a dent in that big problem. Break it into the steps. Work on the first one. If you get the first one done, people will believe in you and users will immediately benefit rather than waiting for 10 years. Users will feel it. Your collaborators will see it.
- lead software engineer
Effective collaboration in cross-functional teams doesn’t need fancy tech
- Tech is almost never the solution to a problem. Having a shiny app doesn’t solve the problem of backlogs in processing applications for benefits. Chatbots don’t remove the needs of the public to ask questions about their specific situations.
- The tech tools you’ll have available for collaborating are usually basic. MS Word and email are the collaboration tools of choice.
- Cross-functional and cross-agency teams can be challenging to pull together but are effective. When you can pull together cross-functional, cross-agency teams, everything goes a bit faster and easier because everyone on the team shares an understanding of the goals, the needs of the different functions, and the intentions for serving the public. You might have to call it a “working group” or a “task force.”
Take care of yourself to make sure you bring your best self to work.
- The stakes are high and the urgency is great — but you’re no good to anyone burned out.
- Take care of yourself. Try not to internalize too much, even though the work is hard and the stakes are high.
