Don't come in and start changing things. That's a huge mistake that I've seen in the past is people think the biggest way, the fastest way to have a big impact is to come in and change things, especially problems that they see immediately. And that's not.

Welcome to the Ladybug podcast. I'm Kelly.

And I'm Emma.

And we're debugging the tech industry.

There's so much going on in the AI space, it's hard to keep up. But here's something you might not know. Graphs can give your AI agents the context they need to work smarter.

Want to see how?

Join us at Nodes 2025 on November 6th. It's a free online conference where developers, data pros and AI engineers from around the world share how they're using graph technology. From powering AI agents and improving data intelligence to building better knowledge graphs and graph powered applications. There are over 140 technical talks over 24 hours so you can attend the live sessions from anywhere. To register for this free conference, visit neo4j.com nodes so Kelly, so ammo.

Another day, another episode, another dream. What are we talking about today?

Today we are talking about what to do when you start a new role and what your first 90 days should ideally look like. And I say ideally because no two jobs are the same and no two roles are the same. If you join a company as a manager versus you get promoted into a new managerial role at a company that's going to look different, different size companies, all the things. So we'll be digging into exactly what that looks like. So let's open this up with a kind of broader question of like when you joined Spotify, I'm going to ask you too. When you joined Spotify, what were your first 90 days like? And then when you came back from parental leave as a manager, what were your first 90 days like?

So when I joined as an Engineer, my first 90 days, I'd say the first 30 days were devoted to learning. So you're not really expected to contribute to to the team's work. But instead you're in boot camps. They do engineering boot camps with all the new hires where you do projects. They do what they call intro days, which is very cool. I joined during 2020 Covid time so it was all remote, but normally they fly everybody to Stockholm and all of the like the CEO and all of his team are there and they all talk to you about the company mission and goals and all of that. So it's typically very cool. So you just spend the first 90 days getting set up with your IDE and understanding the roadmap and getting to meet your team members and all of that. So there's not a lot of pressure to contribute. And frankly, where I'm at on the desktop web team, it's such a high barrier for entry just because it's a massive repository with a lot of history. So we don't really expect people to be really productive for the first few months, especially as a new hire to the company, like we expect six months approximately for onboarding. When I went on nine months of parental leave, that's when I came back as an engineering manager. Same similar team, same domain, but our team of one had split into three, so I was managing one of those three teams. So I knew some of the people and I didn't know some of the people. It was kind of a good mix. But it all worked out in the end and I moved on to the new team about a month in and just started learning about the roadmap, getting to meet people, having one on ones, setting up my calendar, meeting my peers now of engineering managers in my product area, things like that.

Cool. Yeah.

Do you remember your first 90 days as an EM?

It was. Oh, well, it wasn't. Well, it's hard to say because I. Most of my career has been running my own company and so there was never really a first 90 days for me until I joined Spot, which was almost three years ago. So my first 90 days at spot was a little bit more chaotic as well, mostly because I was shutting down my agency and leaving my other startup at the same time. And then I also was trying to finish up agency work that was carrying over. And so a lot of it was spent, of course, learning as much as I can. I had a manager who I knew personally, which definitely helped, and I kind of just got thrown into it, honestly, it's, you know, at a smaller company you don't have that much time to acquaint yourself. I had a lot of people who I needed to learn more about who my peers were, who, you know, the entire extended leadership team, my direct reports, they were all getting to know me. There was one person who started the same day as I did, and so he reported to me and so he learned who his manager was on day one as well, which was an interesting thing too. So, yeah, I mean, within my first 30 days, honestly, I. I kind of took. I learned as much as I could, obviously, but I kind of got thrown to the deep end by day 60 and I had a lot More on my plate. I had a very expedited first 90 days which I could call in like the first 45.

Yeah. I'm curious, given that you were in your own company and then moved into a smaller startup, did you have any formal leadership or management training anywhere?

No.

Okay.

I just learned as a IT for me it's one of those things that it came naturally to me. I think getting my degree in social work and becoming a trained therapist also helped. Oh yeah, I can call that formal leadership training in a regard. I did a leadership course, a couple of leadership courses, I guess. So yeah, I guess I do have some formal leadership training from before joining Spot, but never in like the hands on tactical Engineering Manager. What you would think?

