Embracing Uncertainty: How to Get Untangled & Make Constant Change Work for Your Org

Matt Powell at UXDX USA. Video: https://youtu.be/mQVDcLfL6Ss

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Planning in a world of constant change

[00:00:01] That's not my deck. Oh yeah, it is. That was The Simpsons. Okay. Actually, this is a perfect example of what I'm here to talk about, which is embracing uncertainty, and the fact that we live in a world where whatever can go wrong will go wrong almost all the time, and everything that we think we can count on when we start a planning cycle changes underneath our feet as we go through it. If the last five years haven't taught us that, they haven't taught us anything. Pandemic, inflation, work from home, return to work, hybrid work, war in Ukraine.

[00:00:35] I just read this morning that the next big thing we're all worried about is what's going to happen in real estate and what that's going to do to banks, because 20% of commercial real estate is still vacant and there's $1.2 trillion in regional bank money loaned into office leases. So there's this whole new discussion about what that's going to do to the banking system, which I can't even notice anymore, because what are we, seven days from the country defaulting on its debt?

[00:01:04] At the same time, in this world of all this crazy change, all of us are expected to operate inside rigid annual planning cycles. We get together at the beginning of the year, at many companies years in advance if you're producing something that actually has to be built, and we make a plan for what we're going to do either the next year or the year after that. And we all know that before the ink even dries, something substantial is going to change. So figuring out a way to operate in that environment, where our plans get socked in the mouth as soon as we start to work on them, is a critical act if you're going to be successful in the modern world. I certainly don't have all the answers, but I happen to be coming out of a period at a company in a situation of a ton of change, so I thought maybe I'd share a nugget or two of what we've learned.

FTD and a company in turmoil

[00:01:52] But first, an introduction to me. I'm Matt Powell. I'm the chief technology officer at FTD until tomorrow, and then I'm starting a new job on June 5th, continuing the ongoing uncertainty. My remit is to run our technology division and our contact center division. I have 215 folks in the US and India on the technology side of the house, 75 captives on the contact center side, and another 100 in a BPO. So I'm dealing with a team that's in the US, India and the Philippines, responsible for everything from the ethernet jacks at the desks in the office that we no longer go to, to the SaaS products that we sell to our small business florists, our e-commerce property, and everything in between. My tech teams are cross-functional, so it's UX, product, engineering, QA and infrastructure, all in one place.

[00:02:44] FTD, for anybody who's under 40 and has no idea what that is, is a 113-year-old flower and gifting marketplace. As an interesting aside, 13 florists in 1910 are actually the people who invented the concept of the wire service. American Express, Western Union, all of that: a bunch of florists who thought it'd be kick-ass if you could use a telegraph to send flowers from Dallas to Boston that day, in the early 1900s, which is kind of amazing. Today we serve 90% of American households for same-day and next-day delivery from our fulfillment network. We do most of our fulfillment through a network of 10,000 small business independent retail florists. Talk about uncertainty: everybody wants to do business differently, and you have to facilitate that. We do about seven million orders a year, and those florists are using our marketplace technology and our SaaS technology for running their e-commerce websites, which we provide, running point of sale, doing local commerce, and doing delivery.

[00:03:44] In August 2019 the company went through a bankruptcy. That bankruptcy was really a direct result of a decision a couple of years before to make a big acquisition of a competitor, get out of just being in the flowers business and into a bunch of other gifting spaces, and get out of doing everything on a retail basis and move into drop ship. Anybody who's ever been through a merger knows it takes way longer than four years to finish them, and before the merger was even finished, the company went bankrupt because it couldn't meet its debt covenants.

[00:04:13] I came in on April 1st, 2020, just six months after that, into a lot of turmoil, and I started work seven days after the country went into shelter in place, so I didn't meet my team for a year. That's a long way of saying that I've been living in the land of uncertainty, and we've bumped into some things about it that I think can be potentially helpful.

Empowerment as the answer

