Pełna transkrypcja odcinka Using Data to Uncover Hidden Talent on Engineering Teams

that? Is that true? I'm just making an assumption. Yeah, 28 00:02:16.539 --> 00:02:20.939 for sure. I mean I'm a former engineering leader. I have this 29 00:02:21.060 --> 00:02:24.740 wandering career between engineering and product management, but I as an engineering leader, 30 00:02:24.860 --> 00:02:31.530 I used to really rely on things like seeing a team all sitting together and 31 00:02:31.689 --> 00:02:36.770 a person wheeling their chair over to somebody else's desk and they're just like cammering 32 00:02:36.810 --> 00:02:40.090 out something or in a conference room on white boards, lots of pens flaying 33 00:02:40.169 --> 00:02:45.520 and with covid like that's everyone went remote, that's all gone. Yeah, 34 00:02:45.639 --> 00:02:49.840 but the truth is like that was already kind of going away as most of 35 00:02:49.960 --> 00:02:54.439 us became more and more distributed workforces. So even as I reflect on my 36 00:02:54.680 --> 00:02:59.629 own behaviors as a leader, I'm like, AH, how right was that? 37 00:03:00.030 --> 00:03:05.069 When I make judgments on just what I observed in these human behaviors was 38 00:03:05.110 --> 00:03:09.229 that it was kind of excluding the people that were remote or maybe not in 39 00:03:09.310 --> 00:03:14.340 the office that day. But as leaders we have to learn how to reassess 40 00:03:14.819 --> 00:03:21.099 collaboration. That's such a fundamental piece of a good engineering team. Do you 41 00:03:21.259 --> 00:03:23.300 have a bunch of single authors that don't work together, or do you have 42 00:03:23.340 --> 00:03:29.729 a team that really does work together? If Your judgment on collaboration was what 43 00:03:29.930 --> 00:03:32.650 you saw, you're missing a bunch. And one of the things we try 44 00:03:32.729 --> 00:03:39.849 to help team see is how are people collaborating in the code? And the 45 00:03:40.090 --> 00:03:46.199 most common way that people collaborate in the code isn't pull request for viewing each 46 00:03:46.199 --> 00:03:51.080 other's code and part of the insights we try to give to people is what 47 00:03:51.360 --> 00:03:54.240 person interacts with what other people. So you can kind of see the reach 48 00:03:54.710 --> 00:04:01.469 of influence across the team. But then also how good is the Code Review? 49 00:04:02.030 --> 00:04:06.990 Did someone, the person who wrote the code, actually respond to the 50 00:04:08.189 --> 00:04:11.900 comments that I made, to the review that I did and we called out 51 00:04:11.979 --> 00:04:16.220 influence. Those are the traits that ultimately make really strong teams when you see 52 00:04:16.379 --> 00:04:23.379 these engineers collaborate with each other in a way that results in better code being 53 00:04:23.500 --> 00:04:28.370 committed back to the code base. HMM. So I was really curious. 54 00:04:29.250 --> 00:04:32.769 Do you feel like engineer, see this as kind of big brother scenario and 55 00:04:33.449