Yeah, I would definitely recommend. If you're thinking about moving into an EM position or are going to, I would say ask if your company has resources like formal training that are relevant to the company. Because Spotify provides two programs that are excellent. They're called Management AT and Leadership at. Management AT is the logistics of the job, what to expect, how our cadence runs every six months regarding performance evaluations, compensation reviews, all like that. And then leadership is a week long in person event. It's not just managers, it's any leader who's not in an IC or an individual contributor role. So it's going to be like product managers or data science managers, engineering managers, things like that. And you get together and it's still related to Spotify, but it's more about having these crucial conversations and difficulties you might face on the job and you get to go to those about two one to two months in. So it's not like the first thing that you do, but it was definitely worth it. I will say I've noticed there are some conferences out there that look really nice for management or leadership. They tend to run really expensive, which I mean get your bag of course. But it's at the point where like I think they're expecting companies to send their employees there and I'm like, are companies affording this? Like even still, I'm like twelve hundred dollars for a ticket for two days.

Is nuts to me so much. I would just say, hey, I'll speak if it means I can go for free. Yeah, just because I want to learn from other people. But like especially when you're at a startup or you're running your own company, like that's not an opportunity. Yeah, that's not for you.

That's not something that you have to invest in. Like if your company doesn't provide formal training like LinkedIn Learning has courses that you can take for really affordable prices. There are books, of course. Our podcast is a resource. Plenty of, like, more affordable or free resources, so. But yeah, if your company does offer formal training, take advantage. We also do interim EM roles because even in the US Spotify offers really great parental leave, but I'll be taking parental leave starting in April and I'll be gone for seven months. And that means we hire an interim EM for my team. So it's open to anyone in, like, our studio or our product area to apply. It could be from my own team, where they basically are my replacement for six to seven months or longer. It's really great way to try out the role before you formally move into it. So.

Yeah, I love that.

Yeah.

Because, you know, I think a lot of people, like, there's an, there's an article that I can, I can link to and I'm sure I've talked about this a lot, but Charity Majors has a. An article on, like, the pendulum of, like, moving between IC and em. And I think a lot of people, it feels like a huge commitment to move into a manager role because it is a very different job and to be able to try it out without, like a full commitment is such a cool idea because let's say you're interim EM for a while and you're like, wow, I really love this and I want to stay being an em, then, you know, like, that is going to be your career trajectory. Instead of saying, I actually, you know, it was fine, like, didn't love it. I want to be more hands on the keyboard board. I'm going to stick to the IC side of things. It's such a good way to try things out.

Yeah, It's a pretty low barrier to entry. I mean, I wouldn't take that with a grain of salt because every decision you make still affects a person. Of course, however, at least on our side, like the folks who are standing in as an interim, they don't get to do compensation review. They don't get any salary information about their direct reports. So it is, it's not like the entire scope of the job, but I think that's, I mean, that would make a lot of sense. Right. Why would you be privy to people's financial information if you're not going to be permanent? But yeah. Yeah. So I never went through the interim process. I went straight into the role. But if you do have something like that, I think it's really valuable.

Yeah. So let's talk about, you know, if you transition over to an engineering manager role. It's going, we mentioned at the beginning like it's going to vary. Like the kind of advice you take is going to change based on, you know, what type of the team and company you're moving into. And one of the things that, you know, I've seen both sides of is taking over, over a high performing team versus taking over a low performing team. Having managed a low performing team in the past, I think high performing teams are a little bit easier because they help you ramp up. Like they're like I, I've managed very self managed teams before and it's very hands off. Like they're like, hey, these are my priorities, which one should be number one? Or so. And so came to me, what are the trade offs we need to be considering or like architectural, you know, conversations, system design conversations. Like you know, we're stuck between these two solutions which, how should we approach this? Like those types of things are what you see in a high performing team. In a low performing team. Maybe they're not moving as quickly as they should. Maybe they're introducing a lot of regressions. Maybe there are cultural issues on the team, communication issues on the team. Just something's not working and you have to spend a lot of time figuring out what's not working before coming to a conclusion. And that's a really important point to make because the last thing you want to do is run in and be like, you know, you hear from one person, be like this person's the problem and they're like, okay, well I'm going to fire this person because obviously they're the problem and perhaps maybe they're not the problem to begin with. Maybe it's, it's more systemic, maybe it's something that's more procedural or process oriented and not like one particular individual. I've managed individuals in the past where you know, I thought they were low performers at first but what was really the problem is that they're working on a problem, like a problem or a stack or whatever that's just not suitable for them to thrive in that environment. And you pull them off of that team and suddenly they're thriving again. Like this is the problem with taking over a low performing team. You have to go in with zero assumptions and it can be really challenging if you know some of the people on this team before you move into this one because you have biases that you're already, you've already formed in your head, let's say like you've been, I've done this before. Like, I've seen, I've had issues with certain people on different teams and I'm like, I really think they shouldn't be. You know, I'm not going to give too many concrete examples for reasons that I want to be vague here, but you know, if I, if I'm saying like this individual, like, I feel like they're writing most of their code with ChatGPT because I don't believe they're actually writing that many comments in their code. I don't think they're doing their best work and suddenly I'm taking over the team that they're on. I'm going to point this out as being like, okay, so here are some process things we're going to use around, like, how do we go, how are we going to actually use AI like cursor or chatgpt or whatever, help us write code, Are we going to do that? And what, what checks are we going to have in place instead of being like, all right, you're now reporting to me and you're doing a bad job and so I'm going to immediately put you on a PIP because you need to change your behavior.