[00:04:41] When we think about our attack on uncertainty, and how we build organizations where change isn't a scary thing but something you expect and are excited about, it really all boils down to one thing, which is empowerment. How do you create an organization where each cellular unit is able to act like a part of the whole, where the DNA for the way the company works, its values, how it makes decisions, what's important, is encoded in every cell, so that every cell can represent this larger organism?

[00:05:13] Top-down approaches, in our opinion, are way too slow. They don't have enough throughput, and they don't have the best information available on the battlefield, at the point of contact, to make the decision. There's too much inertia, and they discourage bravery. They really water down bold ideas. What we have found is that if you can empower each person, each team, each department to respond flexibly and autonomously in the moment, without having to get approval or permission, without having to ask how to act, but in a way where all those actions still ladder up to what we're trying to do, the outcome is way, way better in terms of results, and it's just a lot more fun.

[00:05:53] People want agency, particularly knowledge workers. You want to feel like you can make a decision, and not that everything has to go to committee, and empowerment really is the grease for that. When we think about empowerment, there are three things we try to do. We focus on alignment, we focus on enablement, and we focus on psychological safety. I'll hit each, but I think the important thing to think about is what it looks like in an organization if leadership, instead of being a system of control that assumes the people inside the organization are inept or lazy or all the things that autocratic ways of thinking about companies assume, instead recognizes that its responsibility is to create an environment of alignment, of shared understanding, of shared belief, and of a shared way of keeping score. Then something really special can happen.

Alignment and a shared way of keeping score

[00:06:49] All right. Empowerment starts with alignment, and alignment is really about understanding the difference between a specific set of repeatable rote instructions and what we're actually trying to do. I love this goofy graphic, even though, if you're following along, it's not really the best time in the world to be showing Dilbert graphics, but this is the best version of this graphic I'm aware of. There's one way of going, which is telling people to build a bridge. Then they get there, and for whatever reason it's not a good place to cross the river. The important thing is that we need a way to cross the river, and a bridge may be a terrible answer. Alignment is knowing that we want to cross the river because we need these folks who are behind us to be able to get from here to there, and that's very different from the specificity of saying it has to be a bridge.

[00:07:38] Empowering people starts with alignment. Aligned organizations have a shared understanding of business strategy, a shared understanding of the executional approach, and, most importantly in my opinion, a shared understanding of how we keep score and how we make decisions. There was a discussion earlier in a forum about prioritization, and one of the comments that got raised was that people struggle with backlogs that just fill up over time and that you feel like you can't crack into. Designers are frustrated that we've got all these great ideas and they aren't getting prioritized, because our capitalist VC and PE overlords don't want to focus on those things. The same thing happens for engineering teams, where they get worked up about tech debt that no one's ever going to let them touch.

[00:08:18] I have found that the key to cracking all of those nuts is to put everything into a common language that works just as well, in my case, in the contact center as it does for making a software engineering decision, and that connects to the P&L. Then there's none of this subjective debate about how to make a good decision; instead we can all make an aligned decision with a shared understanding. Because I work for a private equity-owned company, for us it's EBITDA, and we boil every decision down to EBITDA. Every decision can be boiled down to that. If we're building something that makes people more efficient, how many hours are they going to get back? What do those hours translate into in terms of value? How will those hours be redeployed, and what is the value of the time that's created through the redeployment?

[00:09:04] If you can standardize on a way for the company to decide what's important that everyone can use, then you can start having objective discussions, not subjective discussions, about what we're going to do and prioritize next, and you can start pulling stuff out of your backlog. Sometimes you have to pull a five whys. It takes a bit of work to figure out how to do that with some kinds of tech debt. Well, if we build this admin tool, it's going to make this thing easier. All right, let's figure out how much time goes into the engineering team having to do things that we could do through an admin tool. What's that worth over time? What would it be worth to go faster?

Alignment at D-Day