--> 00:04:39.079 how should leaders talk to their teams about it? And what do you do, 56 00:04:39.480 --> 00:04:43.279 by the way, to educate? Yeah, I mean it is my 57 00:04:43.360 --> 00:04:46.959 daily life what you just highlighted here, because it is really easy to see 58 00:04:47.000 --> 00:04:53.149 something like data insights as big brother. When we started on this journey as 59 00:04:53.189 --> 00:04:59.110 a team, we even some ways underestimated how much we needed to teach data 60 00:04:59.269 --> 00:05:01.310 for good. We have like a couple of hashtags that we talked about all 61 00:05:01.310 --> 00:05:04.670 the time. Hashtag data for good. Like we're not here actually to be 62 00:05:04.910 --> 00:05:08.899 big brother, we're here to help teams be their best or one of the 63 00:05:08.980 --> 00:05:13.420 other shifts. I think in this data for good is engineering. Team members 64 00:05:13.540 --> 00:05:17.579 have a sense of who is good and who is not good. It's all 65 00:05:17.699 --> 00:05:23.290 judgment versus data. You mentioned hidden talent. I think this is one of 66 00:05:23.329 --> 00:05:29.970 the aspects. is a team using data, qualitative data, to see how 67 00:05:30.649 --> 00:05:35.680 they are helping each other, who really is getting better, who is contributing 68 00:05:35.720 --> 00:05:41.240 to others. Data is a really powerful way to get us from that judge 69 00:05:41.839 --> 00:05:47.920 maker, creative self into qualitatively assessing how we're before performing as a team and 70 00:05:48.040 --> 00:05:51.949 when at those our continuity. I wanted to pick up on a thread, 71 00:05:53.310 --> 00:05:58.310 which is that looking at this kind of data can make a difference for team 72 00:05:58.589 --> 00:06:04.540 members from underrepresented groups, and I know you have an interesting customer story around 73 00:06:04.620 --> 00:06:10.180 that. Yeah, the customer is Manualife, a fluorosite customer, and they 74 00:06:10.259 --> 00:06:14.980 use all of our products, but with flow in particular. They actually I 75 00:06:15.060 --> 00:06:17.500 don't know if they intended this initially or if it just happened, but as 76 00:06:17.540 --> 00:06:23.250 they started to look at performance of the teams, they found a woman on 77 00:06:23.370 --> 00:06:30.329 the team that had been at this associate level for multiple years and she was 78 00:06:30.529 --> 00:06:33.360 not allowed person and she was not a self promoter and she was not the 79 00:06:33.439 --> 00:06:40.199 one volunteering to do the demos and the presentations, and yet the flow data 80 00:06:40.279 --> 00:06:46.389 showed that she was an incredible contributor to the team, very effective, proficient 81 00:06:46.470 --> 00:06:54.310 at her craft, and they used flow to find that and fix the fact 82 00:06:54.310 --> 00:06:58.589 that she had not been promoted. The other thing that I find remarkable is 83 00:06:58.709 --> 00:07:03.939 that they have been very public about this. Well, VP of engineering. 84 00:07:04.579 --> 00:07:10.980 He talks openly about this story, encouraging other leaders to go and do the 85 00:07:11.060 --> 00:07:15.220 same thing, a sort of this acknowledgement that we've all made mistakes in a 86 00:07:15.379 --> 00:07:20.370 recognizing the self promoters and ignoring those that are not loud, and he's asking 87 00:07:20.490 --> 00:07:24.529 the rest of the world to come with him in this journey and using data 88 00:07:24.930 --> 00:07:30.680 to find people who might be overlooked. Yeah, so let's talk about this 89 00:07:30.879 --> 00:07:34.879 idea of the influencers not necessarily being the loudest person in the room. I 90 00:07:35.000 --> 00:07:39.759 think you have some elaboration on that. Yeah, I'm going to take another 91 00:07:39.800 --> 00:07:42.920 example. This was like a little bit of a like nearder to my heart. 92 00:07:42.920 --> 00:07:48.790 So you think about neually diverse people and there's social interactions are not maybe 93 00:07:48.870 --> 00:07:56.829 like everyone else, and yet for finding that neually diverse people are very talented 94 00:07:57.589 --> 00:08:01.579 in the craft of software engineering. When I use data, I can see 95 00:08:03.339 --> 00:08:09.339 that people who maybe don't have a voice or whose voice is awkward are highly 96 00:08:09.379 --> 00:08:13.569 proficient in coding itself. Like I can actually see how they collaborate with others, 97 00:08:13.689 --> 00:08:20.569 like when they review other people's code, are they contributing really good comments 98 00:08:20.769 --> 00:08:24.089 that cause the other members of the team to make code changes? I can 99 00:08:24.089 --> 00:08:28.879 also see how much time do they spend on new work, on their own 100 00:08:28.920 --> 00:08:33.639 work, versus interacting with others? And that interacting with others? I'll probably 101 00:08:33.720 --> 00:08:39.240 never see it in the form of a conversation, but I can see it 102 00:08:39.360 --> 00:08:43.269 in code and I can see how that matters in the quality of code that 103 00:08:43.389 --> 00:08:46.389 our team is producing. Yeah, and actually, maybe something I should have 104 00:08:46.509 --> 00:08:52.110 mentioned earlier is this type of data. The code commits, the pull request, 105 00:08:52.190 --> 00:08:56.860 the ticket data is available for absolutely every engineering leader. So it's not 106 00:08:58.340 --> 00:09:03.179 just about having flow, but it's about being deliberate about how you're measuring performance 107 00:09:03.259 --> 00:09:07.019 and influence. Yes, totally in fact. Thanks for bringing that up. 108 00:09:07.019 --> 00:09:09.730 I mean this is data that we're getting right out of the code repository that 109 00:09:11.129 --> 00:09:16.250 ninety percent of companies are using, and so it's there. But often leaders 110 00:09:16.289 --> 00:09:20.169 don't take the time to go

