Creativity Within Constraints: Walking The Tightrope Between Direction & Autonomy

Timo Hilhorst at UXDX APAC. Video: https://www.youtube.com/watch?v=l0YoNcyt6Mw

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.

Finding the balance between direction and autonomy

[00:00:00] Hi there. Thank you for tuning in. I wish I could be there today in front of you and actually stand up on the stage, which I would much prefer to recording this thing on Zoom, but I guess on the flip side, I get to do this presentation barefoot. So there's swings and roundabouts there. My name is Timo. I work as a head of product at Seek. I'm originally from Holland, worked in London for a number of years, and then I've been at Seek in Melbourne, Australia for the last two and a half years. For those of you who don't know Seek or haven't heard of Seek: Seek is a recruitment platform here in Australia and across APAC. It's a series of companies, and our purpose is to help people find jobs, to help them live their most productive lives, and help organizations succeed.

[00:00:55] What I'm talking about to you today is something that I'm really, really passionate about, and something that I find incredibly interesting and exciting, and probably the most important part of my job as a product leader. That's about finding the right balance between giving teams the right level of context that they need to be really impactful and creative, without constraining them too much and really taking away their autonomy. What I'm planning to do is to talk you through, just at a high level, how I think about this, and then I'm going to give you some examples that I've come across, that I've seen myself or experienced myself, where the balance was completely off and it really didn't work, and hopefully also some examples of where it did work.

[00:01:37] The first disclaimer there: I definitely don't have the answers here. This is very much a journey I'm on myself. A lot of this is very context dependent as well. But what I'm really hoping is to spark a bit of a debate, and I'd love to engage with you afterwards on the panel, or reach out to me on social media. One of the benefits of having a bit of an unusual name is that you get pretty good SEO on your name, so you can definitely find me, reach out to me on Twitter or LinkedIn, and we can have that conversation. I'd be really interested in that.

From waterfall constraints to empowered teams

[00:02:14] Just a really quick history lesson, and most of you will be very familiar with this, but we've really gone on a journey as an industry from being very constrained and very solution-upfront. In the old waterfall methods, in the big requirement documents, in very clear specifications, where there was actually very little room left for creativity of the people at the end of the journey, or the people executing the work: everything was defined upfront, very, very constrained, but very clear. And we've broken away from that to much more of a world where we're really trying to empower teams. Empowerment and autonomy have become really big buzzwords in our industry and have really helped a lot of product companies achieve a whole lot in the last 10 to 15 years, of companies moving more towards that.

[00:03:10] But what I want to talk about today is really about how to find that really good balance, because there is such a thing as too much autonomy and not enough constraints. Finding that balance is something that I have definitely found incredibly difficult myself, but very, very rewarding when you get it right, and you can really see how that helps teams do the best thing for their customers.

[00:03:34] When we talk about empowered teams, I do love quoting people like Marty Cagan on this thing. I'll just read out Marty's words here: "Great teams are comprised of ordinary people that are empowered to solve hard problems in ways their customers love, yet work for their business." Even there you can already see that Marty's touching on the topic of autonomy and of constraints. Talking about empowerment and people working out how to solve these problems, but also introducing the constraint that it has to work for the business. Even that is a constraint.

A thought experiment: five random things

[00:04:17] This is at a very high level how I think about the balance between constraints and how that can lead to more or less creativity. We start on the high constraint, low creativity part, the lack of freedom aspect. That is probably the easiest one for people to imagine. This goes back to the requirement documents, or it goes back to the highest paid person's opinion, where someone comes in with an idea and says, oh, I had a great dream last night and I worked it out in the shower this morning, here's what we need to do, can you go build this? At that point, a team working on that solution is completely reduced to execution mode. You're not really getting their level of problem solving, their level of creativity, beyond how do we deliver this predefined thing.

[00:05:06] But the low constraints part might be less intuitive for people, where often, when you hear people talk about autonomy, they really talk about that's the nirvana, that's what we should really be aiming for, and it doesn't really talk about the risks or the issues with that. I'd like to do a little thought experiment. Hopefully this works. It's very hard because I can't see what you're doing, so I'm just going to assume that this worked. If you could just close your eyes for a second and just think of five random things. Just five random things. Okay. If you do the same now, but now think of five random things that are white.