[00:09:43] One of my favorite examples of the power of alignment comes from the invasion of Normandy, D-Day. If you think about what happened on June 6th, 1944, everything that really could go wrong for the Allies went wrong. They dropped 13,000 bombs ahead of the invasion, and almost all of them missed their intended targets. The Navy bombed and shelled all the German positions on the beach and made almost no dent; all of the German encampments and reinforced bunkers on the beach were still there. American tanks that were supposed to be able to swim, which were going to provide the armor cover on the beach, all sank because the seas were higher than they were supposed to be. Paratroopers got blown off course and landed all over the place.

[00:10:26] But in spite of all that, the Allied soldiers had the critical advantage of an aligned understanding, not only of the specific actions they were supposed to take, but of the way those actions came together to lead to an outcome for the Allied armies. The German armies, conversely, were just as well trained and just as battle-hardened, but struggled with alignment and empowerment. As one example, one of Hitler's top commanders was a general named Rommel. Rommel had wanted to position all their Panzer divisions just behind the beaches so they could be moved very quickly to wherever the landing occurred. Hitler disagreed. Not only that, Hitler had decided that the only person who could release reserves was him, and he was up late on June 5th partying, so he didn't get up until late on June 6th. Reinforcements weren't released until 3 p.m.

[00:11:14] As a result, in spite of the fact that heroic fighting was done by Germans all up and down those positions, the Allied army prevailed. All of these soldiers who had landed with units that weren't theirs organized ad hoc units on demand and recalibrated their mission objectives for each of these pop-up teams they created, in pursuit of the outcome they wanted to achieve. I think we all know what happened as a result. That was the beginning of the end of the war in Europe, and it was really a result of the fact that the Allied army had much stronger alignment and a much stronger position of empowerment, which enabled their forces to react to the changing conditions on the battlefield, but in a way that was consistent and laddered up to the overall plan.

Alignment at FTD

[00:11:58] Alignment also works for companies, not just in the military. If you Google the power of aligned leadership or anything like that, you'll get hundreds of these. I just picked these, but there are tons and tons of stats about companies that are highly aligned making more money, retaining customers more efficiently, making more profit, growing at a higher rate, and wasting less time on the kinds of things that slow us all down and distract us.

[00:12:27] One of the things we found at FTD: when I came into FTD, there was this mountain of software and systems that had to be upgraded, many things that hadn't been touched in decades. In fact, our ERP system is 40 years old and has been out of support since before I graduated from high school. The point of sale system that our members used when I started was 15 years old. So we had this problem of figuring out what to do when basically everywhere you looked was broken. Any quarter you could look at inside the tech and product landscape was just an absolute mess.

[00:13:09] So how do you make the thousands of decisions that are necessary to quickly drive change, and how do you do that on a private equity timeline? In an environment where private equity owners buy a 113-year-old company out of bankruptcy, they instantly expect you to create value. You have to figure out how you get teams aligned and moving in a direction in a world where there's more to do than you could ever possibly process. The only way really to do that was to empower people, to get people around an aligned vision, a place that we're trying to go together, and then get them making those decisions. Otherwise, if we'd approached it through the lens of top-down planning, three years later I'd still be doing that, and we wouldn't have gotten anything done.

Enablement: data, friction and process

[00:13:55] The next critical tool we look to that helps drive this empowerment is tooling for enablement. How do we create the tools that actually enable teams to operate independently? If we've created this alignment, everyone understands what we're trying to do, how we're trying to do it, and how we measure success. Then how do we start to actually give them the things that help us get more out of their time and more out of the attention they're putting in?

[00:14:23] One of the places we start thinking about that is with data. How do you make sure people have access to the information they need to understand whether the things they're doing are working? What information does this individual, this team, this department need to make good, high-quality decisions? How often do they need it, how fresh does it need to be, how hard do they have to work to go get it, and what can we do to make that easier? So it's not this act of phoning a friend to get support to figure out whether the thing we're trying to do is working, but committing as an organization to which metrics are important and then piping them to the people who need them, so they can take their own action without having to ask someone if they're keeping score.