Yeah. I think also an important note, first of all, yes to everything you said, don't come in and start changing things. That's a huge mistake that I've seen in the past is people think the biggest way, the fastest way to have a big impact is to come in and change things, especially problems that they see immediately. And that's not, that's not the way to do it. Right. Yep. Also, not everything needs to be addressed, let alone addressed immediately. That's a lesson I learned the hard way. But you can have a high performing team with people who are just having a difficult time and it doesn't mean anything about them as a human being. But it does mean that we need to evaluate if you're actually happy here and if our goals are aligned. And if the answer is no, then that's okay and I'm here to help you with that. And we have to decide if we're going to manage you out or manage you back into the community.

Yeah, back into the, I don't know how to say it to a point where that it's working well. We'll, we'll, we'll just like shift your home a little bit and you'll just be able to live in the neighborhood, but maybe you live down the street instead. So there's one, there's a third category here. So taking over an existing team High performing, a low performing team. The other one is if you are forming a new team and you kind of experienced this being that one team was split into three teams. I know you were out for part of this obviously, but I'm curious, do you have anything that you can share around what that transition was like? You know, a mix of new team members, old team members. Like, what was that like?

I think it was actually great. I didn't have any issues managing friends or people. Like, I had no problem taking on a more leadership role for people that I'd previously met and also people I hadn't. Although you do have to be very cognizant of not favoring certain people over another, given your history with them as a friend or whatnot. That being said, the tricky part is now you have to build trust between all of you, right? So as opposed to like just you building one on one trust with everyone, now you have to ensure that they're all building trust with one another. So I didn't think it was a strange transition. Something that I did right off the bat was I did two exercises with people. One was called a moving motivators where we had this like figma or figjam or Mural, one of those collaborative tools. And there were a series of cards that laid out like, oh, essentially you had to rank things that motivate you in your current life. So like money is a big motivator for me at this point in my life, or recognition from peers or autonomy to do my job as I see fit, or work life balance. And you rank them and at surface level it seems very easy. And then you start getting into these conversations and it's like, oh, I actually don't care so much about money. It's important. But like, what's more important is working on cool stuff. Did that with everybody and that was helpful. And then the second one was a career trajectory where we walked through the past, I don't know, 10 years of both of our careers where we'd been. And then we also marked them as like, how motivated were you at this point in your career? And we drew a line so we could kind of track like, oh, okay, I'm really motivated when I'm working on consumer facing products and I'm not so motivated when I'm working on internal tooling. And we both did that for one another. So doing those two right off the bat really helped establish a rapport that didn't previously exist. So yeah, I mean, I found the transition quite easy given that like I had a manager do this with me. It went over really well and then I got really great feedback from the team about them. Yeah, I, I think people just want to feel seen. Yeah, they don't want to feel micromanaged. But it is good to always ask like, how do you like to be managed? You know, think of a manager that you had was really great. What do they do differently?