and look at it or it's awkward to get 111 00:09:20.210 --> 00:09:24.639 that data. But this data is available when people can be doing this starting 112 00:09:24.679 --> 00:09:28.639 today, even if they don't have flow. So there's something else that keeps 113 00:09:28.679 --> 00:09:33.799 leaders up at night, which is on boarding, and I know you've looked 114 00:09:33.799 --> 00:09:37.320 at that quite a bit. So help leaders out in terms of what matters 115 00:09:37.399 --> 00:09:39.269 with regard to on boarding and what they can do. First of all, 116 00:09:39.309 --> 00:09:45.309 maybe a little background. Linkedin did some studies on just the turnover in software 117 00:09:45.350 --> 00:09:50.909 engineering and basically this stat has made remain the same for the last several years. 118 00:09:50.990 --> 00:09:56.019 But twenty percent, roughly, of the workforce is turning over all the 119 00:09:56.139 --> 00:09:58.980 time. So, as we have a team of ten, that that means 120 00:10:00.299 --> 00:10:05.220 two of your people are new at any given time. So hiring is one 121 00:10:05.259 --> 00:10:09.730 challenge, but even once you do that, then getting that person to be 122 00:10:09.970 --> 00:10:15.889 a productive member of the team is that onboarding challenge that you're raising here, 123 00:10:16.129 --> 00:10:18.809 and that's with that twenty percent turn and then some companies of shirts hire. 124 00:10:20.330 --> 00:10:24.120 You're basically doing this all the time. But this is another really fun area 125 00:10:24.159 --> 00:10:26.480 for me where it's like the data showed me that what I was doing the 126 00:10:26.519 --> 00:10:31.080 past was wrong. The natural instinct of a leader, specially an engineering leader, 127 00:10:31.240 --> 00:10:35.000 is when you hire New People, is to give that new person lots 128 00:10:35.000 --> 00:10:37.629 of low risk work. They're like, well, we can't have this person, 129 00:10:37.870 --> 00:10:43.190 brand new, doesn't know anything, putting code and production. That would 130 00:10:43.190 --> 00:10:48.230 be scary. So your instinct is to have these new team members do a 131 00:10:48.269 --> 00:10:52.899 lot of ride along, as they're like watching other people work. Maybe you'd 132 00:10:52.940 --> 00:10:58.059 give them some bug fixes and, as we partners of our customers, to 133 00:10:58.100 --> 00:11:01.580 do some studies. The data showed that in some ways you should just be 134 00:11:01.620 --> 00:11:03.730 doing the opposite. You when you bring this new person onto your team, 135 00:11:05.129 --> 00:11:09.490 you should get this person reviewing lots of other people's code and having a lot 136 00:11:09.490 --> 00:11:13.809 of other people review their code. That other insight is to give them new 137 00:11:15.210 --> 00:11:20.440 work and again rely on that code collaboration as the helping hands around this person 138 00:11:20.480 --> 00:11:26.440 and get that new

