Connecting the dots between theory and application is rarely an easy task. It’s made a bit easier, though, when the theory goes to the heart of human existence: we want – no, we need – to be the authors of our own narrative. And that narrative must be something that we endorse and take ownership of. In other words, humans need Autonomy.

In this episode of the Product Momentum Podcast, Scott Rigby, Ph.D. joins Sean and Paul for the first in a three-part series discussing Self-Determination Theory – specifically, the basic human needs of Autonomy, Competence, and Relatedness. This episode focuses on Autonomy, with future episodes addressing Relatedness and Competence.

Autonomy, Scott shares, is not the freedom do whatever we want to do. “Autonomy is this idea of endorsement…that even within the structure of an organization, even when there are assigned goals and objectives, I can still endorse what I am doing – that I’m on board.”

And that’s a very important concept for product managers to embrace, particularly within the context of assembling and motivating product teams to create complex technical software. We need our teams to endorse the role they play in translating shared goals into reality as we bring together multiple disciplines to meet the needs of our users.

“There’s a lot of structure there,” Scott Rigby adds. “So we can’t define autonomy as freedom and expect to get the job done. When we create that optimal balance of structure with our team’s self-expression, we create the space for them to innovate and to solve challenging problems for their users.”

Podcast: Play in new window | Download

Sean [00:00:19] Hello and welcome to the Product Momentum Podcast. This is a podcast intended to entertain, educate, celebrate, and give a little back to the product leadership community.

Paul [00:00:32] Well hello and welcome to the pod. Today we are excited to be joined by Dr. Scott Rigby. He’s an author, behavioral scientist, and founder and CEO of Immersyve Inc, a company focusing on the application of behavioral science to organizations, products, and services. Scott is immersed in work with both big and small companies on culture and development, motivational best practices. He’s a leading authority on predictive measurement of motivation and engagement, as well as on interventions to improve organizational culture. Clients include Prudential, Amazon, Warner Brothers, Johnson and Johnson, and Disney. He’s authored numerous books. You can find him at motivationworks.com, a platform that empowers organizations to build greater employee engagement. We are also excited to be starting our first chapter event. Sean, what are we doing here? What’s the idea behind this conversation that we’re looking to get into today?

Sean [00:01:21] So as you know, Paul, I’m a big fan of the self-determination theory in the context of how we lead. And I think, you know, human motivation underlies everything that we do. So if we’re building software products, you think about a software product as this thing and we’re a consultancy, right? So we have people who come to us to have us build a product for people that most of us have never met. And in the middle is this team of people that actually have to build the product. There’s a lot of people in there, and we know that building great products requires highly motivated, really smart engineers, artists, designers, architects. And the only products that survive and thrive in the wild are those that actually motivate their users. You know, I’ve fallen in love with the work that the self-determination theory dot org folks, Ed Deci, Richard Ryan, and that crew have done. And Scott, I know, works very closely with them. So he’s at this crossroads of having that Ph.D., and he actually builds the software products.

Paul [00:02:19] Absolutely.

Sean [00:02:19] So welcome to the show, Scott.

Scott [00:02:22] Yeah. Great to be here. I’m excited to be back with you guys.

Paul [00:02:25] Excellent. So in this first episode, first of three, we want to go deep on the concept of autonomy and how it’s important for product teams specifically. What does autonomy mean for us in this context?

Scott [00:02:39] Yeah, no, it’s a great question, and I’m glad we’re starting with autonomy because autonomy is often the basic need that I find is most misunderstood. First, let me talk a little bit about what we mean by need, which is, we have found in the research through self-determination theory that there are three what we call basic psychological needs, and that when we say basic, we mean basic. We need fundamental, scientifically. The example I use is in the same way hunger is a basic physiological need, right? Everyone has it. It doesn’t matter what culture, what age… It’s a universal need. If you don’t get nutrients physically, you will atrophy. When you do get them, you can thrive. We mean psychological need in that same way, and the need for autonomy is the need we all have to feel like we are endorsing the things we’re doing in our lives, that we are the authors of our story, that the narrative we’re telling, that’s both day-to-day and also the longer arc to our lives and what we’re pursuing, that we endorse, that we take ownership of.