Yeah, and, and something to add to that, like a third, a third document perhaps is a How to work with bdoc. Have you done this before? Yeah, yeah. I, I think this is so useful and I, I recycle the same how to work with me document at this point and just update it. Basically this outlines. Here are my working hours. Here's how I prefer to correspond with people. Is it email? Is it slack? Here's, you know, how you can expect me to communicate outside of working hours. There are certain times where I'm actually available because of different time zones. Other times, like don't contact me on the weekend unless it's absolutely necessary or like after a certain period of time. How do you like to give and receive feedback? Some people like to have a lot of like external validation in the work that they do. Like they want to be celebrated by others. Some get really, really uncomfortable if you compliment them in public. Understanding that and then especially on the constructive criticism side of things, like do you prefer to have a face to face conversation? Do you prefer to have it in writing? Like how do you like to communicate? Do you prefer like a, let me get straight to the point and tell you what's going on or do you want me to sugarcoat it? And that's not necessarily a bad thing. Again, there's a lot of cultural implications to how people communicate. And I can tell you certain people on my team who, they want me to sugarcoat it. They want me to be as gentle as possible with them and others who are just like, this sucks. Like this is not good work and here's why. And you know, that's part of learning, learning about your team. And then I also like to include some more like personal things on it. Just like here are my hobbies. Like here, like I like to run and I like to read and I, you know, I'm into Pilates and like that kind of stuff. Just so like if you want to talk about something not work related, you kind of know, you know what I'm interested in. I like having this available to anybody who joins my team or a team that I join. And that goes for like pe, my upper management, any kind of like cross functional leaders that are. That are involved, just so they know how, you know how I like to work as well.

Yeah, we. I love those. We did them as well. There was one question, I was like, what's an assumption that people make about you that's wrong? And I was like, oh, that's a good question. But we all presented it to one another when we formed these new teams. We did them in person and it was really, really nice. So do recommend that.

I love that. I love that you could do it in person too. That's such a. In a world where a lot of companies are still fully remote or mostly remote or even somewhat remote. Well, we are.

We are fully remote. Yeah. And we're spread across like the EMEA time zone as well. So it was kind of like a. We get together once a year and team build and love that. Nice. Yeah.

So that's building trust. The next thing I would talk about earlier on in your first 90 days is more around understanding. And this kind of goes into the how we work with me side of things. But, like, how does the, the team need to function? What kind of rituals do you need on your team? How do you want to know what we have coming down the pipe? Are you the type of person who likes to balance multiple small things at the same time? Do you want like one meaty project and one small thing? Are you, like, I can only focus on one thing at a time. And understanding, you know, how each of your team members work and how this fits into the overall roadmap as well will help you get better alignment on how to best set your team up for success. To actually deliver against that roadmap. The last thing I want to do is say, all right, here's our roadmap. I know none of you. I don't know what your strengths are. I don't know where you want to learn and grow, but I'm just going to assign these randomly and we're going to hope for the best. Nothing good comes out of that.

No, not at all. Yeah, we're always like our team. Like every six months we try new things just to see, like, okay, this maybe isn't ideal. Like, for example, we were running into a situation where, like, certain people had very specific domain knowledge features we were building just because they were the ones working on it for a year at a time. And should anything happen to them, like they go on vacation for three weeks or they move teens or whatever it was, we'd be at a loss. Like, we will not be able to we were lacking documentation, probably that was problem one. But what we realized is it's probably good to circulate people on work streams more frequently and pair someone with good knowledge with someone new to the work stream. So we started like pairing up people based on who hadn't worked together and who didn't work in this domain before. And yeah, I think just having those conversations as a team and I know if you do retrospectives, but we do them every two weeks, sometimes they're more like emotions and feelings oriented, like how are you as a human being? And sometimes they're more about, hey, how are we doing on our roadmap the cycle? How did the last two weeks of work go? But again, don't come in and just start changing things or adding more meetings. Here's a secret, nobody likes meetings, so don't come in and add a bunch of meetings. So yeah, I think just observe, ask people what problem areas they see if there are any improvements that can be made. Also being very clear about whose job is what, who does what job. Like with our product manager and designer, we had like a big retrospective around planning, which is a huge event where we plan for six months and we had, we had to have the conversation whose job is each of these tasks? Because we were getting confused who owned what. So it's not just about having those conversations with your team, your, your like direct reports. It's also about like your peers and the, the other people you work with.

