Episode 2 Transcript: Moving from being an Individiual Contributor (IC) to a manager of a manager of...

This is the full transcript of the first episode of Inherited Composition. You can read it below, or listen to the episode

Gonto: Welcome to the second episode of Inherited Composition. In today's episode we're going to be chatting about how to move from an IC, or individual contributor position, to being a manager, and a manager of managers, and the managers of managers of managers. We're going to divide today's episode into four parts. Each part will have a context and a problem statement, and then different solutions or case studies that we've had throughout our lives. We're going to start talking about being a control freak and what happens when you stop having full control of everything.

Then we're going to move to talk about what happens when you're a first level manager and you need to enable people. Then we're going to talk about what happens when you need to manage people who know more than you in certain regards. And then finally we're going to close with what happens when you're the manager of a manager of a manager.

Guido: Yeah, and again, this is going to be based on our personal experience over the last few years, and I think it's going to be fun to listen to our different perspectives. Probably becoming a manager in a product company has some differences with a service company. So I'm eager to have this conversation with you, Gonto.

Gonto: So before starting, how did you start to be a people manager? How was the transition? Did you think about it, did it just happen? How was it?

Guido: Well, in my case it just happened. At the beginning, I wasn't really conscious about it. I started working at Wolox after I worked in another software company with you, and I needed to start managing a team, because I had a product that I needed to develop with a client, and I had another group of developers that started to work with me, and I remembered that my first project was with a person that was the first Wolox employee, apart from the founders.

So I don't know, I didn't spend too much time thinking about. We just started working the project, and that's it. But eventually, once I started to work in other projects, I realized that I needed to start learning a little bit more about managing people and try to understand what my actual role was, because I still was a software developer. Most of my time I was writing software, but there were problems and situations that needed to be solved regarding people, and I needed to find a way to learn how to handle those situations.

The funny thing is that, you know, being a software developer, you know where to look for answers. For example, you go to Stack Overflow or whatever. And trying to find solutions regarding managing people is completely different because there is no right answer, there is no formula. You're probably not going to find an answer on Stack Overflow. So it felt different for me. It felt that I needed to do more research than I was used to.

Gonto: I think that for software development you also have to do research, it's just about getting used to stuff. And for me actually, how I learned most around management was actually applying things that I talked with my psychologist or that I learned in meditation or that I learned from philosophy and those kinds of things. But for me, I actually had two situations where I became a manager. First it was in software, where we worked together, and I was managing small teams, like two, three people. I was actually your technical leader, I remember. And it just happened, but then from there, I moved to do freelance and talks, etc.

And then in Auth0 when I joined, I joined as an individual contributor, and becoming a manager was actually organic, and it was around scaling. So I was working on things that started to work and show that they were working. So because they were working, we wanted to create a machinery that made them just continue to work and made me focus on other stuff. And that's how I organically started to have managers and managers of managers, etc., after the organization started to do more things that worked and started to scale those kinds of things.

Guido: Yeah. Now that you say that, I realize that one of the things that is both a good and a bad thing, being an engineer, when you transition to a manager position is that the feedback loop is different. The things that you're trying with your team take more time and it takes more time to see the changes of the things you're trying to do to improve how the team performs. So at first that was tough for me, because I wanted to find about a solution, put that in practice, and see the results right away. But on the other side, I think we're used to a way of working that structures how we think in a way that could be better when you want to scale your practice and tackle the problems with an engineering perspective.

Gonto: Makes sense. So let's go into the first topic. We said that the first topic was going to be about being a control freak, and the main idea is that when you are an individual contributor, you have full control of everything, or mostly everything. You might have dependencies on other people, but you know what you need to do, and you just need to do it. But then when you move to be a manager, that's no longer true, because now you have people that will be doing things that are basically out of your control. So something I want to chat about is how can we fight or how can we live with that need of control? So what is your experience with that?

Guido: Yeah, that's a hard one. I think the first thing that comes to my mind is, you know, trying to let go, if I have to summarize that, is understanding that you have to accept that other people have other ways of solving problems and other ways of writing software, or whatever, and you have to accept that. I think it's about setting the right expectations and defining how are we going to work and what you expect from them, but don't tell them how to do things, and don't try to impose your way of working. You have to learn to let people do their thing with their style.