[00:15:04] Similarly, what work do people do regularly that gets in the way? What generates a lot of churn? Where is there a lot of repetitive action, where too much of our energy is going to something we should see in advance and be able to tool for simplifying? What solutions can we design to reduce the friction that goes into the everyday work, so that more of our time and attention is available for solving the new and unexpected stuff that's going to show up, that we can't plan for?

[00:15:36] Then, how can we build processes that are designed to facilitate change? Process is a funny word. I bet most people in here are like me and love it, but for some people process is a really dirty word. It's this creativity-stifling straitjacket. My belief is that process is the most amazing tool for freeing us from the boring. Back to a military analogy: many militaries of the world are populated by folks who don't have as many other choices, particularly when you think about the rank and file, and they do amazing things. How do they do it? Process. Why do people spend so much time learning how to clean a weapon? Because you don't want to have to worry about that if you have a misfire in the middle of a fight. You just need to do it and get on to the more important thing, which is saving your hide. So we think a lot about where process is adding friction instead of enabling creativity, and what we can do to engineer into processes the kind of fluidity and flexibility necessary to allow us to react to a dynamic world.

Combined arms and cross-functional teams

[00:16:37] The last thing we think about as we consider tooling up our teams to thrive in uncertainty is what we call combined arms. I believe a lot in putting teams together cross-functionally, because I hate scheduling. When you watch teams doing all this resource planning and alignment, and all the context switching that happens with that, it's like, why not just build cross-functional teams? At FTD we run value stream-aligned, fully cross-functionally integrated teams. For example, I have an e-com tech department whose full-time job is all of our products that point to consumers, so they can convert internet traffic into network demand, network orders. I've got another team that just focuses on my florist customers and just builds SaaS products for them. In those teams are UX, product, engineering and QA, so there's no having to schedule anybody. All the teams are built with squads as the cellular unit, with agile alignment as the primary structure and functional alignment as a secondary structure, which can be hard to do but I think is very powerful.

Enablement examples: CMS and the contact center

[00:17:45] There are two examples of places where we've tooled for enablement that I think are worth sharing. When I started at FTD, we had about 5% CMS coverage of our websites, which meant that every time you wanted to do anything to the website you had to call an engineer. That was particularly frustrating when we were spending a million dollars with Adobe on Adobe Cloud to have 5% CMS coverage. For a variety of reasons we had to re-platform, and we re-platformed on Contentful as the CMS. Now we have about 98% coverage in the CMS. Not only that, we also have an integration with our testing framework, Optimizely, which means we can run A/B tests from the CMS without having to call an engineer.

[00:18:27] That doesn't mean we don't do testing and feature development that requires engineers. It just means we don't do the boring and repetitive stuff that way anymore. Changing type, changing the layout on the screen, testing headlines, button colors, positions of things: all of that can be done by business users, which is a term I hate because I think everyone's a business user, but I digress. By non-engineers, so that the engineering team's time can be focused on creating value through new features or running more complicated A/B tests, that kind of thing. The other thing that's important about that is not just freeing up engineering time but enabling the P&L owners to butter their own bread, instead of always feeling at the mercy of someone else's schedule. They can do a huge portion of what they need to do to create value on their own.

[00:19:13] Similarly, in our contact center we upgraded from a bunch of more manual tools to a young SaaS company called Gladly. One of the things that's amazing about that is that the CS team went from having to call dedicated Salesforce developers to make changes to workflow and queue management, all the kinds of things that come up in running a contact center, to being able to do all that themselves. It's also got all the contact center data in it, so they no longer have to go to finance to see how things are going. They can see in real time, minute to minute, how things are working in the call center, and adjust the way we deliver the product that is customer service in real time, with very limited developer interaction. Again, that frees more resources for doing more interesting things.

Psychological safety

