Life (and Tech) After Government

During my career, I’ve worked for or in the Federal government several times, nearly in every way you could – a contractor, as an FFRDC staff, and two tours as a Federal employee – and in as many agencies and branches of the government as well. This would total more than a decade if you counted it up (nearly half of my professional career!). However 2020 finds me back outside the government, observing the difference of technology adoption, use and implementation between public sector and the private sector; and sadly, as much as we’ve progressed in adopting forward leaning technologies in government, my exit from there and entry to the private sector opened my eyes that there’s a lot more catch up on what needs to happen.

I have to say I’m proud of where I’ve seen the government technology landscape from 2006, when I first dipped my toe in, and where I observed where I left off at the end of 2019, exiting as a Chief Technology Officer for one of the bleeding edge agency components. It’s monumental to overcome that level of inertia I observed in Federal service, knowing the tendency for large entities to remain at rest until some major event spurs movement off their laurels. To attempt to be apolitical with this, I would have to say that each administration has their own effect on movement such as this, in various levels of magnitudes, and some administrations have a tendency to push things further and faster than others, which is reflective of who they manage to attract to staff agencies and leadership as well as the policies they look to enact. I felt lucky to work across three administrations to at least have a little perspective on these rather stark differences. To that end, change is good, but in order to be effective it requires focus, momentum, and will.

Conversely, the private sector, given my experience and roles, is driven by different motivations, by in part, and complexities of competition and innovation. The need to adopt and adapt is often market driven, and risk, for those who walk along the bleeding edge, pushes the edge of risk into edge of the taste buds, sweet enough to relish the advances, but can easily sour when some tech fails spectacularly. This is gambling somewhat, and those high rolling tech companies, and even some forward leaning traditional companies, who take those risks and make them pay off reap a lot of tangible and intangible rewards.

To the tangibles, there’s obviously a revenue component, being able to possibly operate at speed, cheaper than working with legacy or monolithic tech, booking those savings back to shareholders or being able to offer better perks to employees. Intangibles are the brand recognition and attraction of customers, investors, and other resources who want to ride the wave along with you. 

This is slightly harder for public sector entities, as their relationship intangibles drive more to the missions of those organizations, including a sense of trust and reliability. There’s no “return on investment” for many public sector groups, as they are often supported by tax dollars, bonds and other legal means, and metric for performance and outcomes aren’t as stringently applied as they would with a team of owners, shareholders or investors in the private sector. Since the motivators are different, equating the taste for risk versus reward is dangerous and misguided at best, whereas the investment in the public sector has an expected outcome such as the public good, such as transportation, education, law enforcement, public health, and other such critical services.

As for the desires for keeping up with private sector advancement, such as technology adoption and use, is bounded by priorities and mission needs. Unless the use of a certain technology has a benefit to support core public goods, without degrading current service and capabilities, then they are evaluated, developed and deployed. But, because such resources are usually the last allocated from a particular allocation, unless strictly defined through a budget, adoption and implementation is staged, often piecemeal, in order to conform to funding and timelines. To that end, these organizations have to, by nature, select what they will do with what, very carefully, because a mistake will have implications well beyond the moment from whence it was made. Compound that with buying in volume, and those buffers in the coffers are much smaller. Conversely, many public sector organizations have procurement (purchasing) regulations that often make products and services more costly than an average citizen off the street can acquire on their own, in the effort to be fair in how it is evaluated and purchased. 

Just scratching the surface here, you can start to see the complexities to the answer of your peers asking you in the private sector, when you are a public sector employee: “Hey, why aren’t you using X? It’s cool, it’s modern, and…”

The Federal government is extremely proud that they have adopted a “cloud first” policy a few years ago, but it had the somewhat unintended effect of creating tunnel visions with technology strategies. Cloud first nearly became “cloud only” for new efforts, and what was a way to nudge agencies and their components to evaluate cloud technologies to address new capability needs or modernization, as the only thing they were allowed to consider. Those who felt that their investment margins for mistakes or errors were too thin, decided to limp along legacy systems until a direct budget allocation or major incident, putting overall operating risk in a tenuous position, namely high. For agencies and components who had planned to develop new services or were already involved in a modernization effort before this policy was promulgated, it had the effort of maybe allowing too much freedom, and some ideas were not as mature as they needed to in order to adequately show return on the resource expenditures. 