Oh yeah, yeah. I remember in the past when I started working with a new product manager, they were used to running both product and engineering before I joined the company. And there was, there was a lot of stepping on toes to the point where, you know, at one point I had to have a very frank conversation with this individual and say, you need to let me do my job. You have plenty on your plate to do. Let me do my own job. Thank you. Which is not a fun conversation to have ever because I don't like to be like, stay in your lane. But if I'm not able to do my work and my team is confused around who to go to for certain things, then you know, that's it. That's an alignment problem.

Yeah.

And that is something that needs to be addressed. And those, those peer relationships are so incredibly important. And again, I'm not talking like your fellow engineering leaders, which is also important, of course. I'm talking like the day to day cross functional leader, like relationships you have with design, with product, because these are people who don't necessarily work in the Same exact field. You know, occasionally you'll find an engineer who has been a designer before or vice versa. You see a lot more product engineering swaps than anything specifically engineers going into product. But for the most part, you are the expert in your space. They are the expert in their space. And making sure there's clear alignment of who is doing what and who is responsible for what is so important. Because if nobody owns something or you're like, duh, this will just have like, whoever can grab it, grab it. It doesn't get grabbed, it won't get done.

Or on the flip side, if you have stuff that you're doing you don't have time for or shouldn't be doing, have that conversation too.

Like, hey, can you take over this?

This is more in your domain anyway.

Exactly. You can't do everything. And, and I will say that's one of the, the most common pitfalls you see when you start a new job is like, you, you want to, you know, impress your manager. You want to show that they made a really great decision by hiring you. And so you're going to try to take on a lot. You're going to try to, you know, follow through with literally everything that you have on your plate. And that's not always the smartest move to make. Sometimes you gotta take that step back and be like, okay, I don't actually know what's going on here. And also there's somebody who would be much better suited for owning this or managing this, and I can learn from them. That's not you not doing your job. That's you literally learning in your first 90 days as you should be doing.

Yeah, absolutely. So, okay, once you pass the initial building trust, achieving alignment, what's next?

We kind of touched on this earlier, but the, you know, making sure you understand like the business and the technical side of things, like what is your stack? What are you working with? What goals have been set at the top level for your team? Have those goals been set or is it your responsibility to help establish those goals? This is especially important for like a new organization or a new team that is spun up based on, you know, a new initiative that the business is taking on. And then like talking to the team, talking to peers, and really understanding like what's work, what's, or what's working and what's not so you can identify where process improvements are necessary. Because again, the last thing you want to do is just change a bunch of stuff for the sake of changing it. Be like, I've made my mark and Everything's going to be better now after that. Then it's really focused on like building influence wherever you can. So why don't you kind of kick this, kick, kick this one off.

What is influence?

What is influence?

I need chatgpt at this point I guess. Yeah, that's a really good question. It's not something I've actually thought about. I guess it's the ability to, I don't know. How would you define influence?

Actually I actually I asked this in my course which is why I wanted to ask you. It wasn't, it wasn't a trick question or anything but like I actually ask everybody who takes my, my leadership course, like what, how would you define influence? Like what, what comes to mind when you think about somebody who is influential. And the most important part of influence, it doesn't really have anything to do with your job title although you do have some built in influence as a matter of being like a manager or somebody who is more senior. But it's, it's your ability to make impact in whichever way makes the most sense for your role at your company and for those who are, who you have to interact with on the day to day basis. It's those who say like okay, if I, I know that you know, if I need, if I have a very specific problem that needs solving. Kelly knows how to work, work this through even if it's outside of her like domain expertise. I'm not saying like there's this very specific react bug. I'm saying that this project is going off the rails and it has nothing to do with engineering. But Kelly's good at understanding how to get a project back on track. So let's bring her in. You're having influence outside of your like, like individual domain of expertise and as you become a manager, as you move into a managerial role even within engineering, that your scope of influence is going to change over time as well. At first, like you are looking to make sure, like your job is to make sure your team is delivering against the roadmap at a high quality and on schedule. That's going to evolve over time of like building those relationships and understanding that you have a high level of trust. You have a high level of leverage within the company as well to be able to influence the roadmap and suggest changes to it or process changes. These are the types of things they require trust and they're not going to happen overnight. Which is exactly why we say don't go in and change a bunch of things as soon as you start a new Job.