[00:19:58] The last thing we think a lot about for empowerment is psychological safety, which can sound pretty kumbaya, particularly in private equity and venture. But the reality is that without psychological safety, bad things happen. There's new research on our brains indicating that the more time we spend in fear and stress, the larger our amygdala gets and the smaller our hippocampus gets. The hippocampus is where creativity, imagination, problem solving and all this great stuff happens, and the amygdala is the fear center; it reacts with fear, it's where fight or flight lives. Which condition do we want to be facilitating structurally in responding to dynamic environments: fear and fight or flight, or creativity, imagination and openness? So psychological safety is not just something progressive and New Age to talk about. It's really important if you want to create the conditions where people bring the best of their intellectual machinery to work.

[00:21:02] Psychological safety is a way we make sure people can speak truth to power, that we can hear what's really happening inside a company, and that we can see where the opportunities are to fix things. For example, at my new company the team was in the Philippines visiting the contact center, talking to a bunch of call center agents that no one had spoken to in a while. Somebody asked what could be done to make their day better, and someone offhandedly mentioned it'd be great if the websites worked in Safari. The new CEO, my buddy, started to pick at that, and what he learned was that the websites don't work in Safari and most of the calls the agents get are people yelling at them about that. All of the agents were like, wouldn't it be great if you could just fix that so nobody would yell at us? But they hadn't told anybody for years, because they didn't feel like they could.

[00:21:54] Without psychological safety, people won't. But if you can create a condition where people feel they can say what needs to be said, then the whole company becomes a sensor that we can all use to make better decisions and design better systems. So how to do that? I'll start with the middle one there: blame how, not who. I generally think the act of figuring out whether a person is the problem is an HR act that's character-driven and really about whether a person fits into a team, and it should have almost no role in looking at things that go wrong on a day-to-day basis. We either have the right people or we don't. People are people, and we're not going to blame them. Instead we look to the process. Where did our way of working not manage this condition, and how can we change our way of working so that whatever went wrong is something we can absorb? If you approach things going sideways through the lens of our processes being brittle, and as a training ground for making process better, that gets people feeling comfortable and safe, so they don't have to worry about being in the spotlight or having a target on their back simply because something went wrong or because they said something they shouldn't have.

[00:23:05] The next one I'll hit is the leadership vulnerability point. I have found that part of making people feel safe is demonstrating that when you're in charge, you're not a robot. You're a regular person. Sometimes you didn't get a chance to shower before work and you're on camera that way, sometimes your kid bites your leg while you're doing your thing, and sometimes you don't know the answer. We do town halls every month, and we take anonymous questions from the team, because anonymity can make people feel safe and create space for talking that people wouldn't do otherwise. And we answer all the questions, which feels like such a dumb and obvious thing. But I've been working for 25 years, and I think at every other company I've been at, we wouldn't have done that. We'd pick which of the questions we felt comfortable answering and sweep the rest under the carpet.

[00:23:55] But somebody asked, and if somebody asked, somebody else has that question. If you're not willing to step into those things, you're not being transparent and you're not being vulnerable, and then nobody feels like they can be either. So if you want to make people safe, I think you have to be willing to have the conversations people want to have, to say the things that are true even if they're hard to say, and to say you don't know when you don't know. We found that those two things work together really effectively to help make people feel safe in the way that we engage with them.

[00:24:25] So that's it, that's my 20 minutes, which always go by so fast, particularly when the screen is flickering at you. We see empowerment as the antidote to uncertainty. I think even in a certain environment, empowerment and this way of structuring, organizing, motivating and running teams works best, and it really boils down to alignment, enablement and psychological safety. Thanks.

Q&A

[00:24:56] Host: Thank you so much, Matt, I love that. When you talk about empowerment, alignment really allows people to go and do their best work, enablement lets them execute on it, and when people are working together, aligned and collaborating, they can develop that sense of psychological safety within their teams. So it's fantastic. We have time for questions, so please raise your hand and I will gently pass this box. We'll pass it to you first, and then you'll pass it back, right there in the orange.