work in production as fast as possible. We call them 139 00:11:26.480 --> 00:11:30.919 atchark time to one hundred, which really speaks to how quickly can we get 140 00:11:30.960 --> 00:11:37.590 a person produce using hundred lines of highly efficient and production code and then more? 141 00:11:37.710 --> 00:11:39.990 That you mean into that in some ways was like leaning into your discomfort. 142 00:11:41.230 --> 00:11:45.429 The faster they will on board and be a productive member of the team. 143 00:11:46.269 --> 00:11:50.059 And in the studies we've done we see the difference being in the range 144 00:11:50.100 --> 00:11:56.740 of four months for on boarding to eleven months. And specifically you're talking about 145 00:11:56.779 --> 00:12:01.100 the difference between high and low performing teams. So yellow performing is three to 146 00:12:01.220 --> 00:12:05.210 four months on board versus eleven months to on board. Yeah, so, 147 00:12:05.409 --> 00:12:09.730 yeah, those high performing teams are doing it faster, they're doing in four 148 00:12:09.809 --> 00:12:13.610 months. And there's like another benefit to all this, which is happier teams. 149 00:12:13.929 --> 00:12:16.399 When you join a team like, I don't know if you've ever been 150 00:12:16.440 --> 00:12:18.120 a new member of a company or a new member of a team, like 151 00:12:18.200 --> 00:12:22.000 all you want to do is prove yourself, all you want to do is 152 00:12:22.120 --> 00:12:26.919 be that contributor, and the faster that we can enable you to do that, 153 00:12:26.600 --> 00:12:30.830 the more you're going to be a really happy member of the team, 154 00:12:31.149 --> 00:12:33.990 and that sort of lifts all boats in any ways. But you know, 155 00:12:35.070 --> 00:12:39.309 you've heard there's like this adage of people join companies and then leave the leaders, 156 00:12:39.389 --> 00:12:41.429 writer. E. Leaf bosses. So if that's problem number one, 157 00:12:41.710 --> 00:12:48.340 you see, well, how can you be a good leader and create an 158 00:12:48.379 --> 00:12:52.740 environment where people want to be part of the team? Like it's first valuing 159 00:12:52.019 --> 00:12:58.610 each member for their actual contributions. How many times I've heard team member or 160 00:12:58.690 --> 00:13:03.690 say, well, my manager doesn't know what I'm actually contributing. So first 161 00:13:03.690 --> 00:13:07.490 of all, let's have data for all, like everybody, seeing what I'm 162 00:13:07.490 --> 00:13:13.279 actually contributing and getting promoted for what I am doing, being given opportunities based 163 00:13:13.360 --> 00:13:18.559 on my skill and my craft and how I help the team. All of 164 00:13:18.639 --> 00:13:24.600 these are things that leaders should use when they're looking at the health of the 165 00:13:24.759 --> 00:13:28.269 team. I think on the other side, two engineers are creative makers, 166 00:13:28.909 --> 00:13:37.870 so being able to be more confident in seeing my actual proficiency, that leads 167 00:13:37.870 --> 00:13:41.779 to my happiness. I've also lost engineers over the years because they said, 168 00:13:41.779 --> 00:13:46.019 well, I just wanted to do something new. I was tired of coding 169 00:13:46.059 --> 00:13:48.620 in Java and I wanted to move to Javascript, or want to become a 170 00:13:48.820 --> 00:13:52.659 front and developer, or like, we weren't on the cloud yet and I 171 00:13:52.740 --> 00:13:56.210 really wanted to be doing cloud devops oriented engineering. Well, first of all, 172 00:13:56.330 --> 00:14:00.809 my creating those opportunities in my own environment, but then, as I 173 00:14:01.049 --> 00:14:05.129 do it, am I creating a success path for that person so that they 174 00:14:05.210 --> 00:14:11.039 are taking those opportunities, that are learning the skill and they can see the 175 00:14:11.080 --> 00:14:13.879 data just like I can on how they're doing, and they're getting better and 176 00:14:15.000 --> 00:14:20.480 better. Yeah, and we know there's slewth low of research. That underscores 177 00:14:20.559 --> 00:14:24.830 the fact that engineers in particular, I think, more than any other discipline, 178 00:14:26.230 --> 00:14:33.789 really need to learn and continue to grow, partly because of the thirst 179 00:14:33.870 --> 00:14:37.950 for knowledge that they generally tend to have broad brushstrokes, but also because, 180 00:14:37.470 --> 00:14:41.980 you know, when I talk to engineers, there's a bit more anxiety than 181 00:14:41.019 --> 00:14:46.940 you might imagine, because they're thinking, are my skills still relevant? Am 182 00:14:46.019 --> 00:14:50.940 I at the leading edge? Yeah, I mean that's actually such a stressful 183 00:14:50.019 --> 00:14:56.690 part at their fears are not unfounded, because companies do like a company will 184 00:14:56.730 --> 00:15:00.370 make a strategic decision. Okay, we're going to now do digital transformation. 185 00:15:00.450 --> 00:15:03.690 Are In person experience that we used to have with our customers. It's now 186 00:15:03.769 --> 00:15:07.840 going to be all digital, it's gonna be online, and so they do 187 00:15:07.080 --> 00:15:13.480 feel that pressure to always be on the leading edge of skill, but there's 188 00:15:13.559 --> 00:15:18.679 often not this companion piece of data that shows them give them comfort, like 189 00:15:18.080 --> 00:15:20.870 I'm there, look at me, I'm doing this. Fact, one of 190 00:15:20.909 --> 00:15:24.309 the stories I want to share with you is like a woman on our team's 191 00:15:24.429 --> 00:15:28.750 at floral site she left engineering for ten years to be a stayathome mom and 192 00:15:28.830 --> 00:15:33.029 then when she came back, first of all, ten years is a lifetime 193 00:15:33.269 --> 00:15:37.899 and software engineering, so she's of course learning new skills. But she had 194 00:15:37.980 -->