Gonto: And something I like about what you're saying is that everybody's now talking about diversity, but at first I didn't understand diversity at all, because everybody was talking about diversity, and I was saying, I don't know, like, more women speak at conferences, more people from Africa or even from Argentina, where I am at. But then what I understood is that diversity is not about that. Diversity is about having different cultures and different opinions. And something that I really value at Auth0 is that we are remote-first. We have people from so many different countries, and actually getting a different perspective from my own is something that definitely helps me understand better what to do. And then the other part that you said that I liked is about letting go.

To me, that has to be very together with the expectation management. So in the beginning, something that was happening to me is that I was asking somebody, "Hey, please do this." And then I pinged him one day later or one week later and asked him, "Was it done?" and he was saying no. I was like, "Why the fuck didn't you do it? What happened? How can I work with you?" And then because of that, I started to do more micromanagement, but that wasn't the solution. And what I realized is that the problem, of course, as usual, was me, because I needed to be better at setting expectations.

What that means is that, hey, I want you to do this by January 15. Do you think we can do it or not? And then what you or whoever reports to me should be telling me, "We have these tasks for January 15. So if we need to do this, we need to stop doing these other things." So once you start setting dates, it's easier for people to understand, "Okay, he wants me to do it by that date and he wants me to do it in a certain way." So that way you start talking to them and you start generating these expectations that you have, and everybody starts understanding time is finite, so you need to have a start, stop, and continue. So basically, if you're asking them to start something new, and they don't have bandwidth, they need to know what to stop, and that's something that you need to work with them, I think.

Guido: Yeah, and that's funny because at first, I realized that when I start asking maybe junior developers, "When do you think this particular task is going to be ready?" they usually underestimate the task. And obviously, when you have more experience, you start considering maybe edge cases or maybe impossible integration problems that you think you're going to have, or maybe you're considering that you have to make more documentation or talk with the QA team. And maybe a junior developer that doesn't have the experience forgets about it.

So in my case, it was at first struggling with developers and telling them, "No, I don't think you're going to get that in two days. It's probably going to take a week." But you get the risk of them then relaxing and saying, "Okay, he's always going to tell me a couple more days than I'm used to. So I have more buffer there." So what I did at first was, okay, let's try to break this task together. So how would you implement this? Have you considered these cases?" I was struggling with myself trying to not give them the right answer, you know? I was just asking questions, and try to pick and understand how they think and show them how I think, and maybe converge to a better solution together. So yeah, I think it's a lot about helping the other person go through the process of tackling a particular task.

Gonto: That makes sense. I want to talk more about enabling people in the next section. But before going to that, I have two more things that I think are important, that helped me a lot, is that at first I was asking people and pushing them on, "Is this done? When is it going to be done? What's going on? What's happening?" etc. And people get sick of that. Well, it depends on the personality. But something that I realized is that it's better if I can pull the information instead of pushing them. So using a simple tool as, like, Trello for task management or like a wiki with tasks they need to do, I can then just go in there, see what they're working on, what's done, what's not done, and based on that, I can just ask them questions on the things that I don't get. But I don't need to continually be asking them, "Is this done? Is this not?" etc.

And that was like the pull versus push, where I think that a task management tool can help you do more pull. The other part is that, together with the task management, as we were talking in the previous episode, we're doing OKR's, so objectives and key results. And every person in the company has their own objective, and we check them monthly to see if the key results that drive that objective are being done. And because of that, we don't need to do micromanagement, because everybody knows what to do, and also when we hire people, we are trying to hire more of what we call responsive adults or something like that.

Guido: Yeah, and also I think it's really important not to force a deadline. You know, sometimes obviously you have some strong deadlines that you cannot move, but it's important to get a commitment from the other person, to tell them, "When do you think this is going to be ready? You know we have, I don't know, biweekly sprints. So you know that you have to do a certain amount of work within two weeks. So do you think this particular task can be tackled in the next two weeks?" to try to get a date and a commitment from them and avoid pushing a particular dare. I think that works way better, because then the person says, "I committed to this date. I said that I was able to do this in that particular date."

Obviously you can underestimate or overestimate, and in those cases I think it's a good idea to have a sync up every day and be transparent about that, say, "If you don't think you're going to reach the goal for any particular reason, I need to know that as soon as possible so I can fix that issue or help you or whatever."

Gonto: I think that you're saying [inaudible 00:13:48] etc., to me it's about ownership. Every time that somebody has ownership, they're going to be better at doing that. You were mentioning daily sync-ups. In my case I do actually weekly sync-ups. I chat with some people more, with others less, but I know that every week I have a sync-up where they are going to let me know what have they done, what haven't they done, what are they blocked, and what do they think they're going to ship or do by a certain deadline we agreed, and what we said that they weren't, basically.

