The Team Is Good. So Why Do I Hate Going to Work?

Transcript is auto-generated and may contain errors.

Hey folks, we're going to go to the Experience Dev subreddit. And this topic I thought was pretty interesting because I don't think we've talked about this kind of thing before, but someone was asking, "Have you ever joined a team that wasn't like bad in any way, right? Like nothing really is standing out to you. It's like, oh, this team sucks or there's a, you know, shitty person on the team or whatever." It's hey like team is good but something about the team and how you work you're just not really they use the word gel like you're not jelling with them. Um, and so they were giving an example about a team that they had joined that again they're like on paper everything seems good, nice people, work is interesting, but they were saying like for them uh weird thing is that like there's this like what what feels like an over-the-top like pair programming mob mentality of like okay, there's an issue to solve like we all jump on it and do it.

and they were saying like for them like that that's just kind of odd like that's not really how they like to work I guess and so when they've talked about it you know people were saying hey that's just how we do things on the team so this Redditor was asking like hey like are there other examples of this that people have kind of uh worked through and and what did that look like how did you kind of work around things so um I don't know like I haven't fully thought of this and I thought it would be kind of fun to talk through uh based on at least my own experiences and I can do a bit of reflection on that. And before I dive into any of it, just a reminder that if you have questions about software engineering or career development, leave them below in the comments.

Um otherwise, you can go to codecame.com. You can ask questions anonymously and I'll make a video like this one to respond to you. Um and yeah, of course, if you have different thoughts on this kind of stuff as I'm going through, just yeah, leave them below in the comments. Other people can can see what you have to say because I think this is a pretty interesting question. When I read this post and I was thinking, okay, well, what does that mean for me? Like, have I experienced this? Um, if I have and when I have, what does that look like? Um, and I think there's nothing in the way. Car, why are you beeping at me? I think that um the answer's like kind of yes, but I don't know. But when I was reading what this person wrote, I could I I couldn't figure out how much of this was like they were really bothered by it or like it's a problem or more of a curiosity.

And I wanted to to start by saying for me, I don't think I've ever had like a problem this way or I was like, oh, like got to get off this team because it's something's off. But it's more like, hey, like something I can't put my finger on uh super easily makes me think that like there's there's something off here and I'd like to understand it better, I guess. So, it's not what I'm about to talk about is not like, oh, this team was the worst. It's it's quite the opposite. like great teams and like was there something weird about this that you know that that that made me feel like either an outcast or like working inefficiently. So for context um even up to this point most of my career uh like where I yeah the longest job I had at a place was magnet forensics.

So that would have been 8 years. And what was unique about that is that like when I started there, the engineering team was like just getting formed, right? Like there was there was one engineer and then they hired like uh they had a senior engineer that was hired right after that and then they onboarded a couple of us. So like we were there at the very beginning of this engineering team and and then being there for 8 years meant that like obviously the company culture the teams and stuff are changing over time but for the most part like there was a lot of I I feel like kind of steering and ability to navigate like what's going on around me because um yes with a lot of company growth there's absolutely things that are just outside of like my control and influence But also at the same time like like I'm kind of in it from the start and I can see how things are changing, right?

So the teams and things that I uh participated in while at Magnet Forensics, I feel like for the most part were a situation uh that are not representative of what this person's describing. Almost the opposite, right? I'm like, "Okay, cool. get put, you know, get good people together. We're we're jelling since near the beginning. Um, we got to find a better word than than jelling. Um, but that's what they use. So, you know, that was a lot of my experience for a long time was was that kind of thing. Now there were there were periods where you know um I like I had formed like new smaller teams and stuff like that and there'd be periods of like okay we got to get the team moving and grooving together. We're just going to use all the awesome words today but um there are periods of that but ultimately I think that was really just the team coming together and forming and figuring things out.

But I would, you know, I would say a lot of that time period was just mostly pretty cohesive for the teams I was working on. Now, the differences when I think about parts of my career could have been my internships where I feel like I was maybe a bit of an outcast um or something maybe was not quite right. But for me, I kind of attribute that to maybe. It's just because I was inexperienced and literally like literally an intern like I'm brought in here for a very temporary period and then the other side of that is coming to Microsoft and so for me the most relevant examples of this are at Microsoft and not because there's anything wrong with the teams it's again it's the opposite right um I've been on two different teams at Microsoft and I'm like I'm still there so as

I'm talking about this uh this is why I said this isn't a matter of like oh the team is bad or anything like that not by not by any means but things are different right things are different than how probably I think about operating and how I've been used to doing things so even when things look really good on paper you have uh great people on the team you're working on cool stuff just sort of like team culture team dynamics there's little things where I'm like ah like that's not just what I'm used to. Okay. So, like uh the deployment team for me was a few years ago, so it's not as fresh in my mind as I'm blabbing away here, but you know, I think a good example on the team I'm on right now is there's a lot of design doc writing. And like I don't think there's anything bad with design dogs, right?