00:15:41.299 told herself, I'm not good at this, I've been out for ten years, 195 00:15:41.379 --> 00:15:46.740 I'm just like so grateful to even have got this job. And her 196 00:15:48.259 --> 00:15:56.889 leader was using data really effectively and she saw herself credit pretty quickly that actually, 197 00:15:56.970 --> 00:16:00.289 she's really good. The ten years off didn't really hurt her. She's 198 00:16:00.649 --> 00:16:06.679 extremely talented, extremely technical and was quickly catching up to her peers. One 199 00:16:06.720 --> 00:16:08.759 of the reasons I love the stories. It ties a lot of threads together. 200 00:16:10.080 --> 00:16:14.240 That so maybe quieter voice, that underrepresented voice, that people that took 201 00:16:14.240 --> 00:16:19.350 a bunch time off meeting to reskill. But data kind of set her free 202 00:16:19.669 --> 00:16:23.710 from that dialog in her head that would say all, you've been away ten 203 00:16:23.750 --> 00:16:29.110 years, you're just the junior member of the team, you can't do this. 204 00:16:29.629 --> 00:16:33.379 We all kind of have those voices sometimes and like I love seeing how 205 00:16:33.620 --> 00:16:38.580 the truth set her free in this games hmm. Yeah, and honestly, 206 00:16:40.299 --> 00:16:45.740 women and really anyone who could be seen as other on an engineering team are 207 00:16:45.299 --> 00:16:52.929 prone to telling these stories about themselves and generally, I think leaders should be 208 00:16:52.169 --> 00:16:59.210 aware of that, because people who are underrepresented on engineering teams may need a 209 00:16:59.289 --> 00:17:04.640 leader to pay more attention to the kinds of performance data you're talking about to 210 00:17:04.759 --> 00:17:10.440 ensure that there is more equity. So yeah, data was that you free 211 00:17:10.480 --> 00:17:15.079 should be your next Hashtag. Yeah Right, okay, so obviously data is 212 00:17:15.240 --> 00:17:18.150 the focus here big time. If we played a a drinking game where every 213 00:17:18.230 --> 00:17:22.309 time we mentioned your right, think we'd both be pretty tipsy. But I 214 00:17:22.430 --> 00:17:26.950 think it's not just in the code either, because you've talked about some things 215 00:17:26.029 --> 00:17:30.059 that team leads can do to, without looking at the code, expand the 216 00:17:30.140 --> 00:17:36.740 skills that they reward. So certainly I think reward people that are willing to 217 00:17:37.019 --> 00:17:41.299 learn new skills. Some ways today wid an engineering teams and general feels like, 218 00:17:41.380 --> 00:17:45.329 Oh, if I want to learn a new skill, I have to 219 00:17:45.369 --> 00:17:49.049 go to them my own time. So we need to recognize as engineering leaders 220 00:17:49.490 --> 00:17:56.490 every reason have to learn new skills at some point. So rembrace that reward 221 00:17:56.650 --> 00:18:02.440 that. Recognize it the other instead of just who's doing a maximum number of 222 00:18:02.480 --> 00:18:07.200 tickets every week or who's the hero that responds to production incidents in the middle 223 00:18:07.200 --> 00:18:12.789 of the night to look for some of those other softer either collaboration skills or 224 00:18:14.069 --> 00:18:18.950 the person who quietly goes behind and does clean up and rights documentation. Look 225 00:18:18.029 --> 00:18:22.509 for the things that lift the team. That's and I feel like that applies 226 00:18:22.589 --> 00:18:26.420 to whether it's engineering teams, all teams, but it certainly an engineering go 227 00:18:26.579 --> 00:18:33.420 beyond looking at hero behaviors and look for the quieter, behind the scenes things. 228 00:18:33.819 --> 00:18:36.900 I love that. So that's going to be things like, are they 229 00:18:36.980 --> 00:18:41.809 mentoring others? Do they help on board the new person? Yeah, are 230 00:18:41.849 --> 00:18:45.609 they working cross functionally? Then I think, as you mentioned, it's about 231 00:18:45.609 --> 00:18:52.250 bringing new skills to the team. So how about we move into a segment 232 00:18:52.730 --> 00:18:56.759 that technically people calls the two minute take away. So if you had to 233 00:18:56.839 --> 00:19:02.640 choose a few key pieces of advice that you can give leaders, what would 234 00:19:02.640 --> 00:19:07.480 that be? Yeah, well, first I think it's to create a culture 235 00:19:08.079 --> 00:19:17.309 of trust really intentionally and do this by expanding the definition of contributors. It's 236 00:19:17.430 --> 00:19:21.470 too easy to look at the person who stayed up all night working on my 237 00:19:21.589 --> 00:19:26.579 production isn't or the person who's really loud about all the new things they're doing, 238 00:19:26.099 --> 00:19:33.019 and we often ignore the more silent but meaningful contributors, people are helping 239 00:19:33.140 --> 00:19:38.650 others, people are who are learning new skills, people who are working cross 240 00:19:38.730 --> 00:19:44.930 functionally. So expand that definition of contributors and that will have that effective trust 241 00:19:45.569 --> 00:19:49.210 and the span that the definition of influencers, people who are realizaking a difference. 242 00:19:49.210 --> 00:19:53.440 Yeah, yes, yeah, so that's number one. Number two is 243 00:19:55.359 --> 00:19:59.960 hiring on boarding. Stop Thinking about it as a chore and like this New 244 00:20:00.079 --> 00:20:03.559 Person, got to get them up to speed, lean into our discomfort by 245 00:20:03.680 --> 00:20:08.190 giving them new work, helping them become meaningful contributors faster, faster. Yeah, 246 00:20:08.349 --> 00:20:12.150 and obviously that is so related to your first point, which was about 247 00:20:12.150 --> 00:20:15.150 trust it. So, yeah, exactly. And there's maybe a to a, 248 00:20:15.869 --> 00:20:19.950 which is when you have new team member, there's a data person to 249

