Rerun: How to influence without power – Tim Herbig on The Product Experience

Hey everyone. Welcome to The Product Experience. Randy is on holiday this week, so we are going to fly back to one of our very first episodes with Tim Herbig from Hamburg, who taught us all about how to manage upways, sideways, and downways.

The Product Experience is brought to you by Mind the Product. Every week on the podcast we talk to the best product people from around the globe. Visit mindtheproduct.com to catch up on past episodes and discover more.

Browse for free, or become a mind the product member to unlock premium content, discounts to our conferences around the world, and training opportunities. Mind the Product also offers free product tank meetups in more than 200 cities, and there’s probably one near you.

So, hi everyone. First of all, thanks for having me. My name is Tim Herbig, I’m from Germany, so my name is typically pronounced a bit different, but I’m making it more easy for all the English speakers out there. Herbig, it’s fine. I am essentially someone who loves to build products. So I started doing product management, in some sort of way at least, back in 2010 at a smaller performance marketing agency in Hamburg in Germany. Then I evolved through multiple product roles, either in big publishing companies, super small startups, for example, we tried to disrupt the docs hitting market with a small app, which apparently failed. But I also held product roles, for example at XING, and for those of you who are not familiar with it, it’s pretty much the German LinkedIn, so to say, where I was responsible for the premium membership’s largest B2C revenue source as a product manager. Then I went on to pursue some smaller startup roles again.

And now my day is pretty much two-sided. On the one hand, I lead the overall development and all the other efforts of Iridion, which is an AB testing platform, as the Director of Product, and on the other hand, I do things like writing books, which I wouldn’t recommend to everyone. I talk a lot about product management at various conferences, write about it, workshops, keynotes, that sort of thing. So that’s the super Tim-in-a-nutshell version, I would say.

Because you teased us, and I’m going to bug you about the pronunciation of a different German word later, but how would you normally pronounce your name?

Herbig. But the thing is, I have a dispute even with Germans because most Germans say Herbig, and I try to insist on Herbig. So it’s super complicated how you pronounce the G. I’m sorry.

More relevant. So you just published a book about lateral leadership. So what is lateral leadership and what made you write this book?

So lateral leadership essentially describes the situation many product people find themselves in, in which you have to influence other people, whether it’s your team members, or your stakeholders without having any formal authority over them. So typically you’re not entitled by your salary, your hierarchical level, or your job title to demand certain things from people. The problem is that most managers, on the other side, have established their traditional way of thinking of hierarchical tools to get what they want. But as a product manager, you can’t rely on denying vacation days, or screaming at people to get what you want, so you have to be a bit more creative with getting buy-in from people to a shared vision, I would say.

So this is essentially lateral leadership, and how I arrived at talking and writing more about this topic is essentially that, probably every product manager can relate to the concept, but for most of us, at least from my experience, it’s hard to put it into exact words what it is, what is the situation, what’s the challenge we’re having? And so when I first heard of the term “lateral leadership” and understood what it is about back in 2014, I was super relieved because, “Wow, great, there’s a name for my problem, finally I can give it a name.”

And so over the years, naturally, I was in the situation of having to lead people without formal authority. And then as time went on, and I progressed through various challenges of that in my own product management roles, I did a brief stint in a consulting company where I had the opportunity to observe many, many companies being in this transition towards more agile processes, agile team setups. And I recognised this gap of not only adopting agile processes like sprint planning or estimating using story points, stuff like that, but also thinking about what this adoption of agile processes means for the people working on these agile teams, meaning, how do they lead each other, and which changes are required to succeed with that?

And so then when essentially one and a half years ago already Jeff Gothelf and Josh Seiden opened the new publishing platform Sense & Respond book, I felt like this was the sign I have been waiting for to go a bit deeper on this topic, primarily because I also felt from many conversations I had with product people that very few of them are actually aware that they have a leadership responsibility because it’s not in their official profile, yet the implicit expectation from the environments and the stakeholders is that they step into this leadership responsibility, but they have by no means any education about which tools or skills are needed for that.

Was there a time where you just absolutely failed in this and it had a bad effect on your job?