Scott [00:03:42] The reason I say it’s often misunderstood is people sometimes will use synonyms like freedom or independence for autonomy. So well, autonomy is, “OK, so if you have autonomy, you could just do whatever you want to do.” That actually is not what autonomy means. Autonomy is this idea of endorsement. Even if I don’t have free choice and freedom and independence, I want to endorse what I’m doing, even within structures, even when there’s assigned goals and objectives that I’m trying to achieve, even if there’s other people I am dependent on and that I need, I can still be extremely autonomous and have that autonomy need fulfilled if I’m endorsing what I’m doing, I’m on board, and I have ownership of it. And that’s very important for the context we’re talking about today when we’re talking about the need to create complex technical software to meet the needs of audiences that we maybe have never met, to be able to translate goals into reality in terms of the things we’re coding and designing to bring together multiple disciplines. There’s a lot of structure there, there’s a lot of requirements there. We can’t define autonomy as freedom and expect to get the job done.

Paul [00:04:49] Yeah, that’s great. I think one of the things that you keyed into there, using the synonym of freedom is often the misnomer. It’s almost like there’s a freedom by having that restriction or having that adherence to the endorsement, rather. So when we think of freedom and total creativity, it can sometimes create a sense of being overwhelmed or being unable to focus or unable to accomplish the task at hand. And sometimes there’s actually more freedom in the sense of not being free. Paradoxically, I think autonomous experiences allowing users to accomplish the thing that they need to accomplish sometimes means restricting and focusing. What thoughts do you have on how product teams can start to solve problems in those kinds of creative avenues?

Scott [00:05:31] Yeah, it’s a great question. I think, just to riff on your point there, structure actually helps autonomy because it allows people to understand the shape of things, to understand the purpose of things. In other words, it gives that scaffolding for people to be able to have that sense of endorsement, to be able to lean in and have a sense of ownership for what they’re doing and what they’re about. If there isn’t that kind of definition, if there isn’t that structure, then people can be a bit lost. “What am I doing? What’s the purpose of this? What’s the goal? Where am I supposed to go next?” And that’s a hard thing that you’re in kind of this fog of war motivationally, and you can’t really endorse that, right?

Scott [00:06:09] And so this is where we immediately get into one of the first things we talk about when we talk about project teams is, “OK, why are we building this thing that we’re building? What’s the end goal? What’s the purpose of this?” This is directly to that point of building rationale or endorsement. Very often when we’re in these engagements as product teams, we’ll get the RFP. We’ll do the needs assessment. We kind of get into, this the requirements document. We call it the requirements document. And so even our language is, “all right, these are the tactical things that must be done.” And it’s very easy to kind of immediately be focused at that tactical level.

Scott [00:06:52] There’s a danger there that we’ll lose the opportunity to build that sense of purpose or rationale for why we’re doing this and always remembering to come back to how those requirements tie into that larger rationale or purpose. And that’s kind of a common theme and cadence on teams when you’re trying to build autonomy and trying to check in on autonomy, is, are those connections being made? And you can do that at both kind of a distal and proximal level. The distal level is, “OK, why are we doing this project overall? What are the whys? What’s the purpose? What’s the goal?” But then, even in your iterative cycles, if you’re doing some kind of sprints or agile, you want to make sure you understand, what are the things in the current sprint or in the current cycle? “How does the thing I’m working on also, what’s the rationale for that?” Even in the proximal goals that we’re trying to hit. And so you can apply this same idea at multiple levels of zoom, but without the structure, you can’t really apply that kind of cadence of establishing purpose and tying activities to purpose.

Sean [00:07:53] Yeah. So we’ve often in the past heard it referred to as like goals and guardrails. And you kind of mentioned this, but when you have very crystal clear goals that everybody signed up for and you have guardrails that are well understood, to your point, Paul, it allows you a significant amount of freedom about all those things you don’t have to worry about, and you can apply your creative genius to the things that are important, right? That’s the key. But it’s an important thing to note that without this autonomy, I see to my children, like when you don’t have it, you know it, and you get people moving in the opposite direction. When they’re feeling too tightly controlled, they end up showing up for a paycheck and you get apathy. And that’s the one thing that can kill any software product team.

