Started in the Private Sector, Now We’re Here: Making the Transition to Government
By: Caroline Smith
Tags: Design, Product, Strategy, Civictech

For those who might not know, I began working for the U.S. government last year! I joined the U.S. Digital Service in the fall as a Design Strategist and was assigned to the Centers for Medicare and Medicaid. Although I had prior health care experience having worked for clients like Eli Lilly and Merck, my Big Pharma subject matter expertise was largely useless. CMS is the largest insurer in the country and I had never touched that topic before. What did end up being highly transferable was my experience in working with difficult stakeholders in siloed, legacy organizations with myriad constraints and layers of bureaucracy.

But I’m getting ahead of myself.

I wanted this post to serve as a letter of advice to anyone considering making the transition from the private to public sector in a Product, Design or Technical capacity. While there is a lot of writing that exists on why government is different than the private sector, it can be hard to find information that adequately captures the nuances of how and why it might be different to be a Product Manager or an Engineer at a government agency versus a Fortune 500 company.

Since I’m a fan of using design frameworks to help me tell stories, I’m going to IDEO’s “Three Lenses of Innovation” to compare and contrast the differences I’ve seen so far.

The Desirability, Feasibility, Viability framework is often used in business to help inform strategy. In summary, you need to create something that is Desirable (people want it), Feasible (you can do it) and Viable (you can afford it). Each lens allows a business or organization to assess current product and service performance and what can be improved.

Now hold on, you might be thinking, doesn’t the government care about people’s needs (Desirability), how to deliver products and programs (Feasibility) and budget (Viability) as well? Absolutely. So let’s dive into the similarities and differences and how the work is impacted.

Desirability

In both the private and public sector, organizations strive to solve the needs or pain points of their users. But purpose and scope differ significantly, mainly due to one key difference — the private sector is motivated to make money, whereas the public sector is driven to improve society.

In the private sector, businesses are user-centric in order to deliver products and services people will buy in order to increase the bottom line. Thus companies are often incentivized to build for a specific target audience in order to gain customer loyalty and increase customer lifetime value. Diversifying the target audience is considered only after initial success.

In the public sector, the government is user-centric by mission and by mandate. It’s not possible to produce a product for a select few and exclude users who might not speak English or have a physical impairment. Legally, the government must be inclusive and avoid discrimination when building products and services.

This has enormous implications on the work a Product Manager or Designer might have to do in order to produce what qualifies as a minimum viable product (MVP) in government. Firstly, requirements gathering can be much more robust as it must involve more stakeholders and adhere to rules and regulations. You must also consider how the product or service fits within a larger ecosystem of processes and tools. Thus, it’s crucial to think creatively around how to scope an MVP.

All of this adds up to a much longer timeframe than you might be familiar with in the private sector and requires patience and empathy in order to achieve success.

Feasibility

Depending on your particular private sector experience, the operational capabilities in government might feel very different, or strangely similar.

If you’re coming from a startup or small company that had a small workforce and flat hierarchy, your working style and tasks may have been very integrated, Agile and informal.

If you’re coming from a legacy company with a large, hierarchical workforce (like I have) the culture and working style often found in government may feel very familiar — Waterfall, siloed and very formal.

Government is very hierarchical, siloed and risk-averse which often results in people getting ‘lost’ in the system, having limited autonomy, and lacking the incentives to fail fast and learn. Many people, including government contractors, don’t feel authorized or incentivized to do something if it’s outside of their normal ways of working or contract. All this results in a meeting-heavy culture, lengthy approval processes, and a bias toward inaction, which in turn impacts project timelines and the scope of what you can do.

For example, in order for any technical solution to run in production, government must obtain an Authority to Operate (ATO) — a compliance-heavy document that aims to address security concerns. This extensive approval process must involve an independent audit group to perform a host of assessments including interviews, pen tests, and document reviews to ensure the correct security risk posture is in place. Although there may be similar security processes at private sector companies, it might be fully internal, where the company is approving itself to release a product that it developed to production. Unsurprisingly, the ATO process takes time and impacts A) the technical solution you pursue and b) your timeline to launch.

Additionally, many of the stakeholders you will meet will be career feds — meaning they have put in 10, 20, 30 years. This can have implications on their skill sets, mindsets and appetite for change. Thus it’s crucial to find and cultivate allies who are willing to go against the grain and push for change (aka stakeholder management 101).

Finally, depending on the government agency, headcount allotment will either result in a large Federal workforce or a large contractor workforce. If you come into an agency where the workforce is predominantly contractors and you want to build products or services that the agency will need to own and manage after your departure, you may have a challenge finding dedicated resources that will (1) want to be accountable and are willing to move the project forward without you, and (2) possess the skill sets needed to take ownership.

That challenge has massive implications on the scope of what you can do, as the strategic question shifts from “Can we build it?” to “Can it be owned and maintained by the agency?” In this scenario, the impact of procuring good contractors can literally make or break your effort. Time spent selecting strong contractors — and empowering your government partners to select strong contractors — will be just as important as making technical decisions.

Viability

When it comes to viability, this is where the private and public sector differ the most. Even the very definition differs.

In the private sector, viability is defined and measured by “did it increase our bottom line and contribute to long-term growth?”

You might be thinking: But government doesn’t have to worry about profit. Nor does it have any market competition. There isn’t the typical incentive of ‘more users = more money’. So how is viability determined?

In the absence of measuring revenue, there are other important ways to measure value and determine viability in government. Here are a few to consider, in no particular order:

1. Lowering costs of call centers and help desks by lowering user complaints. 2. Lowering training dollars by making the system more intuitive and user-friendly.

3. Lowering the cost of compliance by assessing what’s actually needed. For example, typical Waterfall development contracts need independent verification and validation contractors. With modern development practices you won’t need them because testing is embedded into the process and verification is done continuously.

4. Lowering bug rates by using modern testing and development practises.

5. Decreasing risk and project delays by increasing the time to market so users can test and give feedback.

These measures can be reflected in contracts and used to track and evaluate the viability of the product. One of the most important and impactful parts of your job will be to successfully change people’s thinking about technology and operations, development versus sustainment, and real user value.

—

The last bit of wisdom I want to leave with you as you transition from the Private Sector into Government, is twofold:



1) Find a cultural interpreter to help you navigate the agency, chart your journey, build relationships, and gain context as soon as possible.

2) Embrace the high-level mission of the work, even though the products and programs may change with leadership. You might find yourself watching a program you worked hard on get replaced by a different activity or be implemented in a different way than you anticipated. Ensure that value is still being delivered to the people who need it, but recognize there are various ways value can be delivered. Have conviction in the purpose of the agency and government as a whole, and you will be set up for success.

Good luck, have fun and go forth and conquer!

***Special thanks to Joy Day, my cultural interpreter and friend at CMS. Your insights and contributions to this article were invaluable.***