Yeah, I would say at least 50% of all the jobs I had. Because the problem with lateral leadership, or the main challenge is that it’s so unique depending on the environment you’re operating in. So you can apply or you can be aware of a certain set of, I don’t want to say standard, but default tools, which probably help you dealing with the challenge, but they always have to be adapted to the environment you’re operating in.

So for example, my first real scenario where I was challenged by that was when I worked at the publishing company, one of the biggest ones in Germany, and the editorial staff was basically my main stakeholder. And it took me quite a while to figure out, “Okay, how can I demonstrate empathy to them so we can relate to each other and have a better understanding about the challenges of my job and their job, and thereby establish just an overall better relationship with each other?” You have to think about completely different things when you try to establish empathy with developers, or engineers, or even marketeers in a more product-driven company. So I would say it took me at least 50% of the time of all of my jobs to figure it out again and again, how I could apply the essentials of, hopefully successfully, leading people without authority.

And I think there’s a balance, isn’t there, between micromanaging people, and then giving people so much space that they feel a bit abandoned. Is there a way that you strive or aim to reach that balance?

Yeah, so I think maybe just briefly picking up what you just said, I think that perfectly describes it, because the problem is that, as a product manager, you’re typically a generalist who has to operate or has to work with domain experts. And a natural reaction for every person probably when you are faced with something you just don’t understand, meaning you can’t practically do that thing, like writing, coding, designing, you react with more control, you want to go deeper into it to have a better understanding y. It’s hard for us to accept this uncertainty and just stay on the sideline. And this is what would typically lead to the micromanagement aspect, meaning, in order to ensure that developers are really producing great tickets, my descriptions have to be more granular. Needless to say that this will cause lots of pushback from your team. And on the other hand, of course, you still want to show that you genuinely care about the work, that you are involved, that you are present, but just from the right distance.

So I think we were going to talk about, especially as Randy teased, the other German term already, we will talk more about the whole aspect of aligning on the actual what needs to be done within a team. But one of the most important aspects for me has been, in the past, when it comes to establishing empathy with the people you’re working with, and simply developing a more shared understanding for the challenges of one another beyond a typical project or a specific scenario. It’s just try to get yourself involved in the communities of practise you’re working with. And it could be as easy as attending a local meetup for iOS developers or engineers, or maybe you have even internal meetup at your company where you could just sit silently in the corner and observe the discussions which are going on within this community of practise. And the goal is not that you become a better developer or designer yourself, the goal is simply to enable yourself to ask better questions and have a better understanding of the context of the people you’re working with, and on the other hand, by showing that you care, gaining a bit more credibility when working with them.

I think that’s really interesting, and certainly with some of the developers that I’ve worked with, you will have some who want to understand the problem and they’ll say to me, “Tell me what the problem is and then I can help come up with the solution or the task,” or whatever. And then you’ll have others who obviously have been used to being micromanaged much more tightly, and I prefer to work in a slightly more distanced kind of way. I don’t like to micromanage people, I like them to feel empowered. So there is that element of coaching that you need to do, and helping them work through, “I’m not going to tell you every single thing that needs to be done. You have to bring your own self to it as well.”

Absolutely. And I think the challenge is that oftentimes, for example, when you take over a new team, maybe it’s not clear in which environment the team you’re now working with has been operating in in the past, so maybe they have been educated to only do what they have been told in a very distinguished and granular manner. And so you might receive some pushback when you start opening up the space they can operate in because they say, “No, we don’t want to step into the space because additional space means more responsibility. We’re not ready for that. We haven’t be educated to behave like that. We want the more granular descriptions.” And so it will take some time until they will accept this additional space of freedom to create.

Yeah, and it’s really healthy if you can get to that point. I think

Before we jump into some of the techniques you can use, is there a way that you can diagnose whether you’re being effective as a lateral leader? Are there typical warning signs or signs of success?

I think one warning sign would definitely be what I just described in the beginning, that if people resignate, and just ask for more granular specs to simply get their job done. So I think this certainly would show that you have established some sort of very unhealthy hierarchy within your team, which goes way beyond just the shared responsibilities of just… Because people would then say, “Okay, we’re always doing what Tim says anyways, so why should we bother discussing additional topics?” So if you observe this resignation, I think it’s a sign that you have you behaved too dominant, and rather applied more hierarchical tools in trying to establish your own position. I think this would be one thing.