Okay, but here's a loaded question. What's the difference between influence in that sense and influence in terms of like getting people to do the stuff that you want? Because one is. Yeah. The other is like psychological manipulation. But it can fall under the umbrella of influencing.

No, one is influence and one is authority is. Yeah, okay. Authority is the role that you have and the, the, the. What's the word I'm looking for? If like my boss asks me to do something, they have the authority to do so.

Right.

If my fellow product manager asks me to do something, they don't have the authority to do so. But they might have enough influence and trust built up with me to say, hey, yes, I'm happy to do this for you.

Okay, that makes more sense then.

Cool. It's actually also run a session called Influence without authority of how to build that influence in an organization without having to be a manager.

We gotta link that in the show notes. Apparently I need to take that.

It's actually a free, free recording that I can link to, so you don't need to.

I'm just waiting for it.

I also give it at conferences as a talk if anybody sees them at their conference.

We do love free things. Okay, that makes a lot more sense in terms of. Yeah. I don't know anything else we should mention about influence. I feel like you covered a whole conference talk in three and a half minutes and I've learned a lot.

Good. You know, it's funny, I've given the same conference talk for a 20 minute talk and a 45 minute talk, same thing. And I don't change them at all.

I'm going to guess the 20 minute talk is harder, isn't it?

Oh, absolutely. Because I can paint such a nicer picture with 45 minutes and give you a lot more examples instead of just like, we're going to fly through this deck. It's a pretty deck at least. Like that's, that's the, the content's great, but if you feel like you're just drinking from the firehose because there's a lot of content to get through, I.

Guess the takeaway here in my mind is like, you can't force your like influence upon someone. It's something that's almost earned. Like if I don't like your point about the project manager, the product manager coming to like one of the engineers, like, hey, can you do this? Like if you don't have influence with them or trust or you're not a good leader, like they can say no to you. It's not something that you can like demand from people.

Exactly. You can't demand respect, you can't demand influence. I mean, you can try, you can try all you want.

I demand respect from my three year old. It doesn't go very well.

You can keep on trying though. It's fine. Did you have the authority? Perhaps I do have the influence.

I definitely do not. But speaking of failures.

What are the.

Common pitfalls that you see people succumb to in the first 90 days?

Trying to do too much at the outset is probably number one, it's the biggest one I see. I remember a conversation that I was having with somebody who was starting a new role and they were trying to really make a difference and show again that this was a good decision to hire me. And so they were like, I'm going to come in with so many suggestions. And on day two, they suggested that they move from GCP to AWS. There's no way in 24 hours you have figured out that there is a fundamental issue on a cloud platform that's going to require the move from one platform to another. There's just no possible way, you know, you do not have enough information there. Like, this is the whole point of like spending your first 30 days learning as much as possible because there's no way you can. If I were to ask you why you're not going to be able to really dive deep into like the business use case for that, you'd be able to say perhaps like, well, I have a lot more experience with AWS and I know it'll work better. But like, cool, that's about you, that's not about the business. That's number one. Number two, I would say is getting a little micromanagy at first. This doesn't happen so much if you're joining a new company because you're still establishing trust with people. But it can definitely come through if you're taking over a team that you were previously an engineer, like an IC on and you become a manager of that team because you're suddenly like, oh, well, I had the influence of them and now I have the authority because I'm their manager. And so I'm going to now change the way they work and I'm going to like change their process because I. This has bothered me all this time and I know it's an issue on our team and now I can do something about it. People generally don't like to be micromanaged. The only time I like to be micromanaged is when I'm doing like a Lego set, which is like, now you take this piece and you connect it with this piece. Other than that, I don't want to be micromanaged. I'm good at my job. And typically I feel like most people are good at their job with, you know, some gentle nudges here and there to make sure they're working on the right thing and perhaps in the right manner if it's like a very vague project. But most of the time, people don't want to be micromanaged.

