03: Want Happier And More Productive Employees? Give Them Autonomy
03: Want Happier And More Productive Employees? Give Them Autonomy
Speaker 1: All right. So today we're going to talk about autonomy, which is a big thing that you preach in addition to the way that modern software companies should be built. What is autonomy? Why is it so important?
Speaker 2: So I think autonomy is super important for lots of reasons. Most important reason is that I think it's the best way to get the very best performance out of people. And if you talk to most engineers coming out of school today, their desire is to have autonomy, to have purpose. And that is what drives them, as Daniel Pink would say.
Speaker 1: So showing up to work every day and saying, I own this thing and it matters if I do it or not.
Speaker 2: Absolutely. So everyone needs to feel like what they're doing matters and that they have a vote in what they're doing and that they have that purpose for doing this. And I think the best way to do that is through autonomy.
Speaker 1: So autonomy was a big thing that you preached with the product team at HubSpot. I think you guys actually had the highest employee NPS score or something like that. And then the exec team said, why is this? And can you present and share this with the rest of the company? So share that story and how that whole thing came about.
Speaker 2: Sure. It was an interesting experiment that at HubSpot on autonomy within the product team. And so we went about designing a team from the very foundation that was based on autonomy, right. And what that led to was productivity that like I had never seen before my career, employee happiness like I had never seen before, and that HubSpot had never seen before. HubSpot has always been voted as one of the best places to work, but all of a sudden through this change, the product team shot up and had the highest NPS ever within employee NPS within HubSpot. And I credit that to autonomy. And I credit that happiness and drive within the team towards autonomy.
Speaker 1: And you've kind of figured out, so this autonomy was a big thing, but over the years, you've kind of narrowed it down to say there are really five key ingredients to creating a autonomous environment. What are those things?
Speaker 2: Yeah, it took me a long time to have enough experience to actually be able to look back and say, what were the ingredients that actually worked and didn't work. And I think there are five key ingredients to creating an autonomous environment.
Speaker 1: The first one?
Speaker 2: The first one is the most important and that is to be customer driven. And so that each person on the team and every team has to be driven towards customer success. And what that means is that they have to be spending time with customers continuously, from the very beginning of designing a product, through shipping a product, to maintaining and enhancing a product, they have to spend time with the customers. They need to consistently wow customers, and they need to increase their product's usage and adoption metrics over time. And that's how we measure and make sure that each team is getting better at becoming customer- driven.
Speaker 1: So you don't get the privilege of autonomy without being able to base everything that you're doing in customer feedback, customer data, or just getting a pulse of the customer.
Speaker 2: Without the customer at the center of your organization, of your process, you cannot create autonomous teams.
Speaker 1: So first one is customer- driven. Second one is accountability.
Speaker 2: Yep. So the second ingredient is accountability and it's tightly linked with being customer- driven, right? A lot of people, when they think about autonomy, they forget this ingredient, which is accountability. And without accountability, autonomy without accountability is just anarchy. there cannot be autonomy without accountability.
Speaker 1: And you said that this is the one that people get wrong the most. Just because your autonomous doesn't mean that you can go do whatever the hell you want to do.
Speaker 2: Absolutely. So this is the ingredient that you have to watch out for. This is the one that people get wrong all the time. And so they think autonomy means I get to do whatever I want to do. Again, that's just anarchy. What you need is accountability. And the way that we drove accountability was through using metrics for each of the teams that were based on the customer. Is the customer getting happier over time? Is the customer using the product more and more over time? Is the customer referring new customers? All of these metrics were ways that we were measuring teams and making sure that they were being held accountable.
Speaker 1: And the thing that always seems to destroy this is if you're not accountable, what ends up happening is you might shift something, you might do something that breaks, or there's a negative reaction and everybody's gut right there, so just point fingers.
Speaker 2: Yeah. So accountability is not only at the team level, accountability starts with personal accountability. And so key to getting this to work and making sure that it's working is paying attention to whether you're starting to see finger pointing happening within the team. So finger pointing and excuses destroy autonomy.
Speaker 1: This is one of the reasons that you're in that model, one of the resources that you said was okay, this is why product have a dedicated designer instead of a shared one.
Speaker 2: The key to this whole model working and autonomy working is that everyone working on a team has to be dedicated. And so the shared model, whether it's shared designers, shared product managers, shared engineers, doesn't work. That destroys the autonomy model. And so you need people on the team who are dedicated and once they're dedicated, they need to be both personally accountable, but also accountable as a team.
Speaker 1: Third one is transparency, and you're a big fan of over communicating goals, over communicating everything that's going on.
Speaker 2: Yep. So the third ingredient to make this work is transparency. And so we have to default towards transparency and each team, and each person on that team, has to over- communicate their goals, their performance, their ideas, their concerns with the entire company, with the team and show exactly what they're working on. One way that we increase transparency within the greater organization at HubSpot was to implement something that we call show and tell. So we had a monthly show Intel that we called the science fair, where each team had to go up and they had to show what they had worked on in the last month, and what they had to show had to be out there being used by customers at the time of showing. So no demo ware, nothing that worked on their laptop, nothing that was in staging, no prototypes, real stuff that real customers were using. They got to show that in front of the entire company. And by doing that, that increased transparency and let the other teams become more comfortable with the lack of roadmap, with the lack of version numbers or with the lower planning process than they might be used to, because they were seeing each month how each of these teams were impacting customers.
Speaker 1: Autonomy is a great way to work, and it's almost a privilege, but you don't get that if you're not going to be transparent about the things that you're owning and touching.
Speaker 2: Yeah. Without transparency, you can't have the autonomous model.
Speaker 1: Fourth one is having an iterative approach. So this is similar to the way that you think about building modern software teams. This isn't spending five weeks planning something, and then working on something, this is the same listen to customers and iterate.
Speaker 2: So I think the second ingredient, accountability, is the one that people get wrong the most. But the fourth ingredient, the iterative approach, is the next ingredient that most people get wrong. And this is something that, again, inertia plays into this and most teams start to default towards wanting to ship one big thing, instead of taking an indirect approach and shipping things as soon as they are able to be shipped, putting them into production, and letting real users start to use that. It doesn't mean that every one of you users have to be exposed to this. You can have beta users and alpha users, or you can target certain features to just a subset of your user base, but you need to get it out there and you need to iterate, because in almost all cases, you are not the customer. Even if you start out being the customer, building something for yourself, after a certain point, you stop becoming the perfect customer. And so you need to have this iterative approach to figure out what we got right and what we got wrong. I fundamentally believe that whatever decision we make, whatever feature we ship, it is wrong. By default, you are wrong. All you have to figure out is how wrong are you? Are you 10% off? Or are you 100% wrong? It's usually somewhere in between. And so the quicker that you get out there and the faster that you iterate, the faster your chance to success.
Speaker 1: But on the flip side of that, you also think that you can't interpret being iterative and talking to customers as something that means you should spend four or five weeks, months lost in conversations with customers. You need to get the right amount of data to make a decision.
Speaker 2: Yeah. So being iterative is not just in shipping the software, but it's also in any of the planning and talking that you're doing with customers. You need to get out there as soon as possible. And so time is our enemy. We're working against the clock, we need to get stuff out there as soon as possible. So just go out there, get some feedback, then iterate and put it back in front of those users and customers, because no matter how good you are talking to customers and interviewing customers, customers, can't tell you what needs to be built. They are not engineers. They are not designers. They are not the ones building the product. And so you need to go out and build a prototype as quickly as possible and get it in front of them and get a reaction.
Speaker 1: Fifth one is actually one that you recently added is ownership. Why is ownership so important as part of this approach?
Speaker 2: The fifth ingredient, and one that I just added recently after looking back at what had worked and what hadn't, is ownership. And so the ownership ingredient was key to getting this model to work, but one that took me a long time to really figure out and realize that this was one of the kind of hidden secrets in getting this model to work. Ownership is so important because most teams, most companies will regress at some point. And when they regress, they will move back to some portion of the team moving back to a shared model. And again, if you have people who are shared, you have shared resources, whether the designer or product manager and engineer, whatever the model breaks. And so we have to have clear ownership in the model for it to work.
Speaker 1: So even as you're growing, it's important to still default and say no, we need to keep these teams small.
Speaker 2: You always have to keep the teams small. And so as you expand and you scale your company and the problems expand, you have to be focused on building more teams that have ownership over different parts of that problem.