And on the other hand, I think another warning sign could be that you never… I don’t know if it’s a warning sign, but it’s that you never are in the situation of discussing personal measures with your people. Do your team members, your peers, feel safe about opening up what really makes them struggle on an everyday basis as well, at work in the environment you have created? And because I think that empathy is such an important aspect, opening up about what really worries you at the moment or makes you succeed or drive is an important aspect you should create.

So one of the things you cover in your book is how to set a mission or goal for the team to give everyone a target to aim towards. What tools do you use?

There’s certainly no shortage out there when it comes to tools for creating a shared understanding within your team, and creating alignment. But one of the tools which has worked for me pretty well over the last years is called the mission briefing, that’s not my terminology, it’s after strategy consultant called Steven [inaudible 00:13:12], who wrote a whole book on this topic, not specifically in the terms of product but more in general. And so he has come up with this super dense, in short, concept of the mission briefing. And maybe just one or two words on why I think such a framework is important.

The problem is, as we discussed earlier, the situation you’re in, you’re the generalist working with the domain experts, the problem is that even though you think you all have the same understanding about what needs to be done, everybody’s using their own jargon, has their own understanding, everybody’s caught inside their own bubble. And so the biggest challenge for creating a shared understanding about the mission ahead, or what needs to be done, is to develop a shared language, and speak in the same language and articulate the path forward together, and craft it together, not just see it as a top-down document.

And so I’m talking more about this mission briefing, and the goal of the mission briefing is essentially, as I said, to create shared understanding about the mission ahead, meaning the what. And one of the underlying beliefs is that ultimately product teams thrive for autonomy. They want autonomy from their bosses, on the one hand, to act on their own and succeed at a mission hopefully, yet at the same time, this idea of autonomy holds also true for people within the team. So developers, designers, whoever’s part of a cross-functional team also wants pretty much autonomy from the other roles to simply succeed at what they are specifically hired to do. So you want this autonomy. And the degree of autonomy you can get, whether it’s within the org or your team, highly depends on the clarity you have been able to create upfront.

And so the mission briefing is a five chapter, five area sort of document which ideally fits on a standard sheet of paper, and basically walks you through five parts. And the parts consist of, on the one hand, it starts off with, describe the context, what’s the situation within the company? What’s the situation out there for the markets? And what’s the problem with that? What’s the trigger? Why should we act on that? Then you also have to make sure that this initiative, this project you’re pursuing somehow fits into the overall strategy of your company. So what’s the higher intent of the company for this year maybe? How does this fit in?

Then you’re going to talk about, “Okay, what is actually our intent as a team? What do we want to achieve? And it’s there, of course, important to focus on changing user, or business behaviour, not listing specific features of products, but you should also somehow be able to articulate, when are we successful? What kind of measures of success are we pursuing for this project? And then it’s about listing, basically, something like the key implied tasks which are not really tasks, so the word might be a bit misleading. It’s more about pointing out which blind spots do we have ahead of you, and which one should you take it first? What are your most critical hypotheses you should pursue?

And last but not least, and this is probably one of the most important ones when it comes to using this tool to provide actual guidance, is the notion of boundaries, and boundaries are two-sided. On the one hand, it’s about saying what is not allowed to happen as a side effect from this project, which metric is not allowed to go down or up. And on the other hand, also explicitly listing what you’re not going to do, for which platform are you not going to build a product? Which user group won’t you serve with this product? Stuff like that. So the combination of these five areas completes this mission briefing format.

Thank you. That’s a really good overview of it. When I looked through the book, I was, in my mind, comparing it to what Teresa Torres does with the Opportunity Tree, and it’s a different idea, it’s a slightly different purpose. And just for anyone who doesn’t know the Opportunity Tree, there’s really great videos that Teresa has done on this, and it’s worth searching out. But it’s a similar type of structure that you’ve got, a corporate vision, or product vision. You’ve got longer term goals, you’ve got shorter term goals, quarterly, or OKRs, or something like that, that generally come top-down in terms of strategy. And then you’ve got things bottom-up of your backlog, and the epics or features that they align to. And it’s a really great tool for illustrating alignment for work in progress, and strategy, and where you’re going to. Would you see these as complimentary, would you use them together?

