From Red to Green: Transforming Government Technology in 22 Months

By Mollie Bradlee, Chad Geidel, and JP Sleeger

In July 2020, Colorado’s child welfare case management system, Trails, was in trouble. Ensnared in the thick of an unprecedented pandemic that tanked Colorado’s revenue and derailed hundreds of projects across the state, we were over budget and behind schedule. Worse still, we had just identified the need for nearly 30 additional unfunded positions that were critical to finally transforming Trails into a stable, reliable system for thousands of case workers and families. Against the odds, on May 6, 2022, after 22 months that included myriad practice and culture changes, a new approach to funding, and a new team structure, Trails officially turned “green,” moving from a startlingly red “critical issue” to a healthy, on-track operating status.

It’s an oft-repeated adage that government moves slowly. So then, how did Colorado completely revitalize a system in just two years (lightning speed in government time) that was built on Jenga-esque infrastructure, straddled between a legacy and modernized platform, and saddled with technical debt? Let us tell you, it wasn’t easy! Here are a few lessons we, the Trails team, learned along the way:

1. Technology funding should be operational, not capital. Public sector technology has long been funded like buildings — there’s an initial infusion of capital for construction and build, and then a dwindling budget in the outyears to be able to touch up paint and repair roofing. But building technology is not like building a building. The approach of building a system up front and simply maintaining it in the outyears is at odds with the goal of constantly innovating to improve services. This then creates a pattern of repeatedly returning to ask committees that control budget and appropriations for large infusions of cash every 10 or 15 years. In the meantime, technology has irreparably fallen behind best practices and hindered users’ ability to effectively do their jobs. Modern, sustainable technologies need a consistent, reliable stream of funding that supports year-over-year iterative innovation, and allows teams to function in agile ways.
2. Hiring good technical leaders isn’t just about finding strong technical chops. A leadership model that relies on a Product Manager for overall prioritization and a Technical Owner to inform the technical direction creates a productive marriage between the user needs and technological methods used to meet those needs. But leadership on the technical side isn’t just about finding someone who knows the right development languages. Good leaders are players and coaches, have high socio-emotional intelligence, and possess skills that can help resolve conflict, negotiate productive paths forward, and create a positive and psychologically safe culture in which staff can thrive. Technology leaders are not an exception to this. You can’t create successful human services technology without having technical leaders who understand and share the value of deploying high-quality human services to communities. Kids and families are the center of human services work, and they need to be at the center of our technology efforts as well.
3. Psychological safety drives innovation. Government agencies, by the nature of their mission, seek to minimize risk wherever possible. But complete minimization of risk means you’re not playing to win, you’re playing to “not lose.” True innovation in technology can’t be supported in a fear-based environment where technical and program staff are afraid of risk. This fear discourages teams from doing anything other than “business as usual.” Changing this culture means rewarding new ideas, saying “yes” instead of “no,” and ensuring that work is driven not by large agency initiatives but by the needs of caseworkers using our system.
4. Building up deep in-house expertise is critical to ongoing technical success and helps to absorb runway for change. Like other states, Colorado historically relied on an external vendor to develop all “modernized” system code, while the internal state technology agency was charged with maintaining “operations.” But just as child welfare policy is always changing to better support kids and families, case management technology must also constantly adapt to the needs of its users. This creates a perpetual reliance on external vendors for any source code edits and realistically locks the state into a de facto long-term relationship that extends far beyond the scope of the contract itself. In July 2021, faced with dwindling capital funds, the Trails team made the difficult decision to offboard the external vendor and hire in-house talent to learn the code and complete all new development activities. While this transition necessitated a “slow down” of new work as developers came up to speed, it positioned the state to be able to iteratively make changes to its own technology well into the future without any dependencies on high-cost vendors. An investment in people is an investment in the platform, and good people are the key to success.
5. Get back to basics. Due to ruthless prioritization of basic system health, the nationwide Log4J incident that jeopardized systems across the country had minimal-to-no impact on Trails. Pivoting to focus on underlying security and “hygiene” involves difficult trade-offs, especially for users waiting for new functionality. But if your overall infrastructure is reminiscent of a bowl of spaghetti, piling new code on top will lead to increasingly precarious situations. A large portion of the 22-month transformation was spent upgrading the underlying database and stopping most new work to focus on system security and basic release practices. That “slow down to speed up” model has paid off: unanticipated system outages have all but been eliminated, and with a stable foundation and tightened processes, the team has again begun deploying new code while continually striving for better system health.
6. Release small amounts of code often. Big releases may feel exciting, but they sabotage timelines and place an enormous burden on users who have to suddenly relearn tons of functionality in between providing critical services to constituents. As teams build software, they’ll inevitably encounter challenges that they didn’t plan for, think of small features they want to add along the way, or inherit changes in rules or law that necessitate alterations to code. These unanticipated changes snowball over time, increasing the development and testing burden associated with the original release and pushing the planned deployment date iteratively down the road until users are waiting sometimes years between massive releases of huge chunks of code. Teams can break out of this cycle by releasing small amounts of work on a regular basis, preferably every two-to-four weeks. Prioritizing what is needed the next month while balancing longer-term, larger projects by deploying small amounts of code “dark,” or unavailable to users, allows for the kind of adaptations that are inherent in government work. Just as critically, it reduces the learning curve for users, who absorb smaller, user-friendly changes that cause less interruption for their day-to-day work.

Trails still has a long way to go to fully meet the needs of users and facilitate best practices in supporting communities. But by investing in the power of good leadership, iterative processes, and high-quality tech basics, the foundation of our work is now rock solid. These changes are paying out dividends and, for once, we’re optimistic and excited about the path ahead.