Scott [00:08:35] Yeah, it’s interesting. A lot of times establishing a cadence of autonomy and having conversations that are focused on autonomy can seem like you’re moving in the wrong direction because it’s very easy. And this is the way businesses are run on so many levels and historically have been wrong, which is a command and control, “we need to get this thing done, here are the goals, we’re going to hold you accountable, we’re going to track your performance.” Not to say that accountability and performance… You know. Listen, we’ve all run businesses. We know these things are an important part of it. But what’s the interpersonal dynamic? To come back to the thing we started with is we’re dealing with people. We’re dealing with people as the end customer or as clients, as the people on our teams. What gets them motivated? What gets them engaged?

Scott [00:09:15] And a lot of times, for example, on a team, you might have somebody who’s pushing back against a particular structure. “I don’t understand this. I’m having this reaction to what’s happening.” And it’s very easy in those circumstances to lean into this assertion of the thing that must be done, right. “Well, we have to do this. You need to do it this way or we want to kind of get them back in the box.” I thought about this, Sean, because you mentioned your kids. And I know with my daughter, and I do this for a living, right. I find myself in that same kind of cycle. And then when I’m mindful for a moment of this dynamic and instead I just give the space to just let her have her feeling about it and not try to solve it. Let her complain, hear the objection, it’s like, “Yeah, I can understand how that feels very frustrating to you.” That immediately can unjam the entire situation. That’s all she wanted. She wanted to be understood. She wanted there to be this sense that she’s working through her own feelings and that, you know, this is just a sidebar, but sometimes we think about kids as like proto-humans, so one day we’ll shape them into being humans. It’s like, no, they’re humans. Like when you watch what happens with kids, it’s the same thing with adults, except we lose track of these sort of important dynamics. So it’s the same thing with the teams.

Scott [00:10:24] So, you know, giving the space to let people have their reactions to what’s going on can be a way to actually help that rationale and help that ownership. Another quick example I’ll use in terms of the balance between structure and choice or letting people kind of craft how they’re tackling things that also is related to working with kids is, you know, there was a famous developmental psychologist called Winnicott who came up with this term called a holding environment, and the holding environment was a way to sort of foster a healthy relationship, right, between kids and parents and help to build confident kids. And when we think about the people on our team, we want people to be confident because that’s where the creativity and innovation are going to come from. And the holding environment was about striking that balance between not being smothering and overly controlling, but being present. You mentioned the guardrails thing, Sean. It’s like you’re in a safe environment. You’re present. You’ve got structure to it. I, as the caregiver am there, but then you’re allowed to move around and kind of explore your environment and interact freely. And by the way, if you see kids in these holding environments when they’re young. One of the things that shows that it’s a really good holding environment, secure attachment, is that they’re trying things, they’re innovating, if you will, but they’re also looking over their shoulder. They’re checking out like, “Are you still there? Do I have the supports I need?” And that same kind of idea, I think, is important for all of us.

Sean [00:11:48] You used the word innovation. Like, there’s a clear relationship between actual innovation and ideas in the sense of autonomy.

Scott [00:11:55] Mm-hmm.

Sean [00:11:56] I think we want to build products that are more innovative for our end users and there’s a relationship there. So I think that’s an important thing to note. In the context of working with teams, any other recommendations or tactics that we might deploy that would allow us to maybe be a little more productive without going off the deep end with autonomy like Paul had mentioned earlier?

Scott [00:12:17] Well, you know, I think, again, I’ll come back to that idea of creating that optimal balance of structure with the ability for people to also have self-expression, which creates the space, right, for people to be able to be innovative and to create. And if you think about it, it’s like, the right amount of structure is the amount of structure that allows everyone to have this real clear sense of purpose and rationale and goals and also process, right? In other words, it decreases the cognitive load or energy of, “How am I supposed to interact? What am I supposed to do? How am I doing it? Who am I supposed to be working with?” And just playing on something you had said, Sean, it frees up that mental energy for people to kind of invest in the task. But we need to also give them the space to do that.