Yeah, yeah. This is something that I struggle with, is feeling like I am micromanaging people when in reality I'm not. It's. For me, it's more about. I've made my intentions very clear with people where I'm like, hey, if you feel that I am creeping into micromanagement territory in terms of like, who's working on what work stream or what work is coming up next or things like that, just tell me to step off a little bit. But what I told. Or like, if I'm messaging you all the time to say, like, hey, what's the status of this? What I've told them is it's not because I'm checking up on the status of your work. It is because I have adhd. I cannot remember the. All these moving pieces. We're doing like 10 projects simultaneously, which some. Most of them, I don't still understand all the nuances of what we're doing, which is a problem. But I've made my intentions very clear with them. Like, hey, I'm not here to micromanage you. If you feel like I'm overstepping that boundary, please just call me out. My intention here is I need to, for my own sake, make a notes document with the status of things so I can. Can convey that to stakeholders and for my own sanity. And here's a document. You're welcome to update it on your own. You're welcome to see it like it's for everybody. But that was the one thing that I. I don't want to say I have imposter syndrome over, but I do consciously worry about is like, do they think on micromanaging them? And ultimately the answer is no. But it. I think it's because I've made my intentions clear and I've explained why I'm doing what I'm doing. No one likes micromanagement. Nope, not at all. I was going somewhere with that, but I.

No, I mean, it's gone. But that is a. Like, you're making. You're Making a good point there. And I think that's also important to address that. Like what I consider to be micromanagement might not be what you consider to be micromanaged.

Right.

And again, it's all about, you know, are we working in a way that like, do we have alignment in the way that we work? Is our working model working? And that is an important question to ask people. You know, I have other people on my team who I'm like, they're, they're really good on their own. Like they don't need my health self managed or they're like very self managed when they might feel like I am neglecting them because they're like, if they only come to me if I'm doing something wrong, but I want to know that I'm doing okay. I need that extra touch, like just a check in of like, hey, how are you feeling? Do you feel like your work is making sense? Like, are you blocked on anything and that's not micromanaging? You know, I'm for others. I need to tell them like, hey, this is the project that you need to work on and these are the steps that you need to follow and this is how you're going to do it. Typically when they're on like a PIP or they're at risk of being put on a pip, they need that higher touch for a reason. But again, as you said, you're explaining why you're higher touch in some areas than others and then you're like, okay, well there's no question as to why they're acting the way they are. There's actually something here that we're working through. And sometimes for people, I will ask them, like, I feel like they're not spending their time wisely, but perhaps I've taken over a new team and it's somebody on the team where I'm like, I feel like I should be getting more out of you and I'm not. And so I want to understand like how you're spending your day. Like I, if I see that you're actually in way too many meetings that you don't need to be a part of, I'm going to help you clean up your calendar. If your meetings are so spread out throughout the day that you have a context which all the time is you're never really able to get like deep work sessions in, I'm going to help you with your calendar. If you're helping by like jumping into projects because you feel like your team needs the extra support and they really don't but you just like, like doing that job. Then we need to talk about whether or not you're in the right role.

Yeah, no, that makes total sense. Yeah. So I guess that's a good point. Micromanagement means something different to everybody and every team, so it's better just to have that conversation. Yeah. For me, I think it's more about my team cares. More Like I don't come in and tell them how to do their jobs, but I do come in and ensure that they feel supported, that they have what they need, that I understand what the blockers are or whatever. And then sometimes they'll even come and ask for me to step in at some point and I'm like, okay, that's awesome. Happy to do it.

Yep.

On my side, I have two. The first would be neglecting the cultural aspect of being a manager and only focusing on the technical side of what's working. What's not working, the cultural aspect is, I almost want to argue, more important, because if you don't have psychological safety and trust, you're not going to be performing to the highest ability as a team. So understanding the cultural differences in your team members or like, is there any friction anywhere? Do people feel safe, et cetera, is very important. The second thing is that not everything needs addressing and not everything is an emergency. So if I've told this story before, but like, we do health checks every six months to see how people are feeling on the team in regards to many aspects like psychological safety, inclusiveness, many different areas, technical debt, work, life balance, et cetera. So it's all anonymous. People basically give it like a green, yellow, red traffic light rating. Red means like, oh, heck no. Like, this is not working for me.

Green.

It's like, yeah, everything's good. Yellow is meh. I don't know. We stalk about it and they can leave comments, but someone had left a red on psychological safety, which superficially seems like it's a huge problem. And I would argue that it is. However, I failed to take into consideration the other aspects of this. The other aspects where I had left the anonymous survey open to anybody in the channel, which meant that anybody could.

Go fill it out.