In some cases, you had a “Goldilocks effect” where the perfect match of mature programs, funding, and skilled resources along with a realistic strategy and achievable goals were met, and a number of agencies showed progress to adopt and adapt modern technologies, architectures and frameworks into their missions. In some cases, policy and administration programs such as the General Service Administration’s (GSA) 18F office, the White House’s US Digital Service (USDS) and initiative such as The Open Data Initiative, Cloud.gov and Login.gov were born digital in order to jump start the ideas and provide an applicable demonstration of adoption of new ways (for the public sector) of doing things the private sector was already using or even perfecting. 

The lasting outcome of these efforts were the adoption of “digital service” and “IT transformation” teams and the creation of chief data officers and supporting offices in many agencies and components to usher in these changes in a manageable and, somewhat prescriptive fashion. There was the “Digital Services Playbook” which, modeled after the United Kingdom’s Government’s own Digital Service, offered simple “plays” for agencies to exercise to begin these transformations among their programs and operations. Without this, I feel, from my time in the Federal government, we would still see the older architectures and software development and engineering paradigms still in regular use.

To that end, returning to the private sector has been a revelation, and albeit just short of five years since my last return, the advancement and pace is far greater than I had expected, even when leading highly advanced teams in government. Just the fact that companies, through the utilization of platform and software as a service (PaaS/SaaS) models, have simplified and enabled a lot of the promise of modern technology promised by “if you only used this”. Now, I know, I could be currently employed at a “unicorn” in this respect, but the simple fact that access to things I need are streamlined and actually simple, is merely a breath of fresh air.

First, which is key to most modern environments, is authentication and identification. The Federal government has long leaned hard on the HSPD-12 framework, which utilized smart cards (PIV/CAC) to provide multi-factor authentication enablement. Whereas outside the Federal public sector, the multi-factor methods have migrated to digital tokens and one-time passwords as methods to enable secure identification and authorization to applications and services. In some cases, these services also expand into more inclusive access gateways for the SaaS consumed by the organizations, which, via standard APIs and open methods, makes for simple and trusted integrations. While HSPD-12 standards have been around for quite some time, “plug and play” integration with SaaS solutions are far from diverse and readily available for general consumption by agencies for new as well as legacy systems. 

Beyond the identification and authorization aspects of these implementations, what can be observed is that no organization’s “core competency” is providing back-end services such as human resources, finance, procurement, facilities, media delivery and service desk… that is unless that’s exactly what the company does. Barring that explicit role, it does make sense, both in an operations but often a financial and resource management argument as to why to essentially outsource this to a SaaS or PaaS provider who is in business to do this. The need to not have unwieldy cost centers for general operations also makes this palatable, and offsets having a few employees on site that are “the department” versus a liaison or account manager who will interact with requests for features, support and other needs. Also, by utilizing services, in many cases, making a decision to move to another, either due to a needs change or due to other factors, is a lot easier when the investments may be considerably less and lock-in to a specific talent pool for support and operations is not as much of a constraint for an organization.

However, there are caveats to being a bit “carefree” with the adoption and consumption of SaaS and PaaS technologies, and hamstrings both the public and private sector often when evaluating such decisions, and that is, an exit strategy. Most will go all in based on a promise, but not have the foresight to know that things can change, and given the rapid iteration of innovation, something better can and will come along, and if you don’t plan into your move, and eventual exit or migration strategy, you do so at great risk. Laws and regulations may change, the quality of service may waiver, as may the cost of doing business with those entities. As much as we’d tend to believe technology lock-in doesn’t really occur, one can just point to how many Federal agencies keep unsupported browsers around due to peculiarities in web services that only worked in ancient versions of Internet Explorer.

I did note that moving back to the private sector was refreshing, yet I’ve yammered on about what is broken and what hasn’t gotten better since that change, so what’s been the good parts? Well, for one, the simple fact that everything I do is converged. An organization that has either been born “cloud native” or took to adopting SaaS and PaaS quickly and fully merely needs to focus on their data and their integration points rather than covering rote support. While it may be overly simplistic to say “that’s it”, not having to do the day-to-day care and feeding of both core and support infrastructure reduces cost, resource overheads, and allows the technology staff you do have, to focus on a few things rather than everything.

When I started authoring this article, it was well before the COVID-19 pandemic took hold, and externally observing how organizations adapted to providing support to employees and workers to allow them to remotely participate in meaningful work, versus those who are scrambling to adapt or even lighten formerly very strict remote policies has been enlightening and exciting. The joke and memes that circulate that “this meeting could have been an email” are not only getting proven out, but the continuity of operations plans, which are often not prioritized, are being fully tested en masse. Those that have adapted well are those who generally have adopted cloud “as a Service” models and have robust remote and telework plans. There’s still some physical “in office” activities (such as configuring hardware, processing supplies and other items), but in general those organizations seem to have merely “flipped a switch” and are working through those plans.