I think I would see them complimentary because at least this is my understanding of the Opportunity Tree, is that it helps you also to structure your ongoing efforts, for example, during a discovery phase or stuff like that, compared to the mission briefing is really about framing the beginning, and then letting you pursue the mission. So I think this is maybe, if you compare it directly, one of the benefits or the advantages of the Opportunity Solution Tree, that it also helps you to structure the ongoing efforts. That’s how I would see it.

So you might create a mission briefing at that tactical level or even at the strategic level to define.

Yeah.

That makes sense.

Are you ready for Mind the Product San Francisco Conference happening in June?

If you’ve been before, you’re probably feeling a bit like me desperate for your MTP Con fix. And if you are new to it, this is the product conference not to miss. If you’re a product person looking to advance your career, expand your network, get inspired and bring the best products to market, then this is for you.

So what can you expect? Well, MTP Con is known for their epic lineup of speakers, renowned product leaders with invaluable insights and tactics to share. They cover a range of exciting topics that will challenge and inspire you to step up as a product manager, always with something tangible to take away into your own product practise.

And don’t let location hold you back. Even if you can’t join in person in San Francisco, you can still be part of the action with their convenient digital only option.

This event is a must attend for anyone seeking to elevate their product management game, find out more and book your ticket at mindproduct.com/san-francisco.

So who would put this together? Would this be the product manager with the product team, or do you have to work with broader stakeholders?

So I think of course the favourite answer of every product manager is, it depends, but ideally let’s say the final document you would commit on as a team to frame the mission ahead should be crafted together as a team. Because, as I said in the beginning, involving these different perspectives you have on the team is only possible through collaborating on it. So it might be the case, or it might be helpful that… Or this is, for example, a scenario how I use it. When I have a new idea, or in the very early stages of an upcoming discovery, I use this format to structure basically my own thoughts. It helps me bring clarity to my own writing, to my own thoughts, and I write it down. And then typically we do another iteration within the team where I might even hold back some of my input to not giving them any sort of bias towards the additions I made to the mission briefing. And if you have crafted a first version, you should also run it by your boss, and your boss’ boss, to get the alignment of like, “Hey look, does this really fit in into the overall company strategy? Do we have buy-in for pursuing this path?” And stuff like that. But ultimately, it should be something the whole team buys in to.

And what happens when you don’t get buy-in, or when you get a misalignment?

Ideally, if you have a misalignment, I would say you should rethink if you should start the project. But I think one of the biggest confusions I see when it comes to creating alignment is that people confuse alignment with agreement. And there’s this great quote from Jeff Bezos, or this great tale, where he tells, “Alignment is not about agreement, it’s also fair to disagree and commit.” So creating alignment is not about making everyone happy and everybody’s saying, “Yeah, this is the best idea ever,” but more like, “Look, this is something for the next three to six months, maximum, and there are lots of uncertainty in there, so it’s more important to get started to figure out whether the stuff we have put down here is actually true, and we can adjust it all the time.” So it’s not a static document, it should be something which is updated all the time.

And I think with this attitude in mind, it’s also fine, or it’s much more easy to get potentially hesitant or reluctant team members on board of, “Let’s pursue this, let’s give this a try, and let’s adjust along the way.” So I think why most people feel like alignment is impossible, especially larger corporations, is because they aim for true agreement to an idea which is close to impossible, especially in a complex stakeholder environment.”

This is where you’re talking about alignment across larger teams or up and down the chain with stakeholders. XING has a really good methodology for how they create alignment or at least communication and collaboration. And I reference it all the time, I have no idea how to pronounce the word. Please help me.

So the document you’re referring to is called [foreign language 00:23:05], so this is a super German word, it’s hardcore German. There were many attempts inside of the XING when this was created, which of course was heavily influenced by the… So it’s a custom evolution of the mission briefing framework, it’s based on [inaudible 00:23:21] idea. There were many attempts to give it a more internationally appropriate name. I think the closest one we got was, it was called ACE which was assignment clarification exercise, which sounds even German in English. So it’s like, “Okay.” And I think at one point in time we just resignated, or the main people behind the initiative resignated, and said select, “Okay, let’s roll with [foreign language 00:23:47],” through that, at least everyone knows that it’s German.