Any of the 42 people on the channel. And I only have seven engineers. So the math was not mathing. Come to find out, it ended up being somebody who was not part of my engineering team. It was someone that we worked tangentially with. They ended up having a problem with another team member who was also not an engineer. So their red rating, it was almost. And it happened like six months prior. So it was not relevant to the discussion that was being had. The goal of this survey is for me and my engineers to discuss how we're doing. So that was a circumstance unforeseen. However, I had somebody come to me on the team and said, I've never seen a red in this area. We need to do something about it right now. So me being a new manager, I'm like, yeah, of course we do. Like people aren't feeling safe. So I scheduled an hour long workshop with everybody on the team, engineer wise to establish trust and psychological safety. Only to find out everybody on the team feels great, they all trust each other, psychological safety is not a problem. So it was an hour wasted for seven engineers. So seven hours of engineering time. So my point being not everything is the emergency. It might seem face value and it's much better to sit and evaluate and if you're uncertain if you should act on something, talk to your, your manager or a mentor or somebody else. There are cases of course in like that you do need to act immediately. Let's be clear about that. If somebody's being harassed or if somebody comes to you and tells you they feel psychologically unsafe, that's a different situation. But yeah, in most cases it's not an emergency and a lot of times things resolve on their own. So those would be two pitfalls that I myself have. Well, I didn't fall into the first pitfall, but the second one I dug for myself and then threw in myself into.

So yeah, no, I mean I think these are all common pitfalls for a reason. And you're, if you as a new manager or as a, as a manager starting a new role, like you can find yourself in these positions and it's not a judgment of you or your character. They're common pitfalls for a reason. When you're in the thick of it, you don't notice. If somebody brings what you deem to be a crisis to you, you're going to react accordingly. You're going to go into crisis mode. If everything's a crisis, then, well, that's a different conversation. But like it's normal to experience these. And that's why we do these pulse checks for ourselves. And that's why we evaluate ourselves, you know, every 90 days, every six months, be like, are we, are we delivering the way that we should for our team and for ourselves as well. So I think that's a good way to wrap up this, this episode.

Indeed it is.

We'll just wrap it up with your failures. That's fine.

I love that. No, as a.

As a last.

Last note. A lesson I learned pretty quickly as somebody who feels very deeply and is very emotional, is that as a manager, you're going to struggle with this. And there is a difference between empathy and compassion. Empathy being. You sit with them in their emotions and almost absorb some of them from what I understand. And that is not necessarily the best way to do it. Compassion is like, hey, I'm with you. Like, I see what you're going through. It's really tough. I'm here for you. But you don't take on, like, their difficulties as your own. Like, you're still able to maintain that boundary. And that was an important lesson I had to learn. And I learned that from your. Or. It reminded me of that when you said, like, not. What did you say? Like, everything's a crisis. That was me in Miguel. I'm like, everything's a crisis. I'm sitting with all these people in their emotions, and then I'm like, but I don't have to. I can still be there for them.

Yes. Not to mention some of these crises are, like, genuinely just like, they're fires that exist.

Yeah.

Occasionally, like, you're going to have to let a fire burn because it's. That's not a huge fire. But there are other more important fires that require your attention.

Indeed. So speaking of fires, I have. That was not a segue. I have nothing to say about that. But resource of the week.

Yeah. So mine's very topical. It's a book called the first 90 days by Michael D. Watkins. Walks you through a lot of the similar things that we discussed today. I think both you and I have some qualms with the book, that it's not, you know, perfect. Not that I would expect any book to be perfect, but if you're starting a new job, moving into a new role, changing teams, I think it's always a good refresher just to remember, like, kind of, again, like, that reset of, like, okay, starting like this is an opportunity for a fresh start. How am I going to approach this?

Yeah. Definitely has some good practical advice out of that one. One of the nonfiction books I really enjoy from an author I really enjoy is called Think Again by Adam Grant, where he basically challenges you to spend a lot of time rethinking things or as much time rethinking things you believe as well as thinking about things for the first time. So always challenging your own assumptions and beliefs.

That one has been on my bookshelf for a very long time and I need to actually read it.

Yeah, I really liked it. It was a good one to know. That's new.

Awesome. So this wraps up episode three. Thank you so much for tuning in. We are on all forms of podcasting, so subscribe, like, follow whatever else we do.

What all the influencers are saying these days.

Five star reviews. Yeah, leave a five star review, please. Like just say nice things about us. That's how big your. All right, see you next week.