[00:25:29] Matt: Awesome, I love that thing. A beach ball microphone. It feels like it should be at parties.

[00:25:37] Host: Oh, and before we go, really quickly, we have some online questions that I've unfortunately been neglecting. Right now, actually, we don't have online questions, but if one comes up I'll definitely get your attention.

[00:25:54] Audience: Hi, I'm Anne. You said something about the way you structure teams to reduce context switching, and I was like, wait, wait, how did he do that? Can you repeat that?

[00:26:06] Matt: Yeah. I'm way too fast a talker, and it's worse when I'm nervous and everything went to plaid over here, so I apologize for that. I think it's incredibly powerful to cross-functionally align teams whenever you can, because it just gets you out of the scheduling game. Generally speaking, you have a two-dimensional matrix you're dealing with. There's a role for functional alignment, for career development, mentorship, the career ladder and all that stuff, and then there's team alignment, the people you're going to do the work with. Many organizations prioritize the functional alignment and then assign people to teams on a temporary basis. I think the challenge with that is where people believe they're anchored and what they think of as their team.

[00:26:55] So I think you flip that, and that's what we do. We have what we call domain-aligned organizations that are fully cross-functional, and then the functional things are centers of excellence. My Java engineers get together sometimes and talk about how we're going to do Java, and that's great, and the architects spend even more time making sure we're thinking about enterprise patterns the same way, and stuff like that. But that is secondary to their alignment underneath their domain-aligned function, and that does all sorts of great stuff. As an individual contributor, as a person doing the work, if your metrics and KPIs are functional and functional alone, you can never tell how your work ladders up to what the business is doing. If you domain-align as your primary way of aligning teams and you sit cross-functionally, my entire squad will have the exact same goals for the year.

[00:27:47] My e-com tech department has three squads, and each of those squads is working on different aspects of the value we're trying to create in our consumer front end. Each of those teams shares the KPIs for whatever the KPI period is. What that means, too, is that you don't have a lot of the problems you get when you're organized the other way. Working through a sprint, the devs are done with their work and QA is behind. Functionally aligned, with functional metrics, what do people do? Kick their feet up. If the whole team is measured on value contribution against the domain, then the developers start doing QA, or writing tickets for the next sprint, or whatever else can be done to help facilitate the team's success.

[00:28:23] Baseball teams win or lose together, football teams win or lose together. It's not like the quarterback can win and everybody else can lose, and I believe teams should be designed the same way. At whatever elevation you can get that done, you'll benefit. And if you can't do it because the organization resists it, what I would do is build strong partnerships with the other people who look like me in the functional areas and convince them that we should try to do something as close to that as possible.

[00:28:50] Host: Thank you. Awesome, right behind you.

[00:28:54] Audience: I have a specific use case. I lead a team that's abroad, and we have limited touch points. In this use case, how would you best empower and align with them, given those limited touch points?

[00:29:08] Matt: We have some of those problems too. When I started at FTD, 60% of my team was US; now it's about 71% India, and that's been intentional. The big mistake we made initially was not thinking through the way of working as a foundational thing, so we had eight-person scrum teams that had two people in one country and six people in another. We tried that for a year. It worked, but it was bad for quality of life. So we flipped that and geographically aligned all of our teams, with no resource sharing: a full scrum team per country, if we're going to do it at all. That helped a lot.

[00:29:49] And then there's the empowered way of working. You still have all these touch points you have to do. For some teams it works best, because they're parents and they want time in the middle of the day with their kids, to do an early block and a late block and have space in the middle, and I don't care. As long as the squad hits its objectives and targets, they can figure out the way of working. That's true at each elevation of our organization, too. The VP who runs my e-com tech department is a night owl. He plays video games until four in the morning anyway, so he does all of his leadership syncs with his team between 11 p.m. and 2 a.m. and then goes back to playing video games. That's what makes him happy, and I don't bother him before 10.