[foreign language 00:23:52], sort of.

Almost. Let me send it to you as a voice memo, and then you can play it off your phone every time you want to hear that.

I will definitely do that, and we’ll link to the site that’s got a really great overview of [inaudible 00:24:02].

That’s a good idea.

So, going back to disagree and commit for a moment, have you ever seen this being introduced to an organisation? I’ve been in plenty of big companies where we have agreement theatre, but the idea of people actually saying, “Yes,” admitting, “We are not going to agree, but we are going to commit,” I can’t see them doing it in many cases,

I think you have a much higher chance of achieving that when you’re working in an organisation which has embraced the idea of self-organisation much more wholeheartedly. Because from my experience, the biggest amount of actual disagreement about a mission does not necessarily come from within the team, but more from senior management disagreeing with the direction the team wants to pursue. So I think if a company has really said, “Look, we’re really doubling down on this idea of cross-functional teams autonomously pursuing a mission,” I think in these environments you will experience it much more often that management might say, “Look, I’m not agreeing, but you’re the team. You are having the autonomy to pursue your mission. Give it a try.”

Moving on to the… We talked about empathy, but also there’s an element of trust that I think lots of people who work with teams are aware that trust is just so important to be an effective leader. You’ve talked about a few examples of how you build trust, but have you got any specific tasks or things that you do yourself to make that happen?

Yeah, so when I thought about this whole topic of, how can you make empathy within the team more tangible? Because I think this is one of the biggest struggles, everybody’s talking about it, but how to make empathy more tangible within the team. I mean there’s the obvious things of simply doing informal one-on-one with team members, and asking them how they’re doing and care about them just beyond the pure [inaudible 00:26:07]. So sort of step into this an area which you would normally consider the area to be of a people manager. But I think it’s important to also support this general culture of empathy within the entire team. And I think because we talk so much about having empathy for our users, but we rarely talk about having empathy for the people we work with. And so, one framework I came up with, or format I came up with, it’s called the Agile Peer Canvas, which is essentially meant to be a guide for teams having a more open and honest discussion, and which goes beyond their job description.

So essentially, it combines various aspects of, what’s your formal responsibility as a person, but also what are the hopes and fears you have as a person? Not just as this role, that you’re having on this team, what drives you, what motivates you, and what might be informal roles you could take as part of this team which help you to fulfil your inner purpose, which is maybe not reflected in your job description? So maybe you care a lot about the way you communicate within the team, or ethical standards, professional pride, stuff like that. These things are oftentimes not reflected in job descriptions and I think it’s an important part of empathy, to help people find the space to step into to pursue this passion, and this purpose. So this Agile Peer Canvas essentially could be a guide for a discussion you have as a team, as a workshop, a joint workshop where one after another simply opens up using this framework, and tells everybody, “Look, this is me, this is me as a person, this is who I am.”

And it’s not only meant to be a one-way street, but instead also offer us the chance to have an honest conversation about who everybody on this team thinks this person is. Like, “What do I think of you? How do I perceive you? What are you driven by? What are your motivators? Why am I surprised that you have a fear of, whatever, imposter syndrome?” To take the product management example. I think these conversations happen way too rarely, that thing, not often enough, let’s say it this way, they don’t happen often enough. And I think just making it a bit more guided and a bit more structured can help product teams achieve a way better culture.

Do you find that some people find that very uncomfortable?

Absolutely. Yeah. And I think that one important thing to get things going is that, so typically it’s the product manager, maybe a [inaudible 00:28:39] master who gets things like that going, and it’s important to understand that you have to be the one opening up first. So when sending this meeting invite, you probably have to send some of the things you’re going to open up on right away.

It’s nothing like it, but it reminds me of an article I read a while ago about Google Ventures, I think it was, used to run, or probably still do, anxiety parties.

Interesting.

It’s great. I absolutely love the idea. I think I’ve only managed to do it once. I’ve only had one scenario where it’s been appropriate. And essentially, what the team will do is they’ll come with their anxieties and say, “This is what I think I’m doing wrong.” And then the rest of the team will rate them on whether it’s an actual thing or not, whether it’s something that they need to worry about or not, which I think is a really nice way of turning it around so that the things that you are worried about, you can either get feedback on, or you can be told, “You don’t need to worry about that because it’s not what we think at all.”