[00:05:55] What I hope you'll have found at this point, and we'll see — please let me know afterwards if that's not true — it should be a bit easier to do the second part, because we've introduced the constraint. There's suddenly a thing, you've got a mental model of things that are white in your heads, so you might have gone to a piece of paper, a wall, some milk, whatever. And it's easier to come up with that than not have any focus and have to come up with five random things. If you found the five random things quite easy, that may have even been because you've introduced some constraints yourself. You may have thought of five things that are in your room, like a chair and a table and a desk and a laptop. Even there, you've introduced a constraint yourself to give you more focus, to make the task easier.

[00:06:42] What I think is that there's really an optimal balance between these two where, rather than say think of five things that are white and you can see in your room right now and you've bought in the last week, which is very limited, then there's lack of freedom and it might be harder to come up with that; or think of five random things. There's this balance between focus and freedom. That is the thing.

[00:07:01] Now, it's really important to hear, I think, in a product company context, that the context of what you're working on here is very important. In some cases, a lack of freedom might be quite right. If there is a specific migration that needs to happen, or you're trying to remedy a security vulnerability, there are cases where the idea of making that commitment and simply delivering a predefined thing is the right thing to do. But hopefully, if you're in a situation where you have empowered product teams, that is the exception and not the rule. Usually what we're really trying to find is this balance where there is focus, but there's freedom in terms of having the creativity and the creative freedom to solve for those challenges.

Alignment and autonomy: crossing the river

[00:07:53] This is another way to visualize that. If we talk about alignment, it has to do with constraints, or getting very, very clear together on what the constraints are and what we are trying to do to solve this problem. And then autonomy. If we look at the bottom left, it's clear there is no autonomy, so teams can't decide what they work on, but there's also no alignment, so it's not clear what they're meant to be working on, and there's probably not a whole lot of stuff that gets done in that environment.

[00:08:21] If we look at the top left, where there is high alignment but lower autonomy, this again goes back to this predefined solution idea, where we've already decided we want to cross the river and we want to do that by building a bridge. All we need to do is get a team to build a bridge. They might be a bit creative with what that bridge looks like, but their creativity is still hemmed in a lot.

[00:08:50] Then if we look at the bottom right, which really is the case where you have the highest level of autonomy, where teams are not getting any direction, they can pick what they work on, but there actually are some constraints somewhere, because someone's thinking, I hope someone's working on the river problem. There is actually something that we hope will be achieved here, but hope is not a strategy, and that's what's happening here. Oh, I just hope that people will realize that's the right thing that we want to do.

[00:09:15] And then the top right, the example really where we want to get to, which is giving a team a reasonably clear objective, ideally with some context around it, but maybe explain to them why we want to get to the other side of the river, what's there when we get there, and then really allow them to figure out the best way how. Maybe it's a bridge, but maybe it's a ferry, or maybe it's a boat, or maybe we just teach everyone how to swim; maybe that's the fastest way that we can get there. Actually, if you look at this, there is more autonomy in the bottom right, but there's more focus, creativity and more impact in the top right.

Too many constraints: losing the team's best thinking

[00:10:01] I want to start talking about some of the examples that I've seen in my own career, or that I've come across in many of the things that I've read about this stuff. I want to start with the obvious examples around too many constraints, which leads to suboptimal solutions. I think the main challenge or the main risk here is that you don't get the full impact or the full input from the people on the team. When you work in a product or a tech company, usually you've got incredibly smart people in product manager roles, you've got incredibly smart designers and developers, and if you over-index on prefabricating the solution and they're just executing, you're only getting a part of their value, only a part of what they can bring. You only get those execution skills, but not creativity.

[00:11:02] The other part there is they might actually be better placed to solve this problem than you are. They probably are, because they're closer to the customer and they're closer to the product itself to really solve the problem there. This is one of the parts where Ray Dalio has this concept of believability weighting: if you have a debate and you can't really work out what the best thing to do is, there is a weighting on who is the most expert here. That is the thing that you lose when you take the ability from teams away to do that, because they actually are the experts on what the customer wants and what the product might be able to do and how the technology might work.

[00:11:32] One quick caveat here: this works really well if you're always right. If you are exactly right and you've come up with the best way to solve a problem, the quickest way to do it is not to get other people's input, or to do something small and test it with customers, or whatever it would be; it's to build it A to Zed and completely launch it. That is the fastest way to success, if you are a hundred percent right. Now, the truth is that with most ideas we aren't right, and we're not fully right the first time, and there's a lot of improvement that we can have from getting additional perspectives.