Going to the next section, which I think is actually related to this is, like, once you start being a first level manager, the other thing besides losing control, the other thing that you start to notice is that your job is now to enable people. You're not the one who ships things anymore. You're not the one who is actually doing stuff. You're just enabling people to do so. So how do you solve this problem of, like, "I'm not shipping stuff. What should I be doing? How can I work with that? What things can I do?" and those feelings, but at the same time being a good manager and enabling the people on your team to be doing actually a much better job.

Guido: Yeah, for me that was the hardest thing, and sometimes I still struggle with that, because I don't know, if you're a passionate software developer, to stop doing your craft is hard. Every time I get to the point of writing code and get in the zone and forget about everything, I get a really good feeling about that. But that's not your role anymore. Of course, you can have some time to still write some code if you're a software developer or have a particular task where you still are the individual contributor. But that's not your key role anymore. So I had to learn that my role was to help people fulfill their job and grow as a person and as a professional. So that's what I think is the most important role of a manager, that would be helping other people become a better professional.

Gonto: And for me it was pretty hard. I remember that I actually had a conversation about this with one person of my team where he's now leading developer evangelism, and I've done developer evangelism for a lot of time. So he started asking me questions and I was always answering them, and then at some point he started to come to me with ideas that weren't fully baked and weren't fully done, and he was coming to me, so I was telling him, "You need to do this, you need to do this, you need to do this." And that's not good for me, that's not good for him, and that's not good for the company.

So I was talking about philosophy, and something that I really like about Socrates is his Socratic method where what he does is he starts asking questions, as you said before. And that's the only thing that he does, and the main idea is, like, when you come to me with a problem or a question, I'm going to start asking questions to you. So the first thing I remembered is, when he started to come to me with half-baked ideas, I was like, "Did you spend some time thinking about this? Is this finished? Do you want me to review or do you want more time?" And at first, he was like, "Okay, give me more time," and then when he came with a conference idea, it was like, "Okay, who's the target for this conference? Who's going to attend? Who's going to be listening to the talks? Who are the speakers? Why do you think that this is important? How is this going to affect the bottom line?"

And by that, you do two things. First, you help people think. You're enabling them to think and you're making them better, because now they're going to make the decisions. It's not you that's making the decision. And then the other part is ownership, because now it's not me who's telling you what you needed to do. Now it's you who decided what you needed to do. I was just guiding you and asking you questions.

Guido: Yeah, and I think that that's really, really important, and even more if you are communicating over a written channel. So for example, pull requests, when you do co-reviews. Asking questions to understand the trade-off that somebody made in their head that drove them to do the particular design or whatever, or how they wrote the code, it's really important because if you start suggesting ways of how you would have solved that problem, then you are, because you have a hierarchy, you are imposing your solution, even when you don't want to do that. So people will say, "Okay, my boss is telling me that I should do this, and this particularly works. So I'm going to do it because I don't want to get him mad," or whatever. So asking questions is a good way of starting a conversation.

And the other thing that worked really well for me, and I still do that a lot, is, when somebody asks me a question, let's say through Slack, maybe what they are asking is not something super critical that needs to be solved right away. I don't answer the question. I wait maybe an hour, maybe two hours, and then most of the time I get another message from that person saying, "Don't worry. I've already solved the problem. Here's the solution." And I really like that because people tend to go with the quick answer. It's like, they know that you may have the knowledge. So it's easier for them to just ask and get a solution, and don't worry about it. But the problem with that is, yeah, you may get problems solved quickly, but in the long-term that's not a good solution because that person is not learning through the experience of going to do the research, face the problem, and think about it.

Gonto: At the same time I think you're generating a dependency, because the more they ask questions and the more you answer, the more they will come and ask because they know that you can answer or that you will answer. So you're generating this dependency where instead of growing them, they're just asking questions and acting on whatever you're saying, which to me, that doesn't make sense. But at the same time, something that happened to me is like, okay, I'm going to start asking more questions, I'm going to start enabling people, but I really like executing.

I still really like executing, and something that was happening to me, and again, it's like a feeling that probably will go away eventually, but it's like, being a manager and not shipping things, I feel that I'm not adding value to the company. And it's crazy. I know that's bullshit, I know that's on my brain, but the difference from the brain of what I know and what I feel is huge, and there's not a bridge for that. So what I ended up doing is, I actually now book myself time to work as an IC. There are particular projects where I work as an IC. So what I do is I book myself in the calendar four hours every week, or sometimes like six hours every week, to work on a project that's not time-sensitive and that's not in a critical path. The main idea of that is that I get the feeling that I'm doing something myself, but at the same time I'm not delaying anything, and it's something that I feel can add value.