It sounds so California, though.

How do you deal with stuff like that in the UK, Randy?

We just have a cup of tea.

Of course.

I’m going to defer to the actual British person on that. So I’m sorry, Tim, that was a really great practical overview, and description of the peer canvas, but is there a way that people can get their hands on it if they want to try it out?

Yeah, sure. I think we might be able to link it in the show notes as well. But if you just go to, now using my German last name, herbig.blog/canvas, should get you right to it. You can download for free, and I provide some instructions of how to use it as well. And if you have any questions, feel free to reach out to me.

So one of the big things that you have to deal with in leadership, and in managing teams, or working with teams is conflict management. What’s your take on conflict, and how to deal with conflict in a lateral leadership manner?

I think the biggest problem with conflict and associated, the process of escalating things if you’re not able to resolve it on eye level, is that it’s seen as a bad thing. So people shy away from escalating things or clarifying conflicts because doing that might lead to the perception that they have not been able to master it themselves. They look for help from others, and this is a weakness, so they are a weak leader, not a strong leader. I think this is simply a way of thinking which has to stop, because ultimately everyone on the team seeks progress and clarity, and sometimes it’s natural or it’s important to admit that you can’t resolve every conflict, and every situation, every disagreement purely on eye level between two persons because probably you’re just running around in circles because you couldn’t get to the solution. And therefore, it’s important to seek this support or this help in making the final decision, or making a call by escalating things.

And I don’t know if it is how it is abroad, but especially in Germany, or in the German culture, I would say, that escalating things has this negative touch, this negative perception that it’s not something you should do. And I’m a big fan of actually supporting escalation and giving people more guidance and encouraging them to escalate to clarify conflicts by just making sure that there’s a certain shared understanding that this is not a bad thing, and just walking through a certain step of things like how you would like to see things escalated in your company in order to make a structured decision-making. And I think this is what it’s ultimately about. And if you’re able to establish this shared understanding, or this culture of escalating properly for conflict resolution in your company, you are able to make much more progress even in lateral, or especially in lateral environments.

So that’s interesting. You’re talking about escalation but not making it confrontational. Is that an accurate-

I think it depends on how you would define confrontation. So in my head, and this is so German, confrontation sounds like screaming at each other, and fighting. And I think unfortunately it’s oftentimes used that. People use escalation as a threat. I once was part of a project where someone stormed into the room and was in disagreement with the project we’re working on, was like, “This is not how things are going happening here. I’m going to escalate that.” And it was clearly meant as a threat to stop doing things, compared to the reaction one should have embraced on the other side, should be like, “Great, finally we’re doing this, may I help you write the email to escalate things? Because then we can finally make progress.” So I think that people are oftentimes, especially on eye level, might not be able to make a call to finally resolve a conflict because it depends on things above their pay grade, or whatever, or political dependencies. And therefore it’s even more important to embrace, for example, the clarification of this conflict.

It’s interesting, and actually what I find as well is that you can get an element of lateral escalation, certainly I’ve been in a situation where someone’s manager has come to me and said, “I’m having this problem with this staff member. Please can you find a way to encourage them to behave slightly differently, or to think about the rest of the team when they’re behaving in this way?” So I think escalation can work in different ways.

Absolutely. So I think it’s a misperception that escalation only has to go up the chain, it’s hierarchical escalation. I think if you think back of this concept of especially the informal roles on the team, I think there certainly are people in every team who are pretty good mediators and can help you resolve conflict, and all that’s needed here is just the shed understanding of a process of how you lay out the conflict to enable decision-making.

So do you have your favourite lateral leader? Do you have your one person, or your few handful of people that you’ve seen do this really well?

I still admire… Because it’s important to understand that lateral leadership does not only happen on an individual contributor level, because also C-level board members or VPs have to lead laterally, meaning they have to lead other VPs or other C-level board members literally, because as soon as you’re on the same hierarchy level, you have to apply these tools. And so to this day, I still have lots of admiration for my former boss’ boss at XING, who was a VP, an I’m still admiring him for the empathetic way… I don’t know if that’s a thing. The way he deployed empathy to work with people on the same level as he was, and never relied on traditional, who’s the strongest guy in the room? At least not to my awareness. So this was really impressive to me, and also showed me that this way of leading is also needed and possible on higher hierarchical levels.