Scott [00:13:02] And I think that gets harder as organizations scale. And we know that there are these inflection points. I learned it the hard way. And like, I was a genius up until I had 20 people in my first company. And then I hit this inflection point and I was like, “Oh, we need some more structures here.” And once we figured that out, I was a genius up until about 50 people. I know there’s been some research on where these inflection points are based on anthropology and tribe theory, but I won’t nerd out on that too much. But you reach a point where just the natural interpersonal glue can’t quite move it forward, and there needs to be some structure. And I really struggled with that for a while as we got bigger. It’s one of the reasons why I haven’t liked the idea of growing another really big organization because having grown to past a hundred people, I see those dynamics and I also working with clients see as they get thousands of people that there’s even more of an issue because you’ve got to put more and more of these structures in place. And from a leadership standpoint, you tend to be focused on those structures. You also need to be building that process for people’s voices to be heard in that because otherwise they feel too constrained, right. And this is where the connection between leadership and that sense of structure and performance management has to be integrated with culture, has to be integrated with leadership development, all the way through down to kind of front line managers has to be put in place around the teams. This is why autonomy as a cultural norm is so important, because, in large organizations, you’re not going to be able to put it in place just from the C-suite alone.

Paul [00:14:36] Yeah, you hit on cognitive load and sort of the analysis paralysis there. And one of the things that I find most interesting, we’ve been talking about empowered product teams and sort of getting into how do we set up guides and guardrails for people to operate within systems that help them focus on tasks, requirements, documents, all these kind of things. But really, it’s expressed in the products that we build, the DNA of the organization, and more fundamentally, that ultimate connection back to the client who brings a problem to solve for the user. If the team building the product isn’t autonomous, it’s nearly impossible for them to build an experience for users that is allowing for autonomy at the end-user. One recent example that I read is the scientific and research and academic UIs that often you build are so engineering-centric. They have buttons and dropdowns and, you know, every option on the screen at once, and it’s actually impacting the speed to market of vaccines. So having a UI that is so free with all of the options visible and all of the workflows available and sort of any given path and a choose-your-own-adventure, that ultimately results in lives that are impacted because the people using the interfaces aren’t able to get their work done. So this whole thing has sort of a stacking effect.

Scott [00:15:52] Yeah. One where we use a lot, and embedded in this are a number of things from the Need Fulfillment Theory, but autonomy is chief among them, which is the idea of narratives. I mean, in some ways, I guess you’ve got, you know, in the agile process and you all are more expert on that than I am, but this idea of user stories. So you’ve got the idea of a story, you want to tell a story from this perspective and that perspective. But we do tend to use those more as tactical engineering goals or they do seem to get relegated that way. We talk a lot about, what are the tools for narrative building that each of the individuals can have? And the thing is that if there’s too much structure and controls, then I’m not building my narrative, I’m being told what narrative to plan. I’m being handed a script and I’m not given any opportunity to build my narrative.

Scott [00:16:38] And if you do that on teams, I think to your point, Paul, yeah, then you’re not going to see that flow through with product. And so we do a lot of work, for example, with gaming companies. And the games that are most successful are ones that do have a structure to them, that do help to put clear goals, telegraph future opportunities, all the things we’ve talked about. But they also have the ability or they give players the ability to create their own narrative, to give them choice about how they’re going to engage through multiple levels of features or ways in which the features are engaged or the path they’re going to take through those features or the things they’re going to emphasize or the way that they prioritize goals or choose goals. These can be important kinds of choices to give individuals about narrative building.

Scott [00:17:23] And so I think that’s one of the real pieces of work for development teams and organizations because it’s easy to always be in the weeds with the next thing that has to be done, and those are the kinds of work processes we put together. And again, this problem gets harder as organizations get larger. Where are we going to create those spaces for the people on our teams to build their own narrative? Right? So another word I’ll throw out here, which is more colloquial for this is growth. What are the growth paths for an individual? And we’re going to also talk about another basic need, which is the need for competence. And, you know, growth often gets slotted in the theory under the basic need for competence. But I don’t think that that’s fair to the idea of growth. I think growth is actually an interplay between autonomy and competence that then is potentiated by relatedness. But you know, there is a lot going on and as we look for new opportunities, right, because we want to express ourselves and build our narrative, and then when we get those opportunities, we want to master them so we can create yet new opportunities. And so there’s this interplay that goes on, which results in growth, but autonomy is really a key piece of that.