So for example, something I worked on in the past was the new version of the pricing. We didn't have an urge to update it, but at the same time I felt I could add value to that, and it was very interesting to me. So that was one of the projects that I worked a lot of time on. Another project, for example, that I do an IC on now is talking to analysts. So that's another thing that I go, I spend some time, I talk to them, etc., because again that's something that I feel I can add value, and it's just a particular time constraint, like one-hour meeting or something like that.

Guido: Yeah, and it's the same for me. I still enjoy writing software, and probably going to still do it, but it's true, I can no longer be the person in the critical path. I'm not the one that's supposed to write software for a client project. So what I end up doing is I allocate time to work on open source projects that I like. Maybe I want to explore a particular pattern, or maybe, I don't know, learn a new language or maybe improve some internal tooling that nobody is doing in the company and it's not a high priority, but everyone would benefit if something is done on that side. So I take those projects.

Then there's a problem for me, because I cannot move as fast as I used to. So I need to learn not to be that anxious, and maybe an approach that I would take normally one or two months is going to take me four, but it's a good way of letting my inner developer still code and also learn new things and be able to keep my skills up to date and still have conversations with developers and know what's the latest tech. Or sometimes it was good for the company because I used my time to learn a new technology that the rest of the team didn't have the time, and then I was able to introduce that technology into the company.

Gonto: For me, I don't code in my day-to-day life anymore. I actually sometimes do it in my free time. So for example, I was very interested in Etherium. So I started coding smart contracts. So that was another thing that I started doing. So you were talking to me sometime before now about investing time on raising junior devs. Can you tell me more about that?

Guido: Yeah. One of the things I'm proud about Wolox is I think we're pretty good at getting junior developers and raising their skills. But you have to be conscious that you need to invest a lot of time on that. And sometimes it was hard. I remember being on a project and saying, "I need to get this done by Friday," and this person is probably not able to do it because he lacks the experience to do this in this short amount of time. So yeah, the easy answer there is just me, you know, writing code and shipping and that's it, let's forget about it. But I actually always try to spend time with a junior developer and just working side by side doing [inaudible 00:24:45] so okay, I know this task, if I do it, I'll probably do it in an hour, and if you do it, maybe it takes four or five hours. But let's do it together. We'll probably do it in two or three hours, and you're going to learn how I think and probably learn some new tricks.

And next time you're going to be better prepared for [inaudible 00:25:08] and it's a good way also to introduce them to more complex parts of the systems or maybe to different parts of the organization. So I think it's really important to be conscious about it, and sometimes what we do is we over-assign developers to a particular project to, you know, have a quick way of getting a junior developer into a real-world project and give them small tasks that are not in critical paths or are not supposed to be done in that particular sprint. And that helps them to get on track really, really fast.

Gonto: That's cool. Let's go to the next topic. So this is something that personally happens to me a lot. Guido said that it doesn't happen to him that much. It's around managing people that you feel know more about something than you. This is something that, I don't know if it's an insecurity of mine or what it is, but sometimes my question is, I'm hiring somebody that's smarter than me on something, and I think that that's the best choice. You should always hire people who know more than you. But my question was, "How can I add value to these people if I feel that they know much more than me?" And particularly there are two things that, to me, are very interesting about this and that I keep on thinking and that have helped me with this.

One of them is that the people that I manage really value my different point of view. So I'm an engineer, I'm doing marketing. That means I'm better at technical things, growth, I'm good at storytelling, but for example, I knew nothing about integrated campaigns. Now I do because I'm learning, but I hired Carrie, who has done it before, she knows a lot about it. And my question was, "Can I be a good manager for her?" She has so much experience doing integrated campaigns, trying things out. How can I work with her?

She actually gave me, during these two years that I've been managing her, she has been giving me different feedback about this. One was around a different point of view, which to me is something that I never thought about before. But she has experience, and when people have experience in something, they've done it before, and they're going to try to do it the same way that they've done it before because they know that it works.

But because I know shit about that, I can basically have a very different point of view because I was giving her new ideas or new things, and actually from the combination of the two, we got to a really, really good and interesting point, and we started chatting and having good ideas. And then the other part that, to me, is interesting is that managing people is not about knowing and being a subject matter. Actually sometimes there are managers that have absolutely no idea of who they are managing.

