Speaker 1: So what do you do to earn the trust of
Speaker 1: the team as a TPM.
Speaker 2: Don't be a know at all. Yeah, don't make assumptions,
Speaker 2: have extreme empathy and listen. As a technical program manager,
Speaker 2: you're often the one that's kind of in the shadows
Speaker 2: a little bit, right, Like you're the one who helps
Speaker 2: other people shine, go outside, go on a walk, be
Speaker 2: in nature. We are way too connected to technology and
Speaker 2: I think our human brains can only handle so much.
Speaker 2: And with AI, it's just like way you know, made,
Speaker 2: it's made the problem even worse.
Speaker 1: Hello everybody, and welcome to the Devlife Podcast. I'm here
Speaker 1: with Brooke. Hey, Brooke, Hello, how are you Hey? Doing good?
Speaker 1: How are you doing good?
Speaker 2: Yeah? Just new year, lots of great things going on.
Speaker 2: I think twenty twenty six is going to be a
Speaker 2: really positive I don't know, so I just feel really
Speaker 2: good energy this year.
Speaker 1: So me too, I really feel it too. Well. I'm
Speaker 1: really excited to let everyone know. Today we have a
Speaker 1: very special guest, which is Brooke. She is going to
Speaker 1: tell us about being a TPM. So let's start with that.
Speaker 1: What is a TPM? Brook?
Speaker 2: Yeah? And yeah, what is what are There's too many
Speaker 2: acronyms in life a TPM technical program manager. So I
Speaker 2: actually I have a little bit of a windy journey
Speaker 2: in my career, but when I look back on it
Speaker 2: at all, like lines up really well. I mean I've
Speaker 2: gone from getting a master's in education, being a teacher
Speaker 2: for a while, becoming a software engineer doing that for
Speaker 2: a while, and then that led into my manager suggesting, Hey,
Speaker 2: you know, you have a kind of a knack for
Speaker 2: working with people and would you ever consider becoming a
Speaker 2: technical program manager? And I honestly was like, I don't
Speaker 2: even know what that is, but I love it. And essentially,
Speaker 2: a technical program manager is someone who's kind of like
Speaker 2: connecting the dots across teams and departments. So when there's
Speaker 2: a program, when there's an initiative that the team is
Speaker 2: working on, rights, it's the TPM who can really be
Speaker 2: the one that comes up with like the program brief
Speaker 2: and really lays out the foundation for what are the
Speaker 2: problems we're trying to solve, what are the suggested solutions,
Speaker 2: What are the phases that we're going to go through
Speaker 2: to accomplish this? Who all is involved, how are we
Speaker 2: going to execute this? What meetings do we need to
Speaker 2: set up, what channels of communication do we need to have,
Speaker 2: how are we going to get buy in and align
Speaker 2: the stakeholders, but then executing it too, basically being the
Speaker 2: person who looks over everyone's shoulder to make sure that
Speaker 2: things are getting done and if there's a problem or
Speaker 2: if something isn't quite working, we fix it and we
Speaker 2: make it happen. So, you know, really like seeing the
Speaker 2: full picture and really executing on that and just being
Speaker 2: kind of the backbone of the project or program.
Speaker 1: Wow, yeah, that's such a big role. Like as you're
Speaker 1: describing this, it sounds exactly like the role of what
Speaker 1: I was missing when I sold my business and kind
Speaker 1: of why I sold my business because I couldn't do
Speaker 1: all of that, you know. And so, man, if I
Speaker 1: could go back in time for you looking back now,
Speaker 1: what actually changed for you when you moved from engineering
Speaker 1: to TPM and can you talk a little bit to that.
Speaker 2: I was really fortunate because it wasn't such a like
Speaker 2: a you know, one day I'm an engineer. In the
Speaker 2: very next day, I'm a TPM at Limble our company.
Speaker 2: Because my manager saw that I had, you know, he
Speaker 2: knew I was a GDE. He knew I was running
Speaker 2: this meet up, I had a podcast, and he could
Speaker 2: see that I was just like on the side, even
Speaker 2: though I was doing all of my programming and like
Speaker 2: software engineer tasks, I was also organizing all these events
Speaker 2: and like putting things together. And I think he saw that,
Speaker 2: you know, like saw that I was gravitating towards doing
Speaker 2: these other things, and that where he was like, well,
Speaker 2: we do have a need and right now we only
Speaker 2: have our lead TPM, but we know she needs help,
Speaker 2: and so he's like, have you ever considered going into
Speaker 2: program management? And then that's when he was like, well,
Speaker 2: let's just try it out. Let's just do you know,
Speaker 2: like maybe twenty percent TPM and you're still doing eighty
Speaker 2: percent engineering, And so we tried that out. I kind
Speaker 2: of dipped my toe into things, was enjoying it enough
Speaker 2: that then it went to like thirty seventy and then
Speaker 2: eventually that's when it was like, Okay, you know this,
Speaker 2: this is really something I enjoy and let's just go
Speaker 2: all in.
Speaker 1: I feel like when I joined Limble, it was like
Speaker 1: like instantly I felt the value of your position, like
Speaker 1: how you were setting up ways for us to learn
Speaker 1: and like all these cool sessions and the culture was
Speaker 1: just so solid because of everything you were doing. That's
Speaker 1: really good to hear gright at that. Are there any
Speaker 1: parts of engineering you miss though, and what parts are
Speaker 1: you relieved to have let go of?
Speaker 2: Yeah, you know, a lot of what I miss is
Speaker 2: that collaboration, kind of that team togetherness, you know, like
Speaker 2: I still understand what engineers are doing, and I think
Speaker 2: that's one benefit to having been a software engineer because
Speaker 2: I do have that understanding and i know what it
Speaker 2: feels like. But I'm not in the trenches like I
Speaker 2: used to be, and that part I do miss. There's
Speaker 2: a certain kind of camaraderie that you know, you know
Speaker 2: what I'm talking about, Like it's just sort of cool
Speaker 2: to like go into the war room together or like
Speaker 2: try to solve a bug or something together, and I
Speaker 2: miss that. A lot of what a TPM does is
Speaker 2: more individualistic, which is weird to say because I'm always
Speaker 2: on the call. Like I'm always on calls, I'm always
Speaker 2: talking with people. But at the same time, it like
Speaker 2: I'm sort of like assigning out tasks and then taking
Speaker 2: on tasks myself and looking over it. But it's not
Speaker 2: quite the same as like solving a bug together.
Speaker 1: Oh yeah, so I do miss that, Yeah totally, Like
Speaker 1: if you were coding, I would totally be excited to
Speaker 1: say screen share with you and might coe together and
Speaker 1: that camaraderie would be awesome. But yeah, I could see
Speaker 1: like how there's pros and cons you know, you're probably
Speaker 1: making huge impact, but also like there's it sounds like
Speaker 1: a lot of leadership is in that role. And I've
Speaker 1: like recently fallen into a bit of a leadership position
Speaker 1: Alan Bill as well, and it feels like as soon
Speaker 1: as you're in a leadership position, you know, telling people
Speaker 1: what to do, scheduling meetings, some of the camaraderie disapperies. Yeah,
Speaker 1: they can, speaking of which, like what surprises you most
Speaker 1: about how engineers perceive the TPM role and like how
Speaker 1: do they perceive that role?
Speaker 2: I think it depends on the company, to be honest,
Speaker 2: because it's interesting when you ask someone what is a TPM,
Speaker 2: you get twenty different answers, like from twenty different people,
Speaker 2: And I think there's a misconception of exactly when I
Speaker 2: shouldn't say misconception, I should more appropriately say that every
Speaker 2: company has a particular need for how the going to
Speaker 2: utilize their TPMs, right, and so it's going to look
Speaker 2: different I think for every company. Some I think use
Speaker 2: a TPM more along the lines of what a program
Speaker 2: manager is going to do and not strictly a TPM.
Speaker 2: So I don't know, it's kind of a hard answer
Speaker 2: or a hard question because every company does have a
Speaker 2: different expectation, I think, and so engineers like for me,
Speaker 2: for example, when I did make that transition, a lot
Speaker 2: of what I was doing was like what you just said,
Speaker 2: I was organizing learning initiatives and putting together little min
Speaker 2: like mini conferences of sorts.
Speaker 1: Yeah.
Speaker 2: Unfortunately, what that turned into was that over time, even
Speaker 2: though I was working on security initiatives and you know,
Speaker 2: implementing things like sneak into our code base and like
Speaker 2: really trying to bulke up our security efforts and things
Speaker 2: like that, or I was really involved with getting launched
Speaker 2: darkly implemented into our code base and our process. Like
Speaker 2: I had all these other things going on, but a
Speaker 2: lot of our team members just kind of saw me
Speaker 2: as the fun maker and that was like wait, wait, wait, no,
Speaker 2: I do a lot more than just organize like you know,
Speaker 2: these little events or or you know, I was organizing
Speaker 2: things like team building initiatives and things like that. So yeah,
Speaker 2: I think sometimes it's just hard whatever is more forward
Speaker 2: facing kind of what the team is going to see.
Speaker 2: But if the company is praising you or like sharing,
Speaker 2: you know, the progress and things that you've done, then
Speaker 2: I think the team will recognize. Yeah, so does that
Speaker 2: make sense? So I think it's really like and how
Speaker 2: the company manage managed and leadership is really sharing your work.
Speaker 1: Yeah, yeah, because you're doing a lot of behind the
Speaker 1: scenes things that make important things work out, but people
Speaker 1: wouldn't know. That makes sense. So if you, you know,
Speaker 1: were to tell if you had an engineer and you
Speaker 1: could give them any advice on how they should interact
Speaker 1: with the TPM on their team, what does that look like? Like?
Speaker 1: What should a good engineer do to communicate and work
Speaker 1: with their TPM and vice versa.
Speaker 2: Really, I mean it depends on what the initiative it is, like,
Speaker 2: what the program is that you start working with the
Speaker 2: TPM on. But I think communication is really huge because
Speaker 2: whatever the TPM is doing is trying to fix something
Speaker 2: or it's trying to improve something. So the best thing
Speaker 2: you can do is just be as open as possible
Speaker 2: and like the tp needs to have as much information
Speaker 2: as they possibly can, and that's usually where I would start,
Speaker 2: is asking a million questions so that I can fully
Speaker 2: understand how are things currently going, what's currently happening. And
Speaker 2: then once I've gathered all that information from pretty much
Speaker 2: everybody involved, then I get that full picture. But the
Speaker 2: more that you're open and just really you know, communicative
Speaker 2: with the TPM, like don't hold back, don't be shy,
Speaker 2: they're not going to judge you. They're not going to like,
Speaker 2: you know, look down on you because things aren't going perfectly.
Speaker 2: Nothing's ever going to be perfect, But just be as
Speaker 2: open as you can and answer the questions that they
Speaker 2: ask and know that, like they're just trying to solve
Speaker 2: a problem. So I would just say that, like, you know,
Speaker 2: help them to understand where the problems have been or
Speaker 2: where things need to improve, and then get them that
Speaker 2: information so that they can kind of like spearhead the
Speaker 2: initiative to fix it or improve it.
Speaker 1: Love that. Love that. So what advice would you give
Speaker 1: to like other TPMs, Like maybe something that's like the
Speaker 1: TPMs need to hear sort of a thing.
Speaker 2: Again, I think it kind of depends on the company.
Speaker 2: But I do think sometimes there's a tendency too, and
Speaker 2: I would say this with program managers or even tech
Speaker 2: leads honestly, but sometimes there's this tendency to want to
Speaker 2: schedule more meetings than maybe you should because you do
Speaker 2: need to collect information, you know. I would just say, like,
Speaker 2: be really careful with don't overschedule things. Try to keep
Speaker 2: meetings as brief and concise and to the point, you know,
Speaker 2: as you possibly can, and be respectful to the fact that,
Speaker 2: like software engineers really need to be focusing on their job, right,
Speaker 2: So yeah, I like that would be one thing I
Speaker 2: would say is just be really conscientious of other people's
Speaker 2: time and also the reality of is my suggested implementation
Speaker 2: or my proposal to improve or fix things is it
Speaker 2: really realistic? So just being very aware of like what
Speaker 2: tools and processes is the company already using and can
Speaker 2: I use that instead of throwing out an idea to
Speaker 2: bring in something totally new or different.
Speaker 1: Yeah, So what do you do to earn the trust
Speaker 1: of the team as a TPM?
Speaker 2: Don't be a know at all, Yeah, don't make assumptions,
Speaker 2: have extreme empathy, and listen. Don't talk, but listen. I
Speaker 2: think those are some of the biggest things. Like it's
Speaker 2: natural to go into any kind of situation and have
Speaker 2: all sorts of background experience or things that worked somewhere else,
Speaker 2: but there's no cookie cutter solution to what you're doing.
Speaker 2: So that's great, that's wonderful that you have something that
Speaker 2: worked in a different situation or with a different team,
Speaker 2: but that may not be what's going to be the
Speaker 2: solution for what you're trying to solve right now, Like,
Speaker 2: you really need to just sit down, ask questions, listen
Speaker 2: as much as you possibly can, and get to know
Speaker 2: the people on your team because they are individuals with
Speaker 2: unique personalities and they're going to come with a lot
Speaker 2: of I mean, most of the time you're trying to
Speaker 2: fix a problem, right, so there's going to be probably
Speaker 2: some yeah, I don't know, just situations that you need
Speaker 2: to be very careful not to go in there and
Speaker 2: just make assumptions and like push your way in, right, Yeah,
Speaker 2: so really listen, figure out how things are working, who
Speaker 2: doing what, who's fitting what role. Even if it's not
Speaker 2: an official title, every person on a team has a role,
Speaker 2: and you need to be careful not to like step
Speaker 2: on toes or go in there and just implement all
Speaker 2: this stuff without figuring out how things are currently working.
Speaker 2: But then, like I said, you got to really just
Speaker 2: have that empathetic listening ear and then present a solution
Speaker 2: without being married to it as well, right Like, whatever
Speaker 2: you suggest is probably not going to be one hundred
Speaker 2: percent what is rolled out, so don't be married to it.
Speaker 2: You have to get buy in from everyone and just
Speaker 2: be willing to you know, I think you really have to.
Speaker 2: I believe very firmly in being agile and just being
Speaker 2: okay with iterations and trying something out a little bit
Speaker 2: and then tweaking it and improving it, but working really
Speaker 2: closely with everyone on the team to make sure that
Speaker 2: they're okay with it too.
Speaker 1: Oh so much good stuff there, And honestly, I think
Speaker 1: this is definitely super relevant to like team lead tech
Speaker 1: leads too good everything you said right there, I'm like, oh,
Speaker 1: I need to listen more. Sometimes I come in and like,
Speaker 1: let's get it done. Here's how I've done it, you know,
Speaker 1: my past company. But like listening, man, Like that's the
Speaker 1: I guess, you know, they say, like we have two
Speaker 1: years of mouth, And it's for a reason.
Speaker 2: It's interesting too, because as I've spoken, and like, you know,
Speaker 2: sometimes I'll go in and I'll try things and maybe
Speaker 2: it's not working. Like I've had this happen recently where
Speaker 2: I get frustrated because it's like I've tried all the
Speaker 2: things that you've taught me and I can't figure out
Speaker 2: why this isn't working. So my mentor I was asking her, like,
Speaker 2: what what would you do? And she's like, ask more questions.
Speaker 2: It's like, what do you mean, ask more questions? I
Speaker 2: need to fix things. And she's like, but the more
Speaker 2: questions you ask, you're getting the other person to really
Speaker 2: think about what you want them to think about.
Speaker 1: Oh my gosh.
Speaker 2: People don't change until they want to change and when
Speaker 2: they think it's their idea. So the more that you,
Speaker 2: as a leader ask the right questions and get them
Speaker 2: to see why they want to change and what they're
Speaker 2: trying to accomplish. You know. But questioning you're not telling them,
Speaker 2: you're not commanding them. You're getting them to dig up
Speaker 2: why they want what they're asking for. So it's it's
Speaker 2: a powerful tool. Questioning.
Speaker 1: I love that. So instead of me being like, hey Brooke,
Speaker 1: this is urgent, critical bug I need to go get
Speaker 1: it fixed by Thursday. I'd be like, hey, did you
Speaker 1: hear about that bug? You know? And then we have
Speaker 1: a conversation and like, do you think we should get
Speaker 1: this done quickly? And you have context you're like, yeah,
Speaker 1: you know, that feels far more friendly and maybe gives
Speaker 1: you a chance to actually have buy in instead of
Speaker 1: me telling you what to do and then you being like, Okay,
Speaker 1: you got a boss, you know, right, Yeah, yeah, that's
Speaker 1: something I could do better. That's really it's ask questions
Speaker 1: for sure. So how do you decide when to step
Speaker 1: in versus stay out of the way.
Speaker 2: That's a really good question. I mean think, well, that's
Speaker 2: a hard question. You step in when nothing else is working,
Speaker 2: Like it just becomes clear and see the problem. Like,
Speaker 2: one thing about being a TPM is that you often
Speaker 2: aren't working with just engineers, right, Like, it's kind of
Speaker 2: cross department, so I would step in, Like I'm trying
Speaker 2: to think of a good example, and one I can
Speaker 2: think of is I've recently been added to be the
Speaker 2: TPM over a big project at our company that goes
Speaker 2: across multiple departments. And the reason that we felt like
Speaker 2: there needed to be a TPM over that was because
Speaker 2: you had one department running how you know, like they're
Speaker 2: part of it, and then the engineering department was running
Speaker 2: their portion of it, but they weren't aligning. And so
Speaker 2: you had documentation over here, you had documentation over here.
Speaker 2: They weren't in the same place. There wasn't one source
Speaker 2: of truth, and communication channels were failing. There was no
Speaker 2: cross communication and there was no buy in. And if
Speaker 2: I had asked someone over here in this department what
Speaker 2: the roadmap was and what the goals were, they would
Speaker 2: tell you very different things and what the engineering department
Speaker 2: would tell you. So I stepped in to create that
Speaker 2: alignment and to create healthy communication channels where there was transparency,
Speaker 2: there was a shared source of truth. You know, everybody
Speaker 2: was really aligned. So does that that makes sense? Oh?
Speaker 1: Yeah, that's that makes so much sense And I love that. Yeah,
Speaker 1: So switching gears a little bit here. How do you
Speaker 1: personally stay technically sharp without writing production code every day?
Speaker 2: Is it definitely a personal I should say, habit right
Speaker 2: like you? But it also depends on the project. I
Speaker 2: mean I mentioned there was I noticed the gap probably
Speaker 2: about a year ago where our company isn't a place
Speaker 2: where it's still fairly young. We were at that time
Speaker 2: still very much in the startup phase, and we really
Speaker 2: had only had like one of our original founders who
Speaker 2: was in charge of security. And because we started growing
Speaker 2: and growing and growing, we were focused on developing a
Speaker 2: more bulked up product team and a larger engineering team,
Speaker 2: but security got a little bit left in the dust.
Speaker 2: And so I was looking at some documentation when and
Speaker 2: was kind of horrified to find out we had nothing
Speaker 2: on security. So that's where I was like, we've got
Speaker 2: to change this, and so I took it upon myself
Speaker 2: to start really building out better documentation on our current
Speaker 2: security process, how things were handled, and then implementing new
Speaker 2: things so that we actually had a process and a
Speaker 2: shared understanding of vulnerabilities or you know, all of these things.
Speaker 2: Oh my gosh, Matt, what was the original question?
Speaker 1: Oh just kind of like what you felt like, you
Speaker 1: do this stay technically sharp?
Speaker 2: Oh right, right, Okay. So because of that, like we
Speaker 2: started looking into different tools or platforms that would help
Speaker 2: us to be more secure. And so for that we
Speaker 2: at that time we had Sneak, but we weren't using it,
Speaker 2: and so it was there, it was what was available.
Speaker 2: We were already paying for it. I didn't know it,
Speaker 2: but I had to go make sure that I understood
Speaker 2: it better. And so again it's just asking questions, but
Speaker 2: I had to go do research. I had to read documentation.
Speaker 2: So in that instance, it was me having to learn
Speaker 2: more about the tool that we already had, but you know,
Speaker 2: setting aside the time to do that so that I
Speaker 2: could try to have more intellectual conversations with actually you
Speaker 2: you got brought into that project as well, but others,
Speaker 2: so that you know, I could actually lead the program,
Speaker 2: lead the initiative and not get lost. So sometimes your
Speaker 2: your position just sort of demands it and you have
Speaker 2: to learn whatever the company decides is the tool or
Speaker 2: the platform that we're going to use to fix the problem.
Speaker 2: But also at the same time, like I'm still an
Speaker 2: angular GDE and so it's very important to me to
Speaker 2: attend conferences, go to meetups, you know, be watching things
Speaker 2: that are released on YouTube, and it's just part of
Speaker 2: my daily discipline honestly, is to set aside that learning
Speaker 2: time and be watching LinkedIn or you know, like where
Speaker 2: people are posting, so social media, watching social media and
Speaker 2: if I see someone like Deborah Carota or someone who's
Speaker 2: posting about signals, then Yeah, it is just part of
Speaker 2: being a professional, I think is taking the time to
Speaker 2: study those things and be up on Okay, back hand
Speaker 2: four months ago, it's like what is signals? What is that?
Speaker 2: You know? And I had to learn more about it
Speaker 2: and what it was solving, what it was fixing.
Speaker 1: Yeah, so like part of it naturally comes through the job,
Speaker 1: but also definitely making some dedicated effort to make sure
Speaker 1: you're learning new things and staying on top of it.
Speaker 1: And I've definitely seen you do both a lot of that.
Speaker 1: Speaking of signals as a TPM, what advice do you
Speaker 1: have for angular teams from like a broader lens, Like
Speaker 1: what patterns separate healthy teams from struggling ones? For example, go.
Speaker 2: Back to how much I really believe in being agile.
Speaker 2: I wouldn't have said that back like when I was
Speaker 2: still actually a software engineer. Our team here at Limboll
Speaker 2: was small enough, there were seventeen of us between product
Speaker 2: and engineering, and we didn't really practice agile development. I
Speaker 2: mean it was like we had one big bucket with
Speaker 2: all of the tickets and tasks that needed to be done,
Speaker 2: and we all just kind of went in and picked
Speaker 2: what we wanted and worked on it, but as the
Speaker 2: team grew, it became obvious that we needed to have
Speaker 2: more structure and really have this iterative process. And it
Speaker 2: was kind of painful at first because I'm someone that
Speaker 2: sort of naturally resists what feels tedious, I think, and
Speaker 2: it can filter, you know, oh my gosh, there's more meetings.
Speaker 2: There's yet another meeting on my agenda because now we
Speaker 2: have to do not just stand up, but we have
Speaker 2: backlog grooming, we have planning, we have retro. And it
Speaker 2: was like, dude, I don't need more meetings, you know,
Speaker 2: but after your team gets into the rhythm and the
Speaker 2: flow of those meetings, you actually go, wow, this is
Speaker 2: helping us a lot. So that would be one thing
Speaker 2: I would say is just like, don't resist process, you know,
Speaker 2: be open to trying new things and working in that
Speaker 2: agile way. Yeah, that's a huge thing for me.
Speaker 1: I love that.
Speaker 2: Yeah, I don't know. I mean, there's so many ways,
Speaker 2: and it really depends on the team, but just be
Speaker 2: open and like I said earlier, like really just communicate
Speaker 2: with people. I think that's one of the best things
Speaker 2: you can do across any angular team, but any team
Speaker 2: in general. It's like just communicate. Do learning together though
Speaker 2: as well, you know, don't feel so isolated to have
Speaker 2: to learn things on your own. I think sometimes teams
Speaker 2: forget that the best learning is done when you have
Speaker 2: like maybe in open office hours. We've done that recently.
Speaker 2: But don't make your teams and your team members feel
Speaker 2: like they have to do all the learning after work hours.
Speaker 2: Do it together, learn together, grow together, solve problems together.
Speaker 1: I love that. Yeah, I'm so glad we've had some
Speaker 1: time to learn together instead of just like, oh, figure
Speaker 1: it out, you know, especially with the AI, right because
Speaker 1: if the process is just figure it out, and then
Speaker 1: people default to AI and start to like not learn
Speaker 1: as much and rely more on AI. And we've already
Speaker 1: talked about brain rot and what can happen with that. Yeah,
Speaker 1: but my last question for you is what do you
Speaker 1: do to like live your best dev life while being
Speaker 1: a TPM, especially like with it sounds like sometimes things
Speaker 1: go unrecognized and there's you know, there's a lot of
Speaker 1: caveats and tricky things about the role. So how do
Speaker 1: you live your best dead life and lifestyle while being
Speaker 1: a TPM?
Speaker 2: It can be hard. You kind of brought it up earlier,
Speaker 2: where as a technical program manager, you're often the one
Speaker 2: that's kind of in the shadows a little bit, right,
Speaker 2: Like you're the one who helps other people shine. But
Speaker 2: that doesn't always mean that your work gets recognized because
Speaker 2: you're telling everybody else like, oh, go do this, and
Speaker 2: this is your role, and you go do this. So
Speaker 2: sometimes it can feel like you aren't being recognized, but
Speaker 2: it doesn't mean that. And I have to remind myself
Speaker 2: that you and I have this conversation sometimes where it's like,
Speaker 2: I don't know, just take care of yourself. I think
Speaker 2: is like, you know, like have that self love of
Speaker 2: like knowing that your job is helping other people to
Speaker 2: shine too.
Speaker 1: And I love that.
Speaker 2: That's one of my favorite things about the job is
Speaker 2: helping other people to really grow and accelerate and have
Speaker 2: all this great success. But that is one thing I do,
Speaker 2: is a lot of self care and just making sure
Speaker 2: that I have that self love, if that makes sense.
Speaker 2: So that is one thing I do to have a good,
Speaker 2: my best dead life. But another thing too, and I
Speaker 2: would say this goes across roles and positions, is like
Speaker 2: really finding a good work life balance. I direct a
Speaker 2: meet up, we do the podcast. You and I also
Speaker 2: run the s like the Salt Lake City Google Developer Group.
Speaker 2: We go around the country and we give talks and presentations.
Speaker 2: Like it gets really easy to overwhelm myself doing a
Speaker 2: lot of these other things on top of having my job.
Speaker 2: But one of the best things that I've done lately
Speaker 2: is just remembering that I need to have time for
Speaker 2: me and for my family and my loved ones, the
Speaker 2: ones who are closest to me, because when I'm not
Speaker 2: doing that, then I just burn out. So finding a
Speaker 2: balance and really making sure I stick to just these
Speaker 2: are my work hours, and here are my boundaries. I'm
Speaker 2: available from this time to this time, and you know,
Speaker 2: maybe timebox other things. But outside of those hours, I
Speaker 2: am not on the computer. I'm not doing work. I'm
Speaker 2: doing my personal hobbies and things that bring me joy
Speaker 2: outside of work related stuff. So important. Go outside, go
Speaker 2: on a walk, be in nature. We are way too
Speaker 2: connected to technology, and I think our human brains can
Speaker 2: only handle so much. And with AI, it's just like
Speaker 2: way you know made, it's made the problem even worse.
Speaker 2: And the best advice I can say is just go
Speaker 2: be in nature, be outside, do things where you're connecting
Speaker 2: with humans. Endless mother nature.
Speaker 1: Yeah right, it's like we were talking about the other day,
Speaker 1: like we're probably not gonna honor deathbeds. Say, oh, I
Speaker 1: wish I spent less time with my loved ones out
Speaker 1: in nature. I wish I spent more time coding in
Speaker 1: the dark after hours, right yeah, yeah, Well everybody, this
Speaker 1: is brook Gde you know, does it all in TPM
Speaker 1: like one of seriously the best people I've ever worked with,
Speaker 1: who is amazing at everything she does. And I cannot
Speaker 1: say enough good about Brooks. So thank you so much
Speaker 1: for all you've shared today, Brooke. And this is the
Speaker 1: deav life.
Speaker 2: The attack could the d