[00:30:30] There's another guy who runs the SaaS side of things, and he's a morning guy. He's up at 5 a.m. anyway, so he does all his cross-functional meetings with his people offshore from 5 a.m. to 8, and then I've got offshore people who do it all different ways. I think part of the key is that if you align the organization around what it's trying to do, and you set boundaries for how we treat each other and what's important to us, we can say to the team, what makes sense? And I want to hear from a scrum master sometimes: hey, we all get along great, but these two people are night people and these six people are morning people, bring us some early birds, this isn't working for us. Great, you just shift it around.

[00:31:11] Short answer: there's no easy answer, it's all situational. But I do think you should try to design for the reality and recognize that time zones are a real thing and body clocks are a real thing, and rather than fight them, just lean into them, whatever that looks like. I have to run some people on shift work, and we're putting a program in place to pay extra for that, because if you're going to have people working late, we'll have a bonus for that, and we'll let people choose. So for one team, everybody wants to take a turn in the rotation, great. If on another team it's just two, because they're younger and they need the money or whatever, I don't care. Whatever works for the team.

[00:31:48] Host: Yep, so way back here.

[00:31:53] Audience: I was curious about your tooling. You had a bunch of bullet points that were for frequent change. What's your criteria that defines a tool or a system as being for frequent change? Or conversely, what do you notice when something is not built for frequent change that's a red flag for you not to adopt it or let it into your system?

[00:32:14] Matt: One of the things is how often you make a plan where you know there are things in it that there's no hope for from the minute you write it. You're making an annual plan with feature commitments for something that's not well understood. It hasn't been spiked, it hasn't been researched, and you're making the commitment because someone has told you they want a commitment, so you're giving them one. But you know you may as well just throw the dart and hope it lands. Those are the kinds of things that give us red flags: an environment where the planning demand refuses to accept the planning reality.

[00:32:51] What we try to do is play the five whys game again, to find something where the interests overlap. Team A is committing to driving revenue growth, and they need features from Team B to do that. The normal way to do that is to commit to those hard features, and I've done this before. You commit that Team B is going to do these features on these dates, and Team A goes, great, we're going to go sell that. A week later somebody from Team A calls you and says, hey, I've got this new thing, and if we could just have one of these next week I can sell a bunch of other stuff. And it's like, no, sorry, you already told me last week that you wanted this other stuff, and I made a commitment, so we're not going to change it.

[00:33:36] What we've moved to instead is: okay, you've said you need these features, and if you get them you can add 20 subscribers. So we're going to sign up together for 20 subscriber growth. We're not going to commit to what the features specifically are, but I fail if you don't get your growth, and you fail if you don't get your growth. Then we agree on what we think the next most important things are that will help us achieve that, and we start working on those things. When they make the phone call and say, well, I just discovered this other thing, you go, great, which of the things on your own list do you want to swap it with? Now we're having a different conversation about how we get to the end game, and it starts to be fun.

[00:34:13] I used to hate those phone calls. My brother runs our sales organization. He's my little brother, and he's far handsomer than me and fitter than me, which is so irritating. He calls and says, hey, on that plan you committed to, I need to change it because there's a bunch of money over there. Now it's a fun call, because he's got some new opportunity that we're both going to win with more easily, and we can pursue it. So those are the kinds of things: trying to figure out a way to commit metrically to things that have flexibility built in, so you can change the plan.

[00:34:46] The other thing this makes me want to share is that we think a lot about really firm commitments on a sprint and quarter basis. Disrupting a sprint is an evil thing to do to a product organization; it should never happen. So we try to never break a sprint, and we try to almost never break a quarter, and past that we don't really worry about it that much. We try to plan quarterly with a rolling 12-month look, so we have a sense of where we're going next, but nobody cares if we have to change what happens after that. We do breach the quarter plan from time to time, but we try not to, and that's how we try to work.

[00:35:25] Host: All right, fantastic. Thank you so much, Matt. Let's give him another round of applause.