Something that I saw is that I'm working with my direct reports a lot about how to deal with stress, how to do problem solving, I talk to them about meditation or things that I've talked with my psychologist, for example, or something like that. All of that stuff, they value it a lot more than I thought, and I actually got comments. They were saying that, because of that, they considered me a good manager because I'm helping them. With one of the guys, with Sika, [SP] I remember that he was always saying, "No," and being conflictive, etc., and he actually told me that working on this actually helped him with his relationship with his girlfriend, which to me is even more amazing. So managing people is all about people, I think.

Guido: Yeah. I just want to clarify that I wasn't facing this situation not because I think I know more than the rest of the people, but just because I was in a situation of managing other developers who were probably junior developers. But yes, I found myself in the situation of working with people that were from a completely different area or have a completely different background, and I needed to work side by side with them. Or maybe me being a cofounder gave them the impression that I was maybe in a high role. But in those cases, what I found really interesting is, it related to what you said. Because you know nothing about that subject, you're entitled to ask some questions that maybe somebody that is an expert in that area wouldn't ask. And that triggers a really good conversation and is a way of unwrapping a problem.

Also, I think in my case it is good to maybe use your, let's call it political powers. So maybe you can raise somebody's voice or maybe you can use your skills inside the organization to help that person accomplish a particular task. So yeah, as you said, it's all about helping people. So in those cases, I think your role is just to unblock people and help them accomplish their goals and be a support on a personal level.

Gonto: Something that to me is interesting about this, and it's related to this, I feel that a lot of this is related to personal insecurities, and there's a lot of talk about, like, impostor syndrome. I love that topic, where you feel like you got there by chance or you don't know why you're here, you don't know what you're doing. And usually that's bullshit. Like, nobody thinks that of you. Sometimes when you listen to people saying, "Hey, this is great, you're the best manager that I've had," you're like, "No, they're lying to me because I'm managing them," or something like that. And in reality, that's not true.

Something that I've learned is that most problems around this are all in your head. And to me, being conscious, as I said in a previous chapter, is the first step. So as you start to be more conscious that all of this comes from thoughts in your brain, then you can say, "I've done this before. This is working. Everybody says that I'm a good manager. Stop listening to those thoughts, because they make absolutely no sense."

Guido: Yeah, and again, it's all about having good communication with the people you work with. So yeah, I think having a regular chat with them, having a space where you don't talk about work and you start growing a personal relationship, they don't need to be your friends obviously, but they need to realize that you are also human, that you make mistakes, and you are there just to help. Once you start bonding on that level, I think the best things are the ones that come after that.

Gonto: There's a post that I read that's related to this that talks about, if you're doing a one-on-one that's not awkward, you're doing it wrong. What I do, for example, with the people that I manage is that I have the weekly sync-up, as I mentioned before, and in there we talk about tasks, we talk about what they're doing, etc. In the one-on-one we talk about, "How are you feeling? What's going on?" etc. I agree with you that it's about communicating with people at a personal level, because then they're going to tell you the real problems that they have, and you can actually help them. What this post was saying is that, unless there's something awkward or weird in a one-on-one, you're not doing it wrong because you're not talking about the real problems or the real things that are going on. And something that I always try to do is share how I feel or what things happened to me, because that makes people share more, and there's a good Ted Talk about the called "The Power of Being Vulnerable," that I'm not going to go into, but it's great. I love it. So you should listen to it.

Guido: Yeah. It's funny, I was just going to say something along those lines. This is something that I still struggle a lot with. You need to show people that you're vulnerable, and you have to be comfortable with that, but it's tough. Maybe we can discuss that on another episode.

Gonto: Yeah, let's go to the last section of this episode, which is, what happens when you are a manager of a manager of a manager. So at the beginning you were managing people, and those people were shipping something. But then you start being a manager of a manager of a manager of a manager, and you're not that close to the people that are shipping. So how can you work on detaching from the day-to-day to work on more strategy topics? Personally, this is something that I struggle a lot with, because I like being involved, but I know I should do it less. So this is a personal struggle that I have right now, and for me, something that I started to do is hiring and training more senior people that I don't have to tell them what to do. They know what to do. They just do it, and basically I talk with them, I give them feedback, I help them out, and it's not me telling them what they need to be doing.

