Special thanks to Jessica Dussault for this image!
An unlevel playing field
In June of 2021, 18F embarked on a new kind of partnership with the Office of Head Start (OHS). Several 18F teams had successfully worked across OHS since August 2019, and their work surfaced common issues shared across the agency. In an effort to tackle their systemic issues in a more comprehensive way, we consolidated three different projects into one.
We were excited to tackle problems across their systems, but our new agreement introduced some complications. Suddenly, instead of working with a single partner we were working with four system owners, all very invested in the success of their own system as well as the success of cross-agency data-sharing and system-building initiatives. We’d worked with some of these stakeholders for over a year; others, we’d briefly met in meetings. Their level of familiarity with agile thinking and development varied, as did their technical expertise.
The recommendations that 18F presents can feel intimidating if we don’t do the work to level-set with our partners. We understood early on that in order to be effective with our partners, we needed a way to achieve a shared level of understanding about some of the scary-sounding technical details, while not leaving any of our partners behind.
Enter tech talks
To get everyone on the same page, we set up a recurring weekly meeting where different members of the 18F team presented a short talk about a concept or term related to the work we were doing. Some of the topics related directly to something we were working on that week, others were about a broader concept that we thought would be interesting for them to learn about. One week an engineer would present “Version control and Git” while the next might be a designer/researcher talking about “UX Design 101.” We crafted these presentations to help our stakeholders understand technical concepts, often using metaphors, or breaking down complex topics into essential building blocks.
Because our stakeholders were mostly non-technical, we wanted to make learning a priority of our project. Our partners could ask questions in a safe space without feeling embarrassed or rushed. The more our partners understood the agile software development process, the easier it would be to internalize and practice our recommendations.
Preparing these talks also allowed us to slow down and think about our audience, and what precisely we wanted to convey to them. As we reached inflection points in the project about things like data sharing across systems, we could dedicate a tech talk to “APIs as data exchange,” to better explain and contextualize the methods we used and the decisions we made.
The tech talks worked as we’d hoped: our partners leveled up their knowledge of agile practices and increased their buy-in. It was exciting to work with them so actively to increase their understanding. We noticed a number of other benefits from the tech talks for our team that we had not anticipated.
Building trust
The One OHS project spanned 4 technical systems and different areas of oversight and development, which meant that each team member worked more closely with one of the four stakeholders. Since the stakeholders all committed to attending all the tech talks, each talk was an opportunity for an 18F team member to demonstrate mastery and build trust with all the stakeholders on the OHS side.
Tailoring our talks to the interests and skill levels of the partners let us demonstrate that, whether we had been working with a partner for a year or a month, we were paying attention to their (and their system’s) needs. The talks were a way to express our intention of working for the benefit of OHS.
Our OHS partners asked very good and sometimes very tough questions. We didn’t always have great answers prepared, and we made a point of responding “I don’t know offhand,” or, “We’ll have to do some research to answer that question,” when we couldn’t answer something directly. Being candid about what we didn’t know modeled vulnerability and signaled that gaps in technical knowledge was not only okay, but was expected.
Demonstrating mastery
Completing a project feels great, but to keep morale and energy up, team members also need small wins along the way. It can be tricky to feel that sense of progress on projects like One OHS that have expansive, long-term goals.
Our tech talks were a tangible deliverable that allowed us to have many small wins on a weekly basis. Even when we were doing high-level, abstract ideation work, we still had learning time with our partners and a presentation that we could share.
Our partners were learning, but we also got to learn from each other. Our large team had shared expertise in everything from accessibility to data visualizations; every week was an opportunity for 18F team members to grow as well. Breaking down complex topics for our partners, and learning alongside them felt really great every single time!
Creating a shared space
Early on in the tech talks, we noticed that some of our newer stakeholders were more engaged; they seemed very excited about being able to learn and level up their technical skills. But what was really exciting to see was the way that they began asking about each other’s opinions and experiences on shared technical problems.
Historically, the OHS systems and teams have been siloed. Creating a collaborative meeting entirely for their learning opened up different opportunities for them to relate to each other. Building cross-system interoperability is long-term work, but the tech talks became an early step in establishing shared understandings and contexts for OHS.
Developing your own tech talks
Dedicating time to leveling up our partners’ knowledge had a lot of benefits that went beyond the scope of what we initially guessed. We did have a few takeaways that made our talks more successful.
Schedule a recurring meeting and make it mandatory
It’s hard to schedule ad-hoc meetings with many participants. Carving out a specific, recurring time that works for your team and your partners signals that learning is a priority for the project. While you can always be flexible about attendance, making the meeting mandatory for your team will demonstrate the importance of the subject matter.
Include your partners in topic selection
Asking our partners what they wanted to learn was an opportunity to better understand their interests, as well as giving them ownership over their own learning. Creating a curriculum together is an easy way to demonstrate your commitment to the partnership.
Use the talks to unpack future recommendations
In an ideal world, our final project presentation and report should only include concepts that our partners are deeply familiar with. In reality, we didn’t have time to drill deeply into every subject. If you’re leaning towards specific recommendations, tech talks are a perfect chance to explore those ideas so thoroughly that by the time a project is over, they’ve already internalized the approach!
Leave a lot of space for questions
We scheduled the meeting for a full hour, but our presentations rarely exceeded thirty minutes. If there were very few questions we were able to give everyone some time back, but when the talk was on a subject of particular interest to our partners, we all benefited from a lengthy q&a period where we could discuss how the topic applied specifically to their systems.