Sean [00:18:34] I love this concept of narrative building for people, and everyone needs to have their own narrative in like, “how do I fit into this broader puzzle?” Growth is clearly a big part of that. I’m going to switch gears. And Paul touched on it earlier when he brought up the analysis paralysis and too many features getting in the way and figuring out the right thing to build for your users. So I just want to ask if you have any thoughts in terms of, like, what mindsets to take when you’re looking at the user’s journey in the context of, like, business applications.

Scott [00:19:07] Right. So I’m glad you contextualized it to business applications because I think that’s an important framing versus some of the other things. If you’re looking at things like games or other things. You can create motivation in lots of different ways in business applications. We lean really heavily into, in the autonomy realm, to this idea of rationale right upfront in what’s being done, right. And in particular, we try to think about, how do we convince the person that’s going to be using this that they should want to use it for their own benefit, not just for the benefit of the organization or “this is a policy.” Something that I laugh about a lot is, how many times do we, even as customers at stores, we say, “Well, why do I have to do this? Why does it have to be this way?” And the answer we get as an explanation for why is, “Because this is our policy.” That doesn’t answer the question, right? But we hear this a lot because this is the thing that needs to be done. And, you know, sort of like, “I want to return this product.” “Well, it’s our policy to not accept returns.” It’s like, “well, it’s my policy to not keep broken products, so where do we go next?” Right? So really focusing on why, is again, what are those reasons?

Scott [00:20:16] You know, one of the areas that we’re in, I and you have some familiarity now with this product as well, is that in the employee engagement space, you know, we came into this just in the last few years. And what we saw is that, like, employees hate the annual employee survey and all these things. Like, there’s this real kind of like negative reaction to it in most companies because there’s nothing in it for the employee. You know, it’s really just an evaluative tool or they answer a bunch of questions and they never hear another thing or they get some vague meeting with their manager or with leadership. And what’s the rationale? “Why am I engaging in this?” So we’re constantly asking in business applications for employees to be doing these kinds of things, but we’re not spending even just a couple of minutes upfront saying, “here’s why we’re here, here’s why this is important.” And tell that story. Tell why they should care, right?

Scott [00:21:10] And so we spent a lot of time doing that and then trying to create iterative cycles that can also help with onboarding people and understanding the schema and the competence and training. This kind of goes into the competence realm of how to use the program by creating iterative cycles where we will create a cadence of, do a couple of things and then get some feedback. Kind of learn what this is about. But then when we introduce that next cycle of input feedback, again, give the rationale, right? So in other words, it’s a conversation. And again, we use the examples before, Sean, of talking about our kids and everything. So many times in developing these things, if we just stop for a minute and think about, “Well, how do humans interact most effectively? How do I like to be interacted with?” I don’t like, even if somebody is explaining something to me well and giving me rationale, I don’t like it if they just ramble on and on and on. I want to have some back and forth, right? So develop in that way too. So these are the kinds of things we like to see, particularly in business software where there’s not really a choice about whether or not to use it. There is a definite outcome. It’s like, “OK, this is being assigned to me.” So you’ve got to lean into these sorts of experiences around rationale.

Sean [00:22:22] All right, cool. So rationale, really getting into the head of the consumer. I think you’re tying in relatedness and competence a little bit in there. One last question, then we’ll we’ll wrap up this short episode. Any books that you recommend on autonomy specifically?

Scott [00:22:39] Well, honestly, it’s a little dense, but I am a big fan of the tome that came out from Ed and Rich, I’m not really selling it in very well, am I? It’s called Self-determination Theory, and I think that’s a book I’d recommend. It’s got a lot of different, you know, in-depth chapters on autonomy, both as an applied science, but also if people want to understand the underlying science, as well as applications of it into business spheres, into lots of different domains. The reason I’m thinking about that is that your audience, I don’t know exactly what they’re developing for, but if they’re developers, development tends to be kind of a horizontal thing where you might have a health care client or you might have an industrial client or… There’s all kinds of things that developers develop for. It’s nice to know how this same principle can apply across multiple domains. So it’s called Self-determination Theory by Deci and Ryan.

Sean [00:23:30] Yeah. Well, thank you, Scott. This was a great episode. I really enjoyed talking about autonomy with you.

Scott [00:23:37] Yeah.

Paul [00:23:40] Well, that’s it for today. In line with our goals of transparency and listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get, so please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.