Technical problems are not the hardest ones to solve

Agencies come to us to address a lot of different technical problems. They might ask us to help improve their logistics, modernize their systems, or implement a new law.

We use a discovery phase we call a Path Analysis to make sure we understand the nature of the problem to solve, and when we can solve it in a user-centered way with open-source languages like Ruby, Javascript, and Python, we work with them in a longer engagement of about six month to about two years. We use a loose scrum model, and check in with the experts — the users — to make sure we’re on the right track. We will deploy our applications to government supported platforms like cloud.gov or common cloud providers using infrastructure-as-code tools. In working on these applications, we prefer well trod paths, and will often integrate with or migrate off of legacy systems. If our partners need a vendor to continue the work, we help them with the hiring process.

But in the vast majority of our projects, the technological problem is not the most challenging aspect of the problem we face. When we work on  the technical solution, we often uncover non-technical problems that need to be collaboratively solved by 18F and the partners to ensure the project will be successful. 

We have to become both familiar and empathetic with the operational constraints of our partners. We need to understand and process resistance to change.   We need to help our partners resolve conflicts that might arise from lack of alignment, resources, and transparency. 

And we often also have to reset both our expectations for ourselves and for our partners as project directions change. 

We work to resolve these challenges by relying on inclusive communication, agility, and modeling cross-functional collaboration.

Inclusive communication

As conflicts arise, we try to work through them through true collaboration and not merely begrudging compromise. This can sometimes mean having to have a hard conversation about what we and our partners need, which requires us to speak clearly about technical subjects to people who do not share our background. People bring different technical abilities and we are careful to respect the different value each team member brings, identify how those values align to their roles, and check for understanding when speaking. 

Even in the midst of these challenging conversations, we want our team and our partners to have a sense of belonging within the groups and feel that their voices are heard.  We speak up when we have experience to share bringing ourselves and our value to the team. We seek to help our partners understand, address their concerns, and identify ways to encourage underrepresented voices to hold power.  In these conversations we try to recognize and repair our own assumptions or biases, especially where our own privilege may overvalue our opinions.  

We also recognize that asking our partners to work in a new way may be challenging for them.

Agility

When we uncover reasons to shift project directions, we need to stay nimble in our project scope, task tracking, how we staff a project, and clearly communicate expectations of how the project will unfold and how we will make progress with our partners.

In addressing these problems, we advocate for upfront communication about expectations. In the course of navigating these pivots, we have to transition between advising on a new technical direction using our software expertise, collaborating to solve emerging problems, and being a hands-on coder or security expert documenting the implications of a new choice. Across these roles, we try to bring technical integrity and follow through to build trust with our partners.

Modelling distributed and cross-functional collaboration

As a geographically-distributed organization, we try to model remote communication by alternating between video conferencing, instant messaging, and longer written communication patterns. We also recognize the value of in-person workshops, even if we can’t have those meetings during the current crisis.

We also favor working cross-functionally to address both people-oriented and technical problems. To us, that means teams which are made up of people with talents in product, design, content, strategy, engineering, and acquisition, who work as peers with each other. Within and across our disciplines, we recognize that our teams bring diverse experiences and may embody multiple representations of diversity (race, cultural, LGBT, disabilities, gender, age, religion, country of origin, socio-economic, etc). And since we try to be “T-shaped” engineers, we embrace the different skills and strengths of individuals on our broader team.  

In our engagements, 18F and our partners form joint project teams. Our partners  are the experts in how they work, the mission they need to accomplish, and the operational constraints of their world. We learn from them about how they approach their work, and we teach them what we know about developing software, leading cross-functional teams with design and product representation, while incorporating agile practices. 

If collaborating with teams and navigating through sticky situations in service of the public is appealing to you, come apply or learn more at one of our upcoming hiring Information sessions.