[00:12:17] I do find it quite interesting, as a side note, that we've never really had this side of the story as much from our industry, because there's got to be examples where someone came up with a great idea, told someone else to build it, and it worked. In those cases you might start believing that that is the most efficient way that you can do it. But it's more about those 90% of the times or more where your idea either won't work or it can be improved upon.

Faster horses, and blockchain everything

[00:12:45] Let's look at some of these examples. I'm going to start with a very often used example and take it to a bit of a different level, hopefully. The "build faster horses" thing always comes up, and it's always brought up as an example of why you can't ask customers what they want, because they don't know; people would have said, I want faster horses. For me, what this shows a lot more is actually that in those kinds of cases it's very helpful to get these kinds of insights, but you need to do something with them. You need to abstract them from the purely literal sense.

[00:13:13] If you gave this objective to a team, they might still do some very creative things, but it's probably not the most ideal way to solve the underlying problem. They might start trying to do some genetic manipulation on horses, or build a mechanical horse, or there might be a whole range of things. But actually what we're really saying here is, we want to reduce the time it takes humans to get from A to B. And there might be some more constraints, like we want to reduce the time it takes humans to get from A to B within a certain distance, or with a certain level of comfort, so you can't just fire them out of a cannon. There might be other hidden constraints there. But this is an example where initially we're constraining ourselves too much, because we're really anchoring ourselves to the ideas of horses rather than the problem that we're trying to solve underneath. If you were to give a team this level of objective, I think you'd get better results and more creativity and more impact if you went with the second option.

[00:14:22] To take maybe a more realistic approach, something that I've seen a lot in the recruitment technology industry, but all over in the last couple of years: blockchain has become really popular. We've gone back to a world a bit where it's mainly the financial solutions that are really being talked about a lot now, but a couple of years ago, basically it was blockchain everything. How can we introduce blockchain into whatever problem we're solving? It was really a solution looking for a problem.

[00:14:50] This was an example that you might hear about: building a blockchain based electronic medical record system. Very constrained already, and a constraint on the blockchain part that probably doesn't need to be there. So we think about, what could the problem be here that's underlying this that you're trying to solve? It might be, I want to create a secure way to easily keep my medical records and share them with selected providers. That may very well be the blockchain, some blockchain based solution is the best way to solve this.

[00:15:21] Marty Cagan uses a similar example in his latest book, around maybe if you want your customers to use your product on the go, the right thing to do might be to build a mobile app. But rather than start a team off there, why don't you start them with, I want our customers to be able to use our solution on the go? Because they might find that actually, for the solution you have, a website that works well on a mobile might be good enough, or there might be other ways that you might be able to solve it. By constraining yourself into a specific solution you're actually potentially selling yourself short on some level of creativity that would lead to better outcomes.

Not enough constraints: the hackathon startup

[00:16:02] I'll talk a bit about an experience that I had that was really important to me, where actually there were not enough constraints, and when I look back on it there was a lack of focus because we had too much autonomy. When I was working in London, I worked for a company that was really interested in diversifying their business. We had a lot of really, really amazing people in our team, and they'd be reading The Lean Startup and The Innovator's Dilemma, and they came up with this idea that we really needed to foster this innovation within our own business. We needed to find our next growth business, and it was going to come from within the business, and they wanted to empower our teams to come up with that. So they organized a hackathon where we were asked to come up with a business idea that the company could invest in, and the winner of the hackathon would get an opportunity to actually create a business case and get funding for this.

[00:16:59] I was lucky enough to be on one of the two winning teams, and we came up with this idea to effectively build — you'd probably call it LinkedIn for startups, but it was really this idea of founder dating, that was still quite new at the time. We were seeing London was starting to be this budding ecosystem of startups, and we really saw that lots of people didn't really know what to work on or who to work with, or people had great ideas but not really the skills to make them happen. So we built a platform to really bring those people together.

