Aiming for obsolescence: Lessons from an 18F product transition

Alex Pandel is a design and product strategist at 18F, and Ryan Johnson is a content strategist at the Department of the Interior’s Office of Natural Resources Revenue.

Rewind to July 2014: 18F was embarking on one of its earliest partner engagements with the Department of the Interior’s Office of Natural Resources Revenue (ONRR). ONRR sought to build an interactive, open data site to support the department’s participation in the Extractive Industries Transparency Initiative (EITI). The project served as an early model for 18F’s style of collaboratively building digital products with not for our partner agencies and their constituents, and we’ve been blogging about the site and our partnership with ONRR since the work began.

Now fast-forward to today: the ONRR team is fully in the driver’s seat on the project, continuing to work in the open and evolve the site iteratively in response to user needs, and the 18F team is getting ready to roll off the project entirely.

So, how exactly did we get here?

The anatomy of an inter-agency product handoff

We hired a cross-functional team.

In order to continue evolving to meet user needs, any website or digital service needs a small but dedicated team to sustain and evolve it over time. Once the end of 18F’s involvement in the project was in sight, we knew there were three options to ensure ONRR had the team they needed in the long-term: 1) train existing staff into new roles; 2) hire new in-house staff; or 3) bring on contractor support.

In this case, 18F assisted ONRR in hiring three new, term-limited roles to support the site, modeled loosely after the roles of the 18F team: a content strategist, a front-end developer, and a user experience designer. With help from 18F’s Talent Team, we identified candidates, led the first round of interviews, and recommended candidates to ONRR leadership for final interviews and hiring.

We trained and coached existing team members into new roles.

The 18F team also worked with existing ONRR staff to ensure core team members felt empowered to continue work on the site on their own. This included coaching one of the existing ONRR team members into the product manager role (leveraging a training approach established by some of our 18F colleagues, adapted for the ONRR team).

To identify the roles the existing ONRR team members would step into and the training and support that would be needed to get them there, we got together in DC for an in-person workshop (like much of 18F, the ONRR team works remotely). To start, the 18F team spelled out all of the responsibilities we’d needed to run the site successfully thus far. We then asked the ONRR team to identify which responsibilities they’d each be open to taking on once the 18F team was gone in a few months and once their new term-limited counterparts were gone in a few years. This helped identify both near-term and longer-term training needs.

For each new skill or piece of the workflow, 18F took a phased approach, gradually increasing ONRR’s level of responsibility until 18F was no longer needed. Taking the data update process as an example, the 18F team started by demonstrating how the process works so the ONRR folks could get familiar with all the moving parts before diving in themselves. Then we moved on to pairing, where the ONRR folks were running the show, but with 18F there to answer questions or troubleshoot any issues. Before we considered the data update process “transitioned,” we wanted the ONRR folks to complete a successful data update on their own — without needing any help from 18F.

We transferred knowledge via pairing and documentation.

Since we were transitioning a workflow and codebase from 18F’s development environment to DOI’s, we expected some issues to arise, and sure enough, they did. For example, part of the data update script assumed a macOS/Linux development environment, while the ONRR team was running Windows.

Thankfully, we built enough time into the transition to accommodate bottlenecks in the workflow and allow us to mitigate obstacles while maintaining momentum. While challenging, each bottleneck we encountered presented some unexpected benefits:

• We made sure to pair together on mitigating each issue, which presented good opportunities to help onboard new ONRR team members to the codebase.
• Mitigating these issues helped us identify a few gaps in the documentation that we filled in as we went, leaving the project in a more solid place than when we started.

We revisited the product vision.

Early on in the transition, the U.S. withdrew from implementing the EITI Standard, but Interior and ONRR remain strong supporters of good governance and the principles of transparency represented by the EITI and are fully committed to keeping this data open and available. With the site no longer governed by USEITI’s Multi-Stakeholder Group, this shift ultimately represented a great opportunity for the ONRR team to take the lead on revisiting the vision and goals of the site with a newfound sense of full product ownership.

Taking this step to clearly and candidly articulate what we were trying to achieve, what was feasible, and the risks we might confront along the way was crucial to give the team a framework by which to prioritize future work. The team conducted a round of user research to test our assumptions and inform the key user scenarios we’d support moving forward. We expect these priorities to continue to evolve over time in response to changing user needs.

Lessons learned

Although we’re still in the process of transition, we’ve identified some important lessons learned thus far:

• Build in several months of explicitly transition-related work before you expect any “handoff” to happen. It was important for us to give team members time to build confidence as they took on new, unfamiliar responsibilities and transitioned into new roles, as well as account for unexpected curveballs that no amount of careful planning will help you foresee. This work doesn’t happen overnight. Explicitly build it into your statement of work or work plan if you can.
• Establish a clear, shared definition among all stakeholders of what constitutes a successful transition. Just like our product goals, 18F and ONRR worked together to establish clear transition goals as well. This ended up being a vital step in helping us prioritize transition work and stay aligned towards the same goals.
• Recruit and train a product manager from within the existing team (rather than hiring this role out) if you can. While it may feel like more work to train a member of the agency team into a new role versus hiring a contractor or bringing on a new, experienced team member, 18F has seen how much it pays off to keep this role in-house. Thanks to her deep knowledge of the subject matter and her agency, the ONRR product manager has been able to steer the team toward the highest-impact work and advocate for the team in a way that would be significantly harder from someone coming from outside the organization.
• Take it one step at a time. Moving into entirely new roles can be overwhelming. Take it slow to make time for team members to build familiarity with new skills and responsibilities (and figure out how to make space for it within existing responsibilities).
• Continually work to build bridges across the entire organization and bring everyone along. Working iteratively in an open forum was a new way of working for many at ONRR, and it tested the IT infrastructure and practices of the organization. While we did significant work to identify product stakeholders at ONRR, we faced some challenges caused (in part) by a lack of buy-in around our process and development needs. If we could do it again, we’d integrate a wider range of stakeholders earlier on in the project to ensure anyone who had the ability to influence the project was brought along from the start.
• Build with transition in mind. We realized in the course of transition that portions of the development workflow — while entirely open source — were not as cross-platform as they could have been. We’re still identifying work-arounds and options to translate this part of the workflow to the ONRR environment, but planning for this early could have minimized some headaches down the line.

Every transition is different

Four years into 18F’s work, transition is a topic of frequent conversation among our team. Every organization and every project is different. Consequently, there’s no single formula for a successful transition. Evolving goals, varying organizational structures, fluid teams, and advancing technology all play a part in determining what a successful transition looks like.

At the same time, every transition offers lessons that can be applied to the next. Every time we transition a product, we get better at anticipating and mitigating challenges, and we think about transition earlier and more often in the initial development process.

We’ll continue to share lessons learned from this transition and others.