like there's uh and I've talked about this in other videos, but like I don't think there's anything bad about it. Um but the the approach that we take for it is not something I'm used to. I'm not used to having, you know, uh a one-page design dog and then like blowing that up into a bigger like architectural design dog. Like I'm just not used to doing that. um the you know the extent that that's expected I'm like I'm not used to that but again like I do see value in doing it like it's not that it's a problem it's that I'm not used to it. So it makes me it's like one of the things that we do within the team where I'm like oh like that that's a little weird for me right and it's not a big deal right it's really not but

uh I'm saying this because this is an observation I had where when I think about how I operate in the team or sometimes why like there's certain things that make me feel like I'm I'm outside of it that is one such thing where I'm like that just feels a little odd, right? Um I think if I use an example coming from the deployment team over to um the routing plane team that I'm on now, uh one of the things that we like we do on both these teams and uh because we're platform teams, we have a uh like a service review that's uh that's across our broader team every week. And when I was on the deployment team, that was used extensively for um two things. One was reviewing like any incidents. Incidents in this context are they could just be monitors that fired or they could be like escalations or we had to get involved.

So it's kind of all the above. Um but also metrics. There was a huge push on once a week for the people that own different parts of our platform. Let's make sure that we're showing and talking about the metrics, right? Not and this needed to evolve over time, not just metrics for the sake of metrics, but like what's interesting, right? If everything's the same, everything's okay, then great. Like say that, move on. But if something is an outlier or there's a trend, we should talk about it. So on that team, there was a you know, in this weekly service review, there was a lot of like thought and emphasis around like let's talk about the metrics. let's let's surface this for the team and to me like that was new because I didn't have to do that uh coming from desktopbased software before but it

was it was it made a lot of sense to me I'm like this feels good when I came over to the routing plane team we also had a weekly service review but there was a lot of focus on um I guess like the the same type of like uh monitoring alerts and uh and incidents which again that was common between the two but I actually felt like an outlier or like uncomfortable I don't know the right word but uh where I was like hey man like we we used to have so many metrics that we would go over and this in my opinion this routing plane team has significantly more data points like there is so many data points that we could and should be looking at where I was like wo like what like this just feels different like I feel like I'm the outlier want like wanting more of this data.

Um now I've been on this team for a few years now and like these types of meetings and things fortunately evolve over time and and that is like one of the things we focus on now but initially I felt like a bit of an outsider um to this team or there was something that made me like uncomfortable and I couldn't really figure it out but that that is one such thing. So I mean you could go through this exercise for yourself, right? I'm going to spend less time talking about examples now um because I just wanted to give you some so you could think about this for yourself. The other part to this person's question though was like not hey do you have examples it was like what do you do right so I think one thing that I will always say um and it's

not specific to software engineering or anything like that but I always say like awareness is like the first part right so I think having awareness that you're like hm I'm on this team things team is good work is good but there's something and I can't figure out what it is that that I feel a little off about. Awareness, right? Like you have some awareness of it. So don't don't let the awareness be something where you're like uh or sorry like that that signal where something feels off. That's a feeling, right? Don't don't dismiss the feeling. Don't say like, "Oh, it's a feeling. It's not a fact or there's not evidence. Like dismiss it." No, it's a feeling. So something's up. But like what you do with that I think is what's more important. So I would say awareness is really important. So now you're you're noticing something.

You don't have the answer but you're noticing it. So as you become more and more aware that gives you more opportunity to kind of tune into like well what is it? Like when do I start noticing this feeling more? Right? Like maybe in the beginning you're like it just kind of comes up seemingly randomly and then maybe over time you're starting to realize oh it's it's uh every time we're doing a new feature and we're talking about the design dock for it. Back to my example like maybe maybe that starts to become more of the signal and you're like yeah but what about that? And then you start kind of getting more in tune with like oh like something about design docs like maybe because I haven't done uh that in the processes heavily before whatever it is right but you have some awareness and

you start picking up on these things I think it's really hard to take any kind of action without some kind of awareness right so don't dismiss the feelings it's just like kind of lean into them see where they're coming from and then it's about what kind of action you're going to take. I would say um once you start identifying like something that's up I think there's a couple different things like one is like uh also like sharing your perspective on these things with your team, right? Maybe things are a certain way on the team because that's how things have been done and like they've gone unchallenged. Maybe maybe it's time to challenge them. And the word challenge, I'm not saying that to you go tell your team like design docs are the dumbest thing ever. We're never doing a design dock again. Like I'm making a stand.

Like no. Uh what I am saying though is like if if something feels off about that, like is that enough where you you feel comfortable saying like, "Hey, like you know, why are we doing design docs like this? I'd like to understand better." And like if you have a different opinion about that, why don't you share that? Right. So like now you're bringing awareness to this conversation, bringing some different perspective and that doesn't mean like the the goal isn't necessarily like I'm telling you sit everyone on your team down and tell them like you're changing how design docs are done. Like no, not not the case. It's more like hey this is how I feel about these things. I'd like to understand from the rest of the team, whoever's willing to kind of share like why we do things a certain way and then and like having them hear you and you hear them, right?