00:20:21.190 --> 00:20:25.460 A. I love it right doing like when there's a new person on your 250 00:20:25.500 --> 00:20:29.339 team. They might not be new to the company, but part of being 251 00:20:29.500 --> 00:20:32.980 happy as an engineer as being able to do new things. So when a 252 00:20:33.140 --> 00:20:37.049 new person joins the team from another team, on board them in the same 253 00:20:37.130 --> 00:20:41.450 way. Give them new work, let them do meaningful contributions to the team 254 00:20:41.490 --> 00:20:45.730 into production as fast as possible. And up to the final point. I 255 00:20:45.930 --> 00:20:55.359 think is really just seeking hidden talent, look for underrepresented team members, look 256 00:20:55.640 --> 00:20:59.200 where they often might feel like an other. They might not be lowed, 257 00:20:59.359 --> 00:21:04.109 they're not self promoters. So go and look for them and give them the 258 00:21:04.190 --> 00:21:11.869 opportunities, the recognition promote them. That matters so much as companies take on 259 00:21:11.990 --> 00:21:19.420 these big DII initiatives. Amazing, valuable takeaways that leaders can implement two days. 260 00:21:19.740 --> 00:21:25.140 So thank you so much, Catherine. Our listeners are going to want 261 00:21:25.140 --> 00:21:30.339 to talk with you to learn more about expanding their definition of what good performances. 262 00:21:30.700 --> 00:21:33.490 What's a good way to reach you? Yeah, please reach out to 263 00:21:33.490 --> 00:21:37.529 me on Linkedin. That's probably the best way and the easiest way, and 264 00:21:37.690 --> 00:21:42.609 please reference this so that I know that it's related to this built in podcast. 265 00:21:42.849 --> 00:21:45.849 But I really look forward to collaborating with people. As you can tell, 266 00:21:45.930 --> 00:21:52.640 I really am passionate about this and I love learning from others and hearing 267 00:21:52.680 --> 00:21:56.640 new ideas and what people are experiencing. Yeah, I love it and it's 268 00:21:56.720 --> 00:22:02.190 been fun to collaborate on this conversation. So thanks for that. For listeners, 269 00:22:02.230 --> 00:22:06.549 thanks for joining us as well. Don't forget to subscribe to the show 270 00:22:06.950 --> 00:22:12.670 by visiting technically peoplecom and I'd also say just like Catherine, we really love 271 00:22:12.750 --> 00:22:15.299 to hear from you as well, so I feel free to reach out at 272 00:22:15.900 --> 00:22:21.819 our email, which is technically people at built Incom and then, of course, 273 00:22:21.980 --> 00:22:25.500 follow us on Linkedin. So we'll talk to you next week and bring 274 00:22:25.539 --> 00:22:30.450 you another conversation from an expert on the vanguard of the future of work. 275 00:22:30.490 --> 00:22:36.250 Whether you're looking to fill opportunities or find them, built in hows you covered. 276 00:22:36.650 --> 00:22:41.410 If you're seeking to meet aggressive hiring goals, will help you attract sought 277 00:22:41.529 --> 00:22:45.920 after tech talent you might not otherwise reach. And if you're on the market 278 00:22:45.039 --> 00:22:49.640 for a career change, visit our site to explore exciting jobs with our customers 279 00:22:49.920 --> 00:22:56.920 and even with built in. Find Talent, find opportunities built incom