So one of the things I love about your book, Tim, is that it’s short, and I know it sounds ridiculous, but there are a lot of-

The suffering was over.

No, there’s a lot of management books that have a really great message in 30 to 50 pages, and then they repeat it and illustrate it again, and again, and again, and you’re flipping through trying to find the meat in it. And your book doesn’t have a lot of filler to it, but you do have an awfully long reading list at the end.

That’s true.

So we get a lot of the benefit by reading your book, but which are the two or three top things you would recommend for people more interested in this topic?

So the top three books I would certainly recommend from this whole list, on the one hand, it’s a Radical Candour from Kim Scott, which is an amazing book on giving feedback, which is even more important on eye level. Then it’s The Hard Thing About Hard Things from Ben Horowitz, which doesn’t seem that related at first sight, but if you dive into it, this whole notion of the intensity of him caring about the people on this company was certainly impressive for me, writing this book. And last but not least, it’s Reinventing Organisations from Frederick Laloux, the illustrated version, and this is an important remark, because there’s an illustrated and non-illustrated version, and the illustrated ones just so much more fun. And in this book, he describes really a very, I would say, desirable future of how organisations should be set up and work together.

And that was one of the things I was going to ask actually. We are talking in terms of tech businesses, do you have any experience of this lateral leadership becoming more prominent across other industries or other businesses? Because obviously in tech, we’re seeing more sort of holocratic organisations, and different types of organisations, but have you seen any examples of other businesses embracing this kind of non-hierarchical way of working?

Not in person, I have to say, just from the tales, or the stories Laloux is sharing in this book. But just in general, I’m just so convinced that this notion of organising the work and a company in cross-functional, loosely connected teams is already present in companies which are not in the tech sector. So I think, on the same note, I see the awareness for lateral leadership being correlating strongly to the degree of maturity of this company when it comes to embracing agile processes and setting up cross-functional independent teams. And so, as soon as you have adopted to a certain degree of maturity when it comes to agile work, whatever that means, you arrive at this point of questioning, “Okay, what does it mean for the way we lead each other?” And so I strongly believe that this is already present in companies beyond the tech sector, and will spread.

Tim, as you’ve embraced this, what’s the difference you’ve noticed in your day-to-day work? What’s changed since you’ve been aware and started applying this?

I would definitely say opening up more, myself, is one thing. Just regularly opening up a bit more about what worries me, what’s on my mind, with the people I work with on a regular basis. Encouraging them to do the same thing are certainly one of the main aspects, I would say. And also, and this goes a bit then hand in hand with the alignment thing, is trying to pay way more attention of the jargon or the vocabulary which is used within the team to make sure that the shared understanding is actually shared understanding.

And what effect has it had on your teams?

That’s a good one. I think it would be easier to ask them. I would hope that it’s made me more approachable, and increased their psychological safety to pursue their own ideas, and also make their own mistakes, hopefully. At least this is what I’m aiming for by applying this sort of behaviour. But I think this could hold true. And taking up responsibility on their own without my permission.

That’s a good one.

That feels like a really nice place to end the interview. Thank you, Tim. That was brilliant.

Yeah, that was really good. It’s almost like you’ve talked about this before.

I practised. I ran some dry interviews the day before. Thanks so much. This was really fun, guys.

The Product Experience is the first-

And the best-

Podcast from Mind the Product. Our hosts are me, Lily Smit-

And me, Randy Silver.

Louron Pratt is our producer, and Luke Smith is our editor.

Our theme music is from Hamburg Bass Band, Pau. That’s P-A-U. Thanks to Arne Kittler, who curates both Product Tank and MTP Engage in Hamburg, and who also plays bass in the band, for letting us use their music.

You can connect with your local product community via Product Tank, regular free meetups in over 200 cities worldwide.

If there’s not one near you, maybe you should think about starting one. To find out more, go to mindtheproduct.com/producttank.