Because it might be that there's other people on the team that are like, "Yeah, you know, we kind of just have fallen into this habit of doing things this way." And like, why do we do it? I mean, there's probably some reasons, but if you were to ask why we haven't changed, maybe the answer is, you know, everyone's uh favorite phrase, like it's always been this way. We've just always done it, right? That's not like that's a reason. I wouldn't say it's a a great reason to to not change, but it's definitely a reason. So, you know, are you able to kind of share like what if we try doing things a different way? Like are people open to that? And if not, why not? what's that look like? Right? I think starting those conversations is important because otherwise, you know, nothing nothing progresses, nothing evolves.

It's always just kind of flat. Uh and in fact, I would say uh sort of the opposite happens if you don't have enough of this happening on a team where people are overtime challenging things. Again, challenge is not uh please don't interpret that as like causing problems or like you know trying to to be a jackass and disrupt things like that's not what I mean by challenge. When I say challenge I'm saying there you have a different perspective and you are like challenging the status quo. Why do we do things this way? What about this other way? Have we thought about that? If you don't have that happening on a team, literally as things around the team evolve and change and the team itself is not changing, it will quite literally fall behind in terms of effectiveness, things around us change. And so if the team does not change and adapt and I would say this is one such mechanism to do it, then I I believe teams fall behind.

So I like I'm encouraging you to do this. I think it's really this is again why communication skills and things are super important. Um but you should I think it's really important that you do. The flip side to this is that the the goal is not to push your agenda and make people do all the things you want to have done, right? Like the goal is that I mean there's a couple goals. One is that you you want to be on a team that you enjoy being on, right? Seems like there's a lot of good things on the team. So like you're pretty motivated to be there and maybe a couple things that are making you feel like something's off. So you want to be on this good team. You want to make this feeling that something's off or something's out of place. You want that to go away.

And ultimately like we want to be on a team that kicks ass, right? Like we want to be part of that. Like I think it would be a silly statement to say that like people like aspire to be on a team of people they don't like working with building shitty software they don't like building. Like you might say that you are prioritizing other things over that. Like maybe you would do that if they paid a lot of money. Like sure but if they paid a lot of money and they were an awesome team and you were building cool that's probably an even better state to be in. So if you want to be part of like a team like this, I think it's important that you're you're kind of raising awareness of this stuff. But the goal is not to make people do what you say.

The goal, you know, is to be comfortable on on this high performing team. So that also means that when you're having these conversations, you're not having the conversation just to push an agenda. You're having the conversation to understand. And that I think is easier said than done because I think for some people um some people it is like okay well you know this guy on the internet saying go have a conversation with people and like okay like that's going to be tricky and I don't want to do that but okay I'll go do it because when I go have this conversation I'm going to I'm going to tell people how I feel so that things change. And it's like the the goal is not to drive that. The goal is like you need to go in seeking to understand, right? Like you want people to understand your perspective and you need to take some time to understand theirs, right?

Like both sides are valuable. So I'm just trying to remind you not to to rush in to go change things. Like you want to make sure that there is this opportunity where you can understand right to to go back to one of my examples when I came from building desktop software to go you know work on the Microsoft uh 365 deployment team they deploy a huge like they deploy services it's a whole deployment team but they have uh like infrastructure for that deployment that's not desktopbased software it's like it's for big distributed systems. So there was a lot of understanding I had to do of how they worked, right? Even if it was different from how I do things, like to give you one more quick example, like for a lot of us that are building software, like you know, we want to make sure that we can have uh a quick turnaround time, right?

So for example, you have a pull request You don't want to have a poll request sitting open for three weeks and then by the time it's actually taking effect in the system, it's another four weeks, right? It's like 2 months or something to get a change actually done. Like that's that feels crazy. But with a big team like sorry, a big responsibility that this deployment team has, they literally need to bake in mechanisms for deploying things safely. So they literally need to slow things down to make sure that like the technology can make things go fast, but they have process in place to slow things down. So for me, I'm like, "Oh, that feels terrible." Like why why would you slow things down? Like we're trying to get agility. We want to be able to, you know, land our changes and move on to the next thing.

And it was like, hey, like there's hundreds of thousands of machines and the potential to impact like hundreds of millions of customers. So like, you know, doing this for hundreds of services, the blast radius could be pretty big. So like we do this for a reason. And so like taking the time to understand why things are done a certain way I think is super beneficial. And so, uh, you can kind of get to this spot of like, hey, I feel better about this on the team, not just by changing it, but by taking the time to understand it. So, anyway, those are my thoughts on this Reddit post. I thought that would be kind of fun to talk through, but be curious to hear from you as well. So, if you got thoughts on that, leave them below in the comments or like I said earlier, if you got questions about career development, software engineering, below in the comments or code.com, then I'm happy to make a video response for you.

Thanks and I will see you in the next one. Take care.