[00:17:32] What was interesting was that when we started doing this, we were very clear to say, this is a group of customers that are very cash poor. These are people that haven't even started their business yet, so this will be a difficult audience to monetize. But we think if you can grow this enough, there are multiple different ways that you could make money off this. You could sell add-on products, you could start selling recruitment tools to people who actually would get their startup off the ground and would need to start growing their business. You might link it in with an investment platform. There's multiple, multiple different ways you can do this, but in order to do that we need to build this audience up first. At the time, that was hidden constraints.

[00:18:21] The business loved this idea and they said, great, you can have three months. They put us in a small office. We basically got full autonomy to run at this idea and prove that it could work, with the only constraint being you've got three months, and after three months you have to come back and pitch for more investment, or tell us that you failed and what you learned. Again, a great setup in theory.

[00:18:43] After three months we had exceeded our expectations. We'd created this platform, we were starting to get real traction without really any marketing. We had about 10,000 users from all over the world that were starting to form these groups on the platform and started to just send each other messages. There was still a lot to be proved around the real value of it, but all of the signs were as positive as what we could have hoped for after three months. So we went back to our board and pitched for more investment, and interestingly, the pushback was much more negative than what we thought, because they said, oh well, we can't really see how you could really make any money off this idea in a reasonable timeframe.

[00:19:26] It turned out, without realizing it, because this was so new to us as a company, there was actually this unspoken constraint that these new businesses had to have a clear path to profitability in a fairly short timeframe, shorter than what some of the other startups that we'd be seeing pop up had. It was a constraint that was unknown, but it actually meant, in retrospect, as much as I absolutely loved the work that we did, we wasted three months with a small but quite talented team when we could have done something else.

[00:20:04] The other idea that won this hackathon, they basically built Airbnb for office space. Now it would probably be quite popular, with more and more people getting rid of their office space, but it was the idea that you could rent a meeting room or a desk in someone's building. Again, maybe not the right timing, but a pretty novel idea at the time. What turned out was that we actually, as a business — I was working for Reed.co.uk[?] at the time, so we were an online recruitment platform — we didn't know anything about real estate or renting out office space. We didn't really have any competitive advantage to being the one starting this idea. So while this was an idea that probably had some legs, there was no reason why we could do a better job of it than anyone starting out in their garage, or any other company.

[00:20:50] Once we realized that — this is a really important learning curve that we went on as a business — there were actually two really clear constraints. The brief initially that we probably would have done a lot better with would have been to come up with a business idea that is adjacent to our core business, that gives us an unfair advantage, and has a path to profitability in the first two years. There's still heaps and heaps of room for autonomy, for teams to figure out what this is. There might be hundreds of ideas that you could pursue here, and there are also thousands of ideas that with these constraints are no longer viable, and so you wouldn't even try to achieve them.

[00:21:31] That was a really clear lesson to me. Not just that it would have been really helpful from a leadership point of view if we'd had these constraints explained to us, or if we'd even realized them as a business, but also for myself, as the product manager involved in this idea and the person pushing this new startup idea, that in retrospect I should have spent more time trying to uncover some of these constraints. It's great to get this complete blank page and this complete autonomy, but really I should have asked some of these questions to say, hey, if we come up with something crazy that's going to take us 10 years to make any money off, if at all, is that out of balance? If it's completely foreign to what we do as a business, is that out of bounds[?]? That's really where there was too much autonomy, too much freedom here.

Clear constraints without presupposing the solution

[00:22:26] And then finally, let's talk about some examples of where I've seen clear constraints without presupposing solutions, where I think the balance was right. There's a question mark here, because one of the things that I would love to get out of doing this talk is for people to engage afterwards and give their views and say, actually, I don't think that was quite right, or maybe you could have given the teams more freedom, or maybe you should have put in some additional constraints. But these are some examples of where I think I've seen this work pretty well.

[00:22:51] In the recruitment technology industry, integrations and third-party systems are quite a big challenge for a lot of the recruitment platforms. When people post their job ads on Seek or LinkedIn or Indeed or any of these platforms, a lot of customers use an applicant tracking system to manage the applicants that they get through, rather than the platforms where these applicants find the jobs themselves. What we were seeing — this is still when I was part of Reed.co.uk in the UK, and this was the future evolution of what we ended up doing with our innovation space, once we'd realized that introducing some more constraints would work better.

