Learning over Outcomes

Brenna Fallon
UX Program Manager, Google

From the DesignOps Summit website:
As organizations scale, we risk over-engineering the way design teams work. This can mean creating brittle systems and discouraging true innovation. In this talk, we’ll explore learning-centered approaches as a way to embrace change and foster long-term success — and how we can find inspiration from our childhood roots.

Brenna leads Design Program Management for Google Search. She doens’t have a design background. For her, outcomes are a security blanket. For the next 20 minutes or so, she wants to let go of final outcomes.

It matters what you build, but it matters more if you learn. Learning culture is really what is paramount. We know there is value in being goal oriented. But what does it mean to bet on growth?

Change is constant – it’s about the environment you create. Everything she needed to know she learned in Montessori. It’s a learning approach which encourages independence. For her, it shaped how she approaches problem solving.

Both of Google founders were Montessori kids – they are always asking “Why should it be like that?”

Independence. In Montessori, kids learn from working with materials rather than direct instruction. You learn how to take care of your space. Google’s trainings are built on the same discovery model – for all Googlers, not just UX and tech. They are all in the design mindset from the beginning. At her new hire training, they had to come up with their own answer to “What is Googley?” The 20% program is a key to independence and how people operate. You use that time to do whatever you want. You can volunteer with Google.org, automating tools for your team, or imagining new products. But how does this independence scale? At Google, they use OKRs (Objectives, Key Results). The Os are lofty, aspirational, and the measures help you know you’ve achieved those things. OKRs flow up and down – from the highest level of organization to individuals, and it’s bi-directional. You write the goals you’ll be accountable for. They are posted for everyone to see in a tool created by a 20%er. They grade themselves. If you got a perfect score, it means you didn’ set your sights high enough. Good is 75%. We use these to focus on what is important.

Order. People need the structure and the resources to explore. Montessori classrooms are broken up into different areas. She is going to go deeper here since it’s so integral to how they work.

They use Design Thinking to guide their work – from informal and organic to being really strict and gated. But what is interesting is the first diamond. You can realiy make sure you explore and hone in on the right problem, and the right solution. Sometimes things get stuck in the process – things that are executive driven, or projects that are hard to say no to. For the Google App, they went through a difficult period where the designers were ‘design monkeys’, and product managers were doing mocks they wanted tested.

In the squad model, Agile matters more than scrum – ‘loosely coupled, tightly aligned’. This was built out and publicized by the Spotify team. The squads should be self organized, interdisciplinary, and focused on a big long term problem. There are many of good things about it – the autonomy is motivating, and lots of fresh ideas come through this way. But researchers did not do well in that model. For the iOS Google app, kick-off and rollout were done differently – it started strong and with good energy. But then things started to go sour – fear of overlapping ideas, not getting support for bolder ideas. This approach flopped after six months. Philisophically she’s all in, but it needs to be done at a the right moment.

What about the Research Train model?

This is hottest newest thing in their organization. Every quarter there is an field study, every month a diary study, and so on. You gain a lot of time with users this way, and the entire team is focused through the train – engineer is building prototypes for the reseachers to test. There is a startup culture of making progress every week. That quick movement is key in a big company. But it can be really expensive, and logistically hard to pull off. And it requires engineering mindset shift, because historically they have been promoted based on launches. So that required a lot of thought and messaging to encourage engineers to spend 40% of their time on prototypes. The Google Go team pioneered this in the UK. Away from headquarters in Mountain View, they were able to experiment in ways that can be hard closer to corporate. They built this out and it has since proliferated across the organization. It has been incredible to see the uptake on this approach.

Different planes of development

There are different planes of development. It’s important to understand where your teams are. In Montesssori, the educational approach changes to adapt as kids grow.

Tuckman’s Stages of Team Development – forming, storming, norming, performing … and (as many have mentioned this week) reorganizing. 🙂 Each has it’s own challenges. What is the role of a UX Program Manager in this space? Some people have argued for certain functions that have historically been in HR – they haven’t done that at Google.

What they have done is extensive resarch with their People Analytics team. WHO is on the team matters less than how people interact, how they struture their work, and how people view their contributions.

Pyschological Safety is at the bottom of the pyramic. Do all team member feel comfortable, will they be supported by their peers? Dependability – do team members deliver on time, and with high quality? But you can’t jump here if you haven’t done the other two first. The Meaning then becomes important – do people feel personally and professionally fulfilled? And finally, Impact. Do people feel like their work is making a difference?

From this research, they learned that it’s not about consensus-driven decision making, or work-life balance, or co-location. These are key to Google’s ability to thrive in the market. Being able to create and build new things – they are able to operate more independendently.

This could be the quote from a Design Program Manager:

On Monday

• Look at things with fresh eyes
• Celebrate loudly – when you learn and when you fail
• Incentives – it makes operations stick
• Design processes around learning
• Conduct blameless post-mortems
• Don’t lose track of individuals; they are not resources
• Be ok with being messy

Why do we leave behind our security blanket of outcomes? However powerful would our teams be if they were not afraid to fail? It is worth the leap! If we build teams only on what we know today, we’ll miss creating a better tomorrow.