Delivering at the Speed of Trust: Reflections
This post is written by Lindsay Chan, Jane Lu, Jordan Storozuk, and Aaron Jaffery.
If you’ve landed here after participating in our FWD50 session, Delivering at the Speed of Trust, welcome to our blog! We’re grateful you’re joining us again despite all the shenanigans. We want to share some takeaways from the workshop with those who weren’t able to attend.
This workshop gave us an opportunity to share our Digital Experience and Client Data (DECD) vision. While our activity (which we’ve decided to name “Capture the Approval”) is within the service design context, our key message from Delivering at the Speed of Trust extends broadly: the current governance process is not optimized to let us deliver when people in Canada need us.
Why we created Capture the Approval
Capture the Approval was designed to showcase blockers that stop us from delivering value to users. We designed the game to mirror real-world blockers that our teams consistently confront, and to build empathy for teams that are overburdened by process with little room for creativity.
We wanted to frustrate our participants. We wanted them to experience the hurdles that product teams face in delivering digital services today, reflect on whether the processes in place make sense, and understand what a strong team might look like in these challenging conditions. In September, we shared how we’re working to simplify governance and shift from a culture of compliance to creativity to better support our product teams.
In an iterative way of working, teams continually learn from their users and are able to deliver value quickly and repeatedly. Our game instructions encouraged each table to consider themselves as teams solving a problem according to best digital practices.
However, we also introduced processes that align with the traditional, waterfall governance structure: compliance artifacts and approvals. The game includes mandatory tasks that represent things that don’t necessarily have anything to do with the product itself, like our security and privacy assessment.
During gameplay, teams were confronted with deliverables that added no value to their outcomes and a cast of characters that gave approvals based on arbitrary rules.
Current governance processes aren’t user-centric
Our current governance protocols aren’t proportionate to the risk of products, often causing delays to release products when users need them. This doesn’t just impact teams in government, it also makes our services harder to use. We want to make the good path easy and be where people in Canada need us. The current process is inhibiting teams from serving Canadians.
Long delays for delivery means riskier products and a higher chance that the product will no longer meet user needs. We’re working to redesign and simplify governance so it empowers teams to make decisions and quickly deliver value to users.
Here’s what people said about the workshop
Despite all the intentional blockers, pointless rules, and unhelpful help, our human-centric approach made the game bearable — and maybe even fun — for teams.
Here are some things we heard:
- “We felt good until we felt bad. The process we understood we were to follow was clear. The actual process made no sense.”
- “The drawings were a nice simulation of all the side-tasks part of policy making and delivery. Reformat your deck, make a memo, consult committee X”
- “[the activity]…replicated the feeling of doing a task without enough information, time or resources.”
- “So fun and so chaotic — you totally simulated the experience of being a new agile team in a traditional program area. We were challenged with not having all the information and needing to jump to solutions”
- “Having an entire meeting only to hear ‘well I don’t have the authority to approve’ is super frustrating.”
- “When I freelanced, I used to read a blog called ClientsFromHell and during a webinar I asked the guy about working with Government and he said he refuses because you can’t do good work without direct access to decision makers.”
Finding purpose amid the chaos
During our post-activity discussion, it was clear that teams felt a gamut of things: rushed, engaged, frustrated, excited. Many shared the process made no sense and were unsure they came up with the best solution. Some teams reported spending more time on the drawings than the tasks themselves; they felt like the process was the goal. They were exactly right.
Incentives and rewards added a feel-good effect
Others observed that the incentives felt good (approvers “stamped” their approval with colourful stickers!). They learned how they were rewarded as the game progressed (for good drawings and not for good user-centred product or service design). Teammates had to make many assumptions to deal with all the unknowns when trying to complete the tasks.
Collaboration and teamwork for the win
Many participants still had fun because of the collaboration, shared challenges, and ability to bounce ideas off of each other. It helped if the team had more easy-going approvers. It was also much easier to understand the instructions from the start if participants had experience designing products in their real jobs.
Teams who felt good had trust in each other, shared responsibilities, leveraged their mixed skill sets, and were mission-driven together: “I felt excited because my team was all in it with me addressing the issues. We had a lot of fun. I wish work felt like this more often.”
Other observations:
- Many teams split up the tasks between the members and worked on them individually. This makes us wonder about whether the solutions were only a vision from a few of the members.
- Some teams didn’t catch all the details of our oral briefing, and didn’t get the cue to turn over the instruction handout. They stuck closely to our sticky process and lost a lot of time as a result.
- One table had a detailed drawing of an object that wasn’t part of the prompts, and ultimately didn’t count for anything. It’s easy to lose motivation and focus on the wrong things when the process lacks purpose and clarity.
Running the game at FWD50
Each table had about 8 participants that formed a “product team.” We presented a scenario and each team was responsible for completing 4 tasks to build a solution. Each team had a randomly assigned lead to help divide the tasks.
The game loosely mirrors the 4 phases that a typical agile product team follows to launch a service (Discovery, Alpha, Beta, and Live). For example, task 1 (discovery) required teams to identify a potential problem in the scenario (define problem space) and who would be affected by this problem (define the user).
In addition to answering the task-specific questions, teams had to complete mandatory drawings associated with each task before they could seek approval. For task 1, in addition to defining the problem and the user, teams had to also provide drawings of a bunch of mushrooms, a snail eating, and a cat sleeping.
If you’re confused by how these drawings are related to answering the questions, you’re not alone.
Our DECD team became approvers during gameplay, wandering around for tables to flag when they’re ready to seek approval. The approvers were unpredictable (we took our job very seriously)! Sometimes they were out of office or didn’t like the drawings. Some of us were new and had to escalate questions to someone more experienced.
We also embedded wildcards in gameplay — providing additional blockers that were revealed to teams at different stages.
The approvers in the game didn’t have technical or design expertise tailored to assess the teams’ tasks, and weren’t always available when teams were ready to seek approval. The wildcards added even more blockers, such as: burnout and attrition (“sit out for this task if your name comes first in the alphabet”); organizational restructuring (“assign a new team lead”); and teams being crushed by process (“redraw one of the drawings from task 3”).
All of this was a recipe for chaos, fun, and frustration.
Share our game and continue this conversation
If this sounds like your kind of fun, we’ve packaged the materials for the game for you to recreate it.
We invite you to run this game with your own teams to start conversations about how to shift from compliance-focused to value-focused governance. If you decide to do roadshows with this game, we’d love to hear about how they go.
Please reach out to Jordan Storozuk, Lindsay Chan, Jane Lu, or Aaron Jaffery with any other thoughts you’d like to share — or if you want to write a post on your experience!