The other part for me about this is that at first I wasn't understanding what's strategy, as I was saying in the previous episode. To me, strategy is just, instead of thinking, "What will happen tomorrow?" or, "What will happen next week?" it's starting to think, "What's going to happen in the next quarter? What's going to happen in the next year? And how can you work to get to where you want to be on those times by thinking and spending some strategic time on that?" And because I was having a hard time with this, something that I started to do is actually book myself time. I'm a big fan of booking myself time. So now, for example, if I want to think about something, I book myself two hours on Tuesday to say, "Okay, I'm going to think on this topic, write a one-pager, and then share it with the rest to see what they want to do."

But this is something, as I was saying, that's still a struggle of mine, because I feel that I still am in the day-to-day and helping with execution, because something that happens a lot is that one of my teams is doing something, another team is doing another thing, and I know that if they were talking to each other, they would do great things together. So for example, we were doing an online meetup the other day, and the online meetup was for developers and enterprise architects. And that was being done by the developer evangelism team, which just does these things for brand awareness. But developers don't like getting emails, but maybe an enterprise architect and product manager doesn't care that much. so because of that, I connected that team with an integrated campaign team so that we can actually do follow-ups on emails and see if they are interested, eventually set up a call or get them to an ADR, and I'm still doing that, like, joining things, which is part of my day to day job right now, it's like gluing things.

And it's something that I want to get out of, and I feel that, with OKR's objectives and key results again, that's helping me a little bit change that, and the other thing that we're doing is we have a marketing leadership meeting where everybody is sharing good updates or blockings or things that they are doing so that they can interact with each other, but as I said, it's still not solved, to be honest. So if anybody has feedback on this, I'm happy to hear it.

Guido: Yeah, I think that's something really interesting about what you said. Being at a high level is all about, I think, breaking the silos, because you are in the position that you can see how the entire company works, and maybe people that are focused in a particular department lose sight of the big picture. So if you are in a position that could take time, analyze how all the things are working together, I think it's your duty as a manager to make different teams work together. And that's where the most rich ideas start to appear, I think. The other thing is that, going back a little bit about what we discussed in the previous episode about culture and making culture explicit, once there are different managing levels, I think a process needs to be set in place, and a lot of things that are part of the culture or maybe things that are in your head, what you expect from managers, once you have two or three people or two or three levels, you need to start writing down how things work so they can be repeatable and you can scale as a company.

Gonto: I agree. Something that happens to us related to that, is that before we were using Slack and chatting in Slack, and everything was in Slack. Slack, things die there and nobody knows. It's like tribal knowledge. So as you're saying, "I'm working with my team to write more stuff in the wiki, have more processes, and break the silos, but again, I'm not sure if that's exactly what I should be doing. But that's what I'm doing now. But again, this is a thing that I'm personally working on now, as now I have managers of managers of managers, which to me is fucking insane.

Guido: Yeah. Maybe to close this discussion, I just want to mention that today I read a post about, I'm going to put it in the show notes, about flavors of engineering management. It's a good post. It talks about the different styles of engineering manager. One of the things it says is, if you are a technical leader that is focused on a particular stack of technology, you have more knowledge of the people that are reporting to you and you have a lot more experience to have a conversation with them. But for example, if you're a product engineer manager and you're at a high level and you manage people from different technology stacks, you most probably lost sight of the particular things of each platform. So you need to start relying on other managers to help you assess if what your particular team member is doing is the right choice or not. So I don't know, I think it's a really interesting conversation, because then a lot of your decisions start to be based on other people's feedback, and you need to develop some sort of intuition to realize which is the good feedback from the bad feedback, and trying to put your own judgement there and try to make the best decision you can. So I really recommend reading that post. And also, we're going to list a lot of materials in the show notes, podcasts that we consider really good. For example, "Manager Tools" is a really good podcast that at least gave me a lot of tools to improve my skills as a manager. And you're probably going to find different blog posts, a couple books. So yeah, let us know what you think about the material. And if you have something to share with us, feel free to share it.

Thanks for listening to this episode. If you want to know more about us, you can check out our website, inheritedcomposition.com. In there you'll have a sum-up of our episodes as well as the transcript of everything we have said and links to everything we mentioned. You can also follow us on Twitter @TheICCast.

Gonto: We also love feedback. We're trying to improve this every day. If you have feedback, you can tweet us @TheICCast. You can also send us an email to podcast@inheritedcomposition.com, or you can tweet me @MGonto or tweet Guido @GuidoMB. Finally, if you love the show, please leave us a review in your favorite podcast app. If you hated it, send it to your worst enemy so that we get more listeners. Thank you.