However, this is not to say that those SaaS and PaaS capabilities have run flawlessly, as now some are in stress or oversubscription mode, and are really proving out if the on-demand scaling and provisioning of these capabilities will deliver on those promises. If anything, for IT modernization advocates, doing a comparative analysis on which organizations provided a “graceful fail-over” to remote and cloud services will be written up for years afterwards and supply enough marketing material for service providers to keep them satiated for many months after the pandemic eventually diminishes.

The next large, noticeable benefit from consuming modern capabilities is overall service, not service quality, which, depending on your vendor of choice, varies greatly. I’ve worked for public and private sector organizations that have varied in size from nearly 200,000 worldwide staff, to the smallest being about eleven, and the Achilles Heel for all of them was technical support and service desk. The cloud and cloud services has not entirely shifted support elsewhere, quite the contrary, as noted earlier, there’s a lot more integration work that is done by your organization to make it play all together. But with well-defined and documented, standard and open API, they tend to be easier to troubleshoot if you aren’t doing something creative and special with them and their services. The core services, those provided by cloud and service providers are their core competency to run and maintain, so general issues about uptime are more along the lines of how you’d view your participation in a utility, which is, when the service goes out in the neighborhood, there’s little you can personally do to help. Conversely, while your staff isn’t trying to pitch in with running cloud services, they are more apt to ensure that the network is running, desktops are functioning normally, and can handle standard user requests like service provisioning. It’s not exactly sexy or fun work, but the quality and responsiveness improves when the resources aren’t overly taxed or having to juggle too many lanes of expertise. A somewhat intangible, but qualitative benefit from such technology adoption and use.

Of course, harking back to touching on “rapid” adoption of cloud and XaaS-type solutions, they aren’t free and do come at a cost, but if transitioned correctly, and part of a realistic and executable strategy, they can reduce expenditures in money and resources. Due to the challenge of trying to perform transformational activities, while still running the business, during what can be best explained away as the annual Federal budget process, a lot of time and effort was spent trying to provide “showback” for the investments in these activities. It must be blatantly clear, and be communicated to stakeholders, that they will need to do some “dual-stack” operations and know when and how to deprecate replaced or modernized capabilities. Being clear about what will be impacted, and noting the reduction of certain costs is paramount for open and honest discussions with a CFO/COO regarding their investments. That discussion is not restrictive to the public nor private sector, and those timelines for delivering success may hinge on several externalities such as budget cycles, quarterly earnings and changes in leadership, being able to adapt and be trusted will keep these efforts on track and hopefully resourced and succeeding.

Adopting a cloud or modern XaaS architecture is not out of the realm of possibly for considerations of the public sector entities, but as noted above, the margins for funding such transformational activities are slim, and much weight, culturally, has been put on quick wins, and it’s vitally important to ensure any proof of concepts, component adoptions, or service transitions tie back into a larger IT modernization and transformation strategy. Communicating that the efforts are not “one and done” but are an effort to lay the groundwork for further efforts, building upon one another. As part of that strategy, it’s necessary to work backward for goals and outcomes for the strategy and decompose elements of the strategy that have dependencies. In some cases there may be different and parallel workstreams, owned by different groups with different authorities and responsibilities, but decomposing these will help each team out towards supporting one another. I performed a similar effort when at the US Department of the Interior during our initial IT transformation activities in the early 2010s, and it was a good way to visualize the interconnectedness of all things and showed a critical path for success. 

Much of what I outlined above is truly my initial impressions on my transition in and out of government over the past decade, but in my most recent transition, the differences were much more striking, and hopefully this set of observations can act as some reasonable set of guideposts to reassure those who are slowly moving public sector entities to modern architectures and business practices. This will also hopefully reinforce some of what is being done well, and with some caveats, in the private sector as they make decisions to adopt and adapt newly developed techniques, services and technologies to run their businesses. Remember though, this is not always going to be about dollars and cents, but this article started out of a personal observation as to what my qualitative takeaways were from being exposed to an environment who went all in on software and platform as a service both as a consumer, but also capabilities they deliver to others. At times, dogfooding your own strategy that you sell to others aligns your priorities but drives output to a level of quality and completeness your customers and other stakeholders will appreciate and hold in regard.