[00:23:39] What we'd realized is that a lot of our smaller and medium-sized customers were graduating off our platform onto these third party platforms that didn't have great integrations with our systems, and so they were losing a lot of the value[?] or the benefit of using our product. What we could also see was that the applicant tracking systems that they were migrating to probably were far too complex for what they needed as a business, but all of these extra features and tools allowed these applicant tracking systems to really sell that to that customer. So we had a theory that if we created a much more lightweight applicant tracking system that was not as good as what was out there in the market, but good enough for this audience, then we might be able to stop them from migrating to these third party products and actually have them use our own alternative.

[00:24:32] What we were given as a challenge by our exec team was to provide an alternative, or prove that this could work, that would attract smaller and medium-sized customers who were looking to move to their first applicant tracking system. There's clear constraints here to say, we've already identified the group that we want to go after. This is not for our big corporate customers that have hugely complex needs, that will pay lots for an applicant tracking system, where the market's actually quite crowded. We think there's this underserved part of the market that, while they're underserved by our platform, they're overserved by the existing solutions, so we think that there is an opportunity to disrupt the market from below here.

[00:25:15] I think this is a really good example where we had enough of the context and enough of the steer to really focus our efforts, but still lots of freedom to get really creative on how to solve this. This didn't talk about the features this thing would need, whether it would be free or you would sell it, how you would go to market with this. There was a lot of room for creativity, but still a lot more focus on the constraints that we'd already identified and the theories that were behind that.

Making something worth paying significantly more for

[00:25:50] This is another example. This is actually from one of the teams that I worked with at Seek, and again, as you can see, these integrations with third parties are a big challenge in the recruitment technology space. We had a feeling that if some of our products, or a specific version of our products, was better integrated with our customers' third party systems, it would create so much efficiency that they would pay significantly more for it. This really came through our sales teams and through our own conversations with customers. There was an opportunity to monetize this if we solved the customer problem a lot better.

[00:26:28] Now, I think this is a really interesting example, because as an objective it's not particularly inspiring and it's not super customer focused. It's saying, hey, can we get customers to pay more? But actually what this did with the team — and this is why I think it's a really good example of the right level of constraints while giving teams enough freedom — firstly, there was a constraint there, that we already had evidence to show that we thought integrations were part of the solution here, but we didn't really know what else would be included.

[00:27:03] And what the product manager told me afterwards was really helpful here. We started to say, we want to aim to create something that is so valuable that customers would pay significantly more for it. Rather than go very incremental, which is some of the challenges that you sometimes might have with the way some companies have implemented OKRs, for example, where you say, oh, could we lift engagement with our product by 5%, or could we lift this by 10%, and you start thinking quite incremental and quite small — whereas this made it very clear to say, this thing can't just be a bit better than what we have today, because otherwise the switching costs, and the actual cost, would be too high.

[00:27:44] In order to create something that people would actually want to pay more for, we'd have to really identify the pain points that we'd have to solve to basically make a 10X better product. That's really what this allowed the team to do. So while the objective itself doesn't sound overly exciting and overly customer focused, it actually allowed them to completely double down on customer discovery, figuring out what the big pain points were and then how do we solve best for that. It actually led to a huge amount of creativity.

Walking the tightrope

[00:28:24] Hopefully you found it useful seeing some examples of walking this tightrope, and it's so hard. Finding the right level of context, versus not going too far down the solution path so that you end up with teams building a solution where they could have actually come up with something much better. It is an eternal battle and it'll always be very difficult. But I'd love to hear from people, to see if these examples resonated, to see where it's worked well for you, and especially if you disagree with some of the stuff that I've said, I would really love to start a conversation about that.

[00:28:58] I'll come full circle and, as I started, finish with a quote from Marty Cagan, to say: empowered teams need the business context that comes from the leadership, especially the product vision, and the opportunity to figure out the best way to solve the problems that have been assigned. That is really where I think Marty really hits the nail on the head, in terms of the balance. There is top down direction in terms of the language — the problems teams have been assigned, that is very much a directive. They obviously need the context of why those problems are important and how they fit into the rest of what the business is trying to do. And then it's really about allowing the teams the opportunity to figure out what's the best way to solve it, in a way that makes customers really happy and in a way that works for the business.

[00:29:56] Thank you very much for listening. Hopefully you found this interesting, and I'm really looking forward to getting some of the questions for the panel later, or feel free to reach out to me if you had any other thoughts. Thank you.