WEBVTT 1 00:00:02.160 --> 00:00:06.280 And we're live for anyone who doesn't know. We also 2 00:00:07.639 --> 00:00:13.439 live stream this on LinkedIn, YouTube and twitch. At what 3 00:00:13.519 --> 00:00:17.320 time is it? It's uh what ten thirty Eastern time 4 00:00:17.399 --> 00:00:25.039 on Tuesday morning? It's two thirty pm UTC. If you're 5 00:00:25.079 --> 00:00:26.440 not in one of those time zones, you're gonna have 6 00:00:26.440 --> 00:00:28.280 to do the math yourself. But I love you for 7 00:00:28.320 --> 00:00:31.359 listening and watching the live stream. Meanwhile, what's up born? 8 00:00:32.200 --> 00:00:36.320 Hey, thanks for turning that up. And I always get 9 00:00:36.320 --> 00:00:40.159 the time zones, you know, totally wrong living in Switzerland 10 00:00:40.240 --> 00:00:44.039 where at plus two UTC at Yeah, I mean some 11 00:00:44.079 --> 00:00:47.840 of those special ones in North America are quite challenging. 12 00:00:48.920 --> 00:00:56.640 Yeah yeah. On my team currently, I'm in GMT minus six. 13 00:00:57.520 --> 00:01:02.280 I have a person in GMT mine three, one in 14 00:01:02.560 --> 00:01:05.159 GMT plus one, and one in GMT plus two. 15 00:01:05.439 --> 00:01:10.599 So you know, I only is thickering here because we 16 00:01:10.840 --> 00:01:14.120 built a product a stand up bought called the stand 17 00:01:14.159 --> 00:01:16.799 Up and Prosper and it was part of an old 18 00:01:16.840 --> 00:01:19.719 product that we had built a long time ago, and 19 00:01:20.560 --> 00:01:24.680 very quickly we realized, you know, we may actually be 20 00:01:24.680 --> 00:01:27.719 one of those companies that now has to understand really 21 00:01:28.120 --> 00:01:31.959 lots of intricacies about how time zones work. Because like 22 00:01:32.120 --> 00:01:36.040 we have to send we'd send messages to people when 23 00:01:36.079 --> 00:01:38.680 it's eight pm or eight am in their time zone, 24 00:01:39.519 --> 00:01:42.359 and we try to rely on like the Slack time 25 00:01:42.439 --> 00:01:44.280 zone for that and it's not always valuable. And then 26 00:01:44.280 --> 00:01:46.159 we also have to display it an RUIS and also 27 00:01:46.200 --> 00:01:50.959 get it right on Slack display and trying to schedule 28 00:01:51.239 --> 00:01:55.120 in a different time zone is always such a challenge there. 29 00:01:55.439 --> 00:01:57.799 Yeah, I worked at a startup. 30 00:01:57.840 --> 00:01:58.239 One time. 31 00:01:58.280 --> 00:02:04.319 We did medical imaging for trauma hospitals on their trauma 32 00:02:04.400 --> 00:02:09.360 patients and they decided to rewrite the core application in Java. 33 00:02:09.599 --> 00:02:11.120 We're not going to go down that path, but that's 34 00:02:11.159 --> 00:02:16.039 what they did. Right the very next time that daylight 35 00:02:16.080 --> 00:02:23.159 savings time went into effect for the US, we had 36 00:02:23.199 --> 00:02:27.400 about two thousand trauma patients disappear from our system because 37 00:02:27.439 --> 00:02:31.000 they didn't account for daylight savings time. So that was 38 00:02:31.000 --> 00:02:31.560 a good time. 39 00:02:31.960 --> 00:02:34.039 Yeah, I mean, there are definitely some things where we 40 00:02:34.120 --> 00:02:36.039 allow events in the future and then we try to 41 00:02:36.120 --> 00:02:39.840 hide them being displayed, just because prepopulation of data is 42 00:02:39.879 --> 00:02:43.039 so important for production scale applications because you don't want 43 00:02:43.039 --> 00:02:46.719 to wait until you know something actually happens before having 44 00:02:46.759 --> 00:02:49.039 those events in your database. So I can totally imagine 45 00:02:49.439 --> 00:02:52.400 that they're omitted in the future, so don't display them 46 00:02:52.599 --> 00:02:55.960 in any of the UIs to users because that would 47 00:02:55.960 --> 00:02:56.560 be confusing. 48 00:02:57.199 --> 00:03:04.039 Right. But speaking time, it's that time of year that 49 00:03:05.000 --> 00:03:09.560 we're coming up on the end of year, the holiday season, 50 00:03:10.400 --> 00:03:13.599 which can have a lot of it can mean a 51 00:03:13.599 --> 00:03:17.280 lot of things depending on what industry you're in, how 52 00:03:17.319 --> 00:03:21.960 your company handles closing the books at your end, and 53 00:03:23.639 --> 00:03:25.879 so that's what this episode is all about, is just 54 00:03:26.400 --> 00:03:29.159 kind of I think it's kind of just us talking 55 00:03:29.199 --> 00:03:33.400 out loud as reminder to ourselves as well as a 56 00:03:33.439 --> 00:03:36.360 reminder to the listeners of our show that those things 57 00:03:36.360 --> 00:03:39.360 are coming and to start thinking about them, because we're 58 00:03:39.400 --> 00:03:43.879 going to be executing those tasks here before you know it. 59 00:03:45.439 --> 00:03:47.800 You say that, and the first thing that comes to 60 00:03:47.879 --> 00:03:52.960 mind is when it hits to be cyber Monday, I guess, 61 00:03:53.080 --> 00:03:56.439 or you know, three weeks ahead of that, because realistically, 62 00:03:56.919 --> 00:04:00.639 that's when every year it just gets soon and sooner. 63 00:04:00.719 --> 00:04:04.599 And I remember working at so many companies where someone 64 00:04:04.719 --> 00:04:06.919 was telling me, you know, something's going to be different now, 65 00:04:07.639 --> 00:04:09.360 But as an engineer, I'm just like, I don't. I 66 00:04:09.360 --> 00:04:11.280 don't know what that means. I don't I don't know 67 00:04:11.280 --> 00:04:14.879 how to what do want to do that information right? 68 00:04:17.000 --> 00:04:22.439 For me, the hardest part has always been getting that 69 00:04:22.560 --> 00:04:27.800 information out of marketing because they spend a lot of 70 00:04:27.839 --> 00:04:33.000 time and effort doing campaigns, marketing campaigns where this's ads, 71 00:04:33.040 --> 00:04:37.959 email blasts or whatever to build up these big sales events, 72 00:04:38.199 --> 00:04:42.560 And in doing this for three decades, I have never 73 00:04:42.639 --> 00:04:48.439 been successful in convincing someone from marketing that, hey, if 74 00:04:48.439 --> 00:04:51.920 you're gonna funnel an extra two million people to the site, 75 00:04:52.000 --> 00:04:54.800 did you ever think about giving someone an engineering like 76 00:04:54.839 --> 00:04:55.519 a heads up? 77 00:04:57.279 --> 00:04:59.480 Yeah? I mean that's always the most ridiculous thing. I 78 00:04:59.480 --> 00:05:05.560 think it leads the conversation sometimes in an disappointing direction, though, 79 00:05:05.600 --> 00:05:07.800 because it goes from like, Okay, well we're going to 80 00:05:07.800 --> 00:05:10.639 sign out two million emails, but how many? How many 81 00:05:10.639 --> 00:05:12.319 of those are going to be opened? And then you 82 00:05:12.399 --> 00:05:16.079 realize by many marketing departments, the answer is we have 83 00:05:16.199 --> 00:05:21.680 no idea, and it's like, is that two million users 84 00:05:21.720 --> 00:05:24.000 coming to our site? Or is it two hundred thousand, 85 00:05:24.120 --> 00:05:26.959 is it twenty thousand? And so a lot of times 86 00:05:27.000 --> 00:05:29.519 that stuff happens and there's zero impact to the business, 87 00:05:30.079 --> 00:05:32.319 And the most effective thing you can do is, you know, 88 00:05:32.399 --> 00:05:34.800 just stop performing those experiments in that way unless you 89 00:05:34.839 --> 00:05:37.519 actually know what the click through rate is, what the 90 00:05:37.560 --> 00:05:40.959 conversions are going to be. And that's interesting you say 91 00:05:41.000 --> 00:05:44.639 that because when we build authors a while back, one 92 00:05:44.680 --> 00:05:49.920 of the most common concerns we heard from our customers 93 00:05:49.920 --> 00:05:51.959 that we're using our competitors is how they charge by 94 00:05:52.040 --> 00:05:54.920 monthly active users. And that means if you sign in, 95 00:05:55.000 --> 00:05:58.199 you get immediately dinged for a user count that then 96 00:05:58.399 --> 00:06:01.079 is amateurized through the whole month, which means you're basically 97 00:06:01.079 --> 00:06:04.079 paying for thirty days worth of your advertisement, which is 98 00:06:04.079 --> 00:06:06.560 a huge cost, especially when these marketing campaigns go out. 99 00:06:06.720 --> 00:06:11.199 But yeah, I mean yeah, engineering very rarely knows what 100 00:06:11.319 --> 00:06:14.120 to do there, and so we went to a pure 101 00:06:14.680 --> 00:06:18.279 charge by usage, so you know, if they only log 102 00:06:18.279 --> 00:06:20.720 in once, there's not a problem. But I still think 103 00:06:20.759 --> 00:06:24.120 most of those marketing organizations they have no idea how 104 00:06:24.120 --> 00:06:26.720 many users are going to actually come to your site. Yeah. 105 00:06:26.720 --> 00:06:28.319 I think the big takeaway from that is that I 106 00:06:28.399 --> 00:06:31.480 chose the wrong career profession. I chose one where my 107 00:06:31.680 --> 00:06:34.759 performance can be measured. That's my fault. 108 00:06:35.519 --> 00:06:37.959 Oh you say that, and now I really wonder how 109 00:06:38.040 --> 00:06:41.279 are you? How are you being measured? Because performance measurement 110 00:06:41.360 --> 00:06:44.759 in selfware engineering, I think, like anything is, it's much 111 00:06:44.800 --> 00:06:49.560 more difficult than widget production, which is, you know, highly 112 00:06:49.639 --> 00:06:52.639 repetitive in which you can actually measure the throughput and 113 00:06:54.319 --> 00:06:57.560 you know, quality metrics of the individual machine that's that's 114 00:06:57.920 --> 00:07:00.600 manufacturing those widgets, whether it's human or automated. 115 00:07:01.439 --> 00:07:08.360 Yeah, from my perspective, since I'm mostly infrastructure based, a 116 00:07:08.360 --> 00:07:14.319 good bit of my performance evaluation is based on uptime 117 00:07:14.600 --> 00:07:19.800 and ease of deployment and error rate and things like that. 118 00:07:21.560 --> 00:07:24.600 But I would I don't have any data to back 119 00:07:24.639 --> 00:07:28.120 this up, but I would say that a bigger part 120 00:07:28.319 --> 00:07:34.759 of my performance evaluation comes from perception of the teams 121 00:07:34.800 --> 00:07:39.759 that I support. Do they feel like they're being Do 122 00:07:39.800 --> 00:07:42.319 they feel like they're getting the level of support that 123 00:07:42.399 --> 00:07:45.199 they need? And that just comes down to customer service. 124 00:07:46.040 --> 00:07:52.839 Recently had a situation on that exact same topic where 125 00:07:52.879 --> 00:07:58.279 someone felt like they were not getting the level of 126 00:07:58.319 --> 00:08:01.560 support that they needed, And the only thing I changed 127 00:08:01.759 --> 00:08:05.759 was at the end of every meeting asking them, Hey, 128 00:08:05.839 --> 00:08:12.000 is there anything that you are blocked on because you're 129 00:08:12.040 --> 00:08:16.079 waiting on us to do something, and just doing that, 130 00:08:16.279 --> 00:08:20.360 just calling it out to attention, you know, was enough 131 00:08:20.399 --> 00:08:23.399 to change the perception of the performance. 132 00:08:24.040 --> 00:08:25.360 Yeah, I mean, I think that was one of the 133 00:08:25.360 --> 00:08:29.160 biggest learnings I had from when I started professionally, is 134 00:08:29.279 --> 00:08:35.320 I thought that my deliverables as I coded them, as 135 00:08:35.320 --> 00:08:39.679 I architected them, was worth something. But I knew that 136 00:08:39.720 --> 00:08:43.000 there was this thing of No, you're judged by politics 137 00:08:43.200 --> 00:08:45.679 is the word I would use to describe it, which 138 00:08:45.720 --> 00:08:49.919 I really think is a misnomer honestly, because you aren't 139 00:08:50.360 --> 00:08:55.200 fairly or equality judged on what your outputs. You know, 140 00:08:55.240 --> 00:08:58.600 it is really about the perception. And talking with whoever 141 00:08:58.720 --> 00:09:02.320 is in charge of promoting you is really the first 142 00:09:02.360 --> 00:09:05.279 important step that everyone really needs to take on day 143 00:09:05.320 --> 00:09:08.080 one when they get a job. How am I actually 144 00:09:08.080 --> 00:09:11.919 going to be evaluated and over time whether the things 145 00:09:11.960 --> 00:09:14.840 you're working on are actually relevant to being promoted or 146 00:09:14.879 --> 00:09:17.080 even just staying in your job. 147 00:09:17.799 --> 00:09:24.919 Yeah, for sure, that's the whole like social side of 148 00:09:24.919 --> 00:09:28.159 your career. Like your technical skills are only part of it. 149 00:09:29.960 --> 00:09:32.799 I mean, if you can get by working like not 150 00:09:33.360 --> 00:09:36.559 writing any code every single day and just you know, 151 00:09:36.960 --> 00:09:40.960 saying like spitting a good game to your managers, you know, 152 00:09:41.000 --> 00:09:45.000 you can get really really far, so much so you laugh, 153 00:09:45.080 --> 00:09:46.960 but so much so that there's actually a name for this, 154 00:09:47.039 --> 00:09:50.559 and it's called effective managing up And you actually see 155 00:09:50.559 --> 00:09:56.240 a lot of not helpful, probably not good managers doing 156 00:09:56.279 --> 00:09:58.519 this and that's how they got to those positions that 157 00:09:58.639 --> 00:10:02.080 they're really effective. It commits other people that they're doing things. 158 00:10:02.399 --> 00:10:04.679 Yeah. 159 00:10:04.759 --> 00:10:08.519 Yeah, it's which goes back to your earlier comment that 160 00:10:08.679 --> 00:10:12.759 is very political in the US, that's the basis of 161 00:10:12.799 --> 00:10:18.840 our entire government. Without turning this into a political comment, 162 00:10:19.000 --> 00:10:19.679 let's not go there. 163 00:10:19.879 --> 00:10:21.399 We shouldn't do. Yeah. 164 00:10:21.600 --> 00:10:25.799 But so back on topic here, you're in what does 165 00:10:26.720 --> 00:10:29.679 what does your end look like for you or office? 166 00:10:31.480 --> 00:10:33.840 Honestly, we don't really pay too much attention to it 167 00:10:34.440 --> 00:10:37.159 because we don't go through the marketing cycles. Uh, there 168 00:10:37.240 --> 00:10:40.559 is usually some amount of uptick that actually starts at 169 00:10:40.600 --> 00:10:44.360 the beginning of the year, especially for for two reasons. 170 00:10:44.399 --> 00:10:47.919 One for our products that deal more around the ASIC nature. 171 00:10:47.919 --> 00:10:50.639 So I mentioned we have a like number one or 172 00:10:50.639 --> 00:10:53.879 two slack bot for handling stand ups. And at the 173 00:10:53.879 --> 00:10:56.080 beginning towards the end of the year. Beginning of the year, 174 00:10:56.120 --> 00:10:58.240 there's a lot of vacations. You know, people aren't all 175 00:10:58.279 --> 00:11:00.919 in office. It's more remote work, and so figuring out 176 00:11:00.960 --> 00:11:03.120 how to manage your stand ups in an acinc way 177 00:11:04.159 --> 00:11:08.159 is usually valuable for authors, which you know, obviously is 178 00:11:08.200 --> 00:11:12.240 our main product. Budget comes in at the beginning of 179 00:11:12.240 --> 00:11:13.559 the year, and so that's when a lot of teams 180 00:11:13.600 --> 00:11:16.519 start thinking about more what's going on there, and towards 181 00:11:16.519 --> 00:11:19.480 the end of the year they're dealing with all of 182 00:11:19.519 --> 00:11:22.279 the tech debt, all of the mistakes they've made in 183 00:11:22.360 --> 00:11:26.279 the previous six to nine to eleven months before they 184 00:11:26.279 --> 00:11:28.840 get to that point. And I think one of the 185 00:11:28.879 --> 00:11:33.120 biggest ones is the marketing spam, you know, having actual 186 00:11:33.200 --> 00:11:37.799 users come on board. And I actually remember that earlier 187 00:11:37.840 --> 00:11:40.360 on in my career, I was working at a company 188 00:11:40.360 --> 00:11:44.000 that was had billions of dollars in revenue coming in 189 00:11:44.039 --> 00:11:50.519 every year at the cyber Monday, Black Friday, you know, 190 00:11:50.720 --> 00:11:55.840 huge deal days, right for getting in lots of users 191 00:11:55.840 --> 00:11:57.919 to the site, like not even having to ship out orders. 192 00:11:58.039 --> 00:12:01.039 I mean, the biggest problem is actually the manufacturing world 193 00:12:01.080 --> 00:12:03.960 having to then turn around and manufacture and then ship 194 00:12:04.039 --> 00:12:07.240 that stuff out when it's not just sitting on your shelves. 195 00:12:07.799 --> 00:12:13.200 So much so that I remember that frequently management quote unquote, 196 00:12:13.240 --> 00:12:14.840 I don't know who these people were, you know, you 197 00:12:14.919 --> 00:12:19.360 hear it through the grapevine, like it's coming. You know, 198 00:12:19.399 --> 00:12:22.320 there's going to be a massive wave. You need to prepare, 199 00:12:22.360 --> 00:12:27.120 prepare for that, so only really important software should be 200 00:12:27.159 --> 00:12:29.679 done at the end of the year. I feel like 201 00:12:29.720 --> 00:12:34.240 it's the even more ridiculous version of don't merge code 202 00:12:34.279 --> 00:12:37.679 on Friday afternoons. This is don't don't even think about 203 00:12:37.759 --> 00:12:42.240 code between now and after Christmas. And also there aren't 204 00:12:42.240 --> 00:12:45.879 any people there in the office, so maybe also you know, 205 00:12:45.919 --> 00:12:47.879 push that out to like, you know, January eighth, so 206 00:12:47.919 --> 00:12:53.039 from now until January eighth, everyone's on vacation. And that 207 00:12:53.240 --> 00:12:57.720 just always struck me as so utterly ridiculous that a 208 00:12:58.000 --> 00:13:01.080 software engineers could anyone really, but I'm gonna blame software 209 00:13:01.080 --> 00:13:04.519 engineers could determine the difference between like a critical thing 210 00:13:04.559 --> 00:13:06.919 that needs to get the production and like feature and 211 00:13:06.960 --> 00:13:09.840 something that's not because you're often driven by that perception 212 00:13:10.240 --> 00:13:12.759 of this needs to get done, and you're often not 213 00:13:12.840 --> 00:13:15.440 in the situation of being able to even make that decision. 214 00:13:17.399 --> 00:13:26.360 Yeah, you know, up until recently, I had never participated 215 00:13:26.440 --> 00:13:34.200 in the year end code freeze strategy. But at Polygon 216 00:13:34.279 --> 00:13:37.399 we actually have certain platforms where we do a year 217 00:13:37.480 --> 00:13:46.159 in code freeze, and it's frustrating to me because I'm like, no, 218 00:13:46.919 --> 00:13:51.799 just just just know. This is the part of the 219 00:13:51.840 --> 00:13:53.440 show where I could wish, where I wish. 220 00:13:53.279 --> 00:13:53.879 It could cuss. 221 00:13:54.000 --> 00:13:59.559 But but the truth is is where we have some 222 00:13:59.720 --> 00:14:05.360 very very early stage products and some we've built some 223 00:14:05.480 --> 00:14:11.879 things that, for all practical purposes, have never been done before. 224 00:14:11.960 --> 00:14:17.440 So when it comes to monitoring and alerting, we have 225 00:14:17.559 --> 00:14:20.200 room to improve on that because like, if you've never 226 00:14:20.279 --> 00:14:22.200 done this thing, how do you know when the thing 227 00:14:22.279 --> 00:14:24.679 is doing the thing that it's supposed to do and 228 00:14:24.679 --> 00:14:28.200 how are you going to alert on that? And there's 229 00:14:28.320 --> 00:14:30.840 there's certain stages where we don't We just kind of 230 00:14:31.240 --> 00:14:35.480 watch it until we get a like get the pulse 231 00:14:35.559 --> 00:14:37.600 of it, and then we can put monitoring on that. 232 00:14:37.639 --> 00:14:40.200 And so that's the I think that's a big reason 233 00:14:40.720 --> 00:14:42.919 why we're reluctant to do. 234 00:14:44.360 --> 00:14:45.240 Your end releases. 235 00:14:45.279 --> 00:14:48.480 And then also, you know, combined with that, like you mentioned, 236 00:14:48.679 --> 00:14:52.440 a lot of people are out taking vacation and then 237 00:14:52.720 --> 00:14:57.879 we're completely globally distributed to so we you know, async 238 00:14:57.919 --> 00:15:01.200 communications are very very async. 239 00:15:01.919 --> 00:15:04.639 Yeah, I mean there's a platform thing there, right, Like 240 00:15:04.720 --> 00:15:09.440 if you write games as your company's product, there's a 241 00:15:09.559 --> 00:15:13.080 validation process, same with I mean similar to if you're 242 00:15:13.080 --> 00:15:16.279 in healthcare some other apps, if you're deploying a mobile 243 00:15:16.320 --> 00:15:19.639 app for iOS or Android, there's a turnaround time there. 244 00:15:19.679 --> 00:15:21.440 And so even if it's even if your company is 245 00:15:21.440 --> 00:15:23.639 absolutely perfect, we do live in a more just in 246 00:15:23.679 --> 00:15:26.279 time world, a more agile world where you are depending 247 00:15:26.279 --> 00:15:29.240 on third party partners. So even if you do the work, 248 00:15:29.679 --> 00:15:32.240 you know realistically it's not going to be actually able 249 00:15:32.279 --> 00:15:35.399 to get to production. So rather than having it stack 250 00:15:35.519 --> 00:15:38.399 up where you're creating a lot of waste there that 251 00:15:38.440 --> 00:15:41.200 someone still like, you don't want tons of merger requests 252 00:15:41.200 --> 00:15:44.679 sitting open waiting for someone to come and test and 253 00:15:44.720 --> 00:15:46.679 review your code. You want to get those production as 254 00:15:46.720 --> 00:15:48.840 soon as possible. There's no reason to start that work 255 00:15:48.840 --> 00:15:50.919 because you know it's going to be blocked somewhere. So 256 00:15:51.120 --> 00:15:55.120 I do totally get that, especially if you're depending on clients, right, 257 00:15:55.159 --> 00:15:57.240 you actually don't want to do any work unto your 258 00:15:57.240 --> 00:16:00.399 client already says why is it not delivered already? Right, 259 00:16:00.480 --> 00:16:02.879 Because if they're not already waiting on you for a chance, 260 00:16:03.000 --> 00:16:04.519 you're going to do the work and then have to 261 00:16:04.519 --> 00:16:06.759 wait on your client and then you're like, Wow, those 262 00:16:07.120 --> 00:16:10.919 three weeks to three months are longer. Unfortunately in some 263 00:16:11.120 --> 00:16:16.480 concern cases that I'm sure you've got well, that you 264 00:16:16.480 --> 00:16:18.360 could have been doing something more valuable in that time. 265 00:16:19.879 --> 00:16:20.840 Yeah, for sure. 266 00:16:21.039 --> 00:16:24.679 That makes me think of doing mobile development and getting 267 00:16:24.679 --> 00:16:28.240 your app approved to go into the Apple App Store? 268 00:16:29.480 --> 00:16:33.120 Is that three days? Is that three months? Who knows? 269 00:16:33.600 --> 00:16:34.399 Is it consistent? 270 00:16:34.679 --> 00:16:34.960 Nope? 271 00:16:35.039 --> 00:16:37.759 It could be one right after the other every single time, 272 00:16:39.159 --> 00:16:42.279 and that makes it really challenging to roll out new features. 273 00:16:42.759 --> 00:16:46.519 And then compounding that, just because you release a new 274 00:16:46.600 --> 00:16:48.799 version in the App Store doesn't mean people are going 275 00:16:48.840 --> 00:16:52.440 to update. I remember when I was active, we had 276 00:16:53.639 --> 00:16:56.720 a very very small group of people, I mean less 277 00:16:56.720 --> 00:17:00.879 than ten that hadn't updated their app in two years. 278 00:17:01.159 --> 00:17:03.039 They were running on a two year old version of 279 00:17:03.080 --> 00:17:06.640 the app and perfectly happy, but it was causing us 280 00:17:06.680 --> 00:17:12.799 some painful technical debt. And we finally had our marketing team. 281 00:17:12.839 --> 00:17:16.960 They did a marketing and customer service. They jumped through 282 00:17:17.000 --> 00:17:19.119 all kinds of hoops to actually figure out who these 283 00:17:19.160 --> 00:17:22.599 people were, and then I think they were able to 284 00:17:22.640 --> 00:17:26.119 contact them and ask them and send them a gift 285 00:17:26.119 --> 00:17:28.240 card or whatever to upgrade their app. 286 00:17:29.759 --> 00:17:32.599 I got two great stories on that point. Actually, the 287 00:17:32.640 --> 00:17:36.480 first one is having built a very technical API. People 288 00:17:36.519 --> 00:17:40.039 talk about deprecating old stuff, but realistically, if you write it, 289 00:17:40.079 --> 00:17:42.319 you should just pretend it's never going to get removed. 290 00:17:42.359 --> 00:17:46.680 It's so much like the amount of churn challenge, complexity 291 00:17:46.759 --> 00:17:49.279 of trying to convince your customers, as you described, to 292 00:17:49.319 --> 00:17:51.680 make a change there where there's zero, like, there's negative 293 00:17:52.000 --> 00:17:54.960 value in making the change. Right, it's all work, it's 294 00:17:55.000 --> 00:17:58.000 working today. Why would they why would they realistically change? 295 00:17:58.680 --> 00:18:00.960 It's just not worth thinking about in most cases. And 296 00:18:01.119 --> 00:18:03.440 there are so many companies I've worked with who had 297 00:18:03.480 --> 00:18:05.519 this mindset of, oh, we'll get them to change, and 298 00:18:05.559 --> 00:18:09.079 so they then have like five or six versions, like 299 00:18:09.319 --> 00:18:11.240 one every couple of years. Every time there was a 300 00:18:11.240 --> 00:18:14.759 new engineering lead team you know, owner of that product 301 00:18:15.440 --> 00:18:19.359 roll out something new. And so we started having version 302 00:18:19.400 --> 00:18:21.519 numbers in our endpoints and things like that, and so 303 00:18:21.559 --> 00:18:24.200 you see all of them available in production. Still some 304 00:18:24.240 --> 00:18:25.880 of those companies I worked with, you know, they still 305 00:18:25.880 --> 00:18:28.640 have those oldest versions still there because they don't have 306 00:18:28.680 --> 00:18:32.319 that amount of pull within their organization with their customers. 307 00:18:32.519 --> 00:18:34.319 So actually, one of the things we did when we 308 00:18:34.359 --> 00:18:37.920 wrote Authoris is that we just completely discarded that notion, 309 00:18:38.039 --> 00:18:40.599 like there are no versions, it's will be like this 310 00:18:40.720 --> 00:18:45.359 forever likely. It's it's so totally unrealistic. Now, we do 311 00:18:45.480 --> 00:18:47.799 make some changes where we then like update our documentation, 312 00:18:47.839 --> 00:18:51.440 we may remove reference to fields that we still support, 313 00:18:51.759 --> 00:18:54.200 but we don't remove them because the amount of overhead 314 00:18:55.160 --> 00:18:58.200 it goes in it is really high. The other thing 315 00:18:58.240 --> 00:19:01.559 I'll say is I am totally that person that has 316 00:19:01.680 --> 00:19:07.759 old apps on their phone, like from multiple and I 317 00:19:07.799 --> 00:19:11.000 think there's sort of like a two sided extreme here 318 00:19:11.039 --> 00:19:13.319 where both of them are not great. It's there are 319 00:19:13.319 --> 00:19:15.279 tons of apps out there that every single time there's 320 00:19:15.279 --> 00:19:17.319 a new version, it's like you must update to use 321 00:19:17.359 --> 00:19:20.440 the app, and I hate it. And I'm gonna call 322 00:19:20.440 --> 00:19:23.599 out Signal in Google because they both do this. They 323 00:19:23.599 --> 00:19:26.000 tell me all the time, Hey, there's a new version Google. 324 00:19:26.000 --> 00:19:27.960 At least you can skip it. But the pop up 325 00:19:28.000 --> 00:19:30.400 always happens at the wrong time where I'm like, can 326 00:19:30.440 --> 00:19:33.160 you interact with me at the end of my workflow 327 00:19:33.240 --> 00:19:36.200 because then I'll accept the upgrade, and Signal just says no, 328 00:19:36.319 --> 00:19:38.319 I'm sorry, you can't look at your messages until you upgrade. 329 00:19:38.400 --> 00:19:41.240 And that's just an incredible pain and I totally get 330 00:19:41.279 --> 00:19:43.359 the other side where people are using the app multiple 331 00:19:43.440 --> 00:19:46.480 years later. I'm just so afraid of it breaking something 332 00:19:46.680 --> 00:19:49.400 or draining my battery life because I can't trust these 333 00:19:49.400 --> 00:19:51.960 apps and there's no way to stop them from interacting 334 00:19:52.000 --> 00:19:56.799 with the Google Play integrations to get battery hell or 335 00:19:56.839 --> 00:19:58.559 send messages, notifications, et cetera. 336 00:19:59.720 --> 00:20:04.160 Sure that's the I'm the same way, Like as a developer, 337 00:20:04.920 --> 00:20:07.559 I'm like, why are these people not updating? But as 338 00:20:07.599 --> 00:20:10.759 a user, I'm like, I'm not updating that it's working 339 00:20:10.880 --> 00:20:14.279 just fine. There's no way I'm going to risk this 340 00:20:14.440 --> 00:20:15.039 thing breaking. 341 00:20:16.559 --> 00:20:19.000 I'll tell you a secret. And maybe this is letting 342 00:20:19.039 --> 00:20:22.200 the cat out of the bag here. I upgrade apps 343 00:20:22.359 --> 00:20:25.720 when something looks like it doesn't work, and I won't 344 00:20:25.759 --> 00:20:28.960 know why it doesn't work. So you could, for sure 345 00:20:29.000 --> 00:20:32.000 if you had some way of feature flagging, like a 346 00:20:32.039 --> 00:20:35.440 couple buttons just breaking in a weird way, right, Like 347 00:20:35.640 --> 00:20:38.240 you know, I use Plex and if you hit the 348 00:20:38.400 --> 00:20:40.519 like you know, if I hit the play button and 349 00:20:40.559 --> 00:20:43.839 it like pauses it or you know, starts playing and 350 00:20:43.880 --> 00:20:46.440 it like does it weird jump in the video and 351 00:20:46.480 --> 00:20:48.440 it keeps like it just starts happening, I'll be like, 352 00:20:48.480 --> 00:20:51.319 oh man, I got an upgrade. So that's the secret 353 00:20:51.519 --> 00:20:54.880 for convincing your users to upgrade is really, you know, 354 00:20:55.000 --> 00:20:57.279 have something where they don't think is really your fault, 355 00:20:57.279 --> 00:20:59.880 that you would have done intentionally to get the benefit. 356 00:21:02.200 --> 00:21:05.440 And now if you productize that as a service, you've 357 00:21:05.440 --> 00:21:08.440 got you next huge startup idea. 358 00:21:10.279 --> 00:21:18.759 Yeah, graceful like non graceful degradation. And yeah, we like 359 00:21:18.759 --> 00:21:22.960 our core metric for our ICP would be like the 360 00:21:23.079 --> 00:21:27.599 number of broken apps we have in production at that moment, 361 00:21:27.720 --> 00:21:33.079 right our customers are currently destroyed the user experience of 362 00:21:33.200 --> 00:21:35.960 one million users that could. 363 00:21:35.720 --> 00:21:42.799 Be that's funny, write that down right. 364 00:21:44.920 --> 00:21:49.240 But meanwhile, back to your end, Yeah, because that was 365 00:21:49.279 --> 00:21:52.039 our chosen topic till we wandered off, I. 366 00:21:52.039 --> 00:21:53.240 Think it's really challenging. 367 00:21:54.400 --> 00:21:57.000 Yeah, So in my mind, there's a couple of different 368 00:21:57.119 --> 00:21:59.920 categories of things that you have that come up at 369 00:22:00.079 --> 00:22:02.720 your end. One of which you brought up that I 370 00:22:02.759 --> 00:22:06.039 hadn't remembered until you brought it up is budgeting for 371 00:22:06.079 --> 00:22:09.200 the next year. So you got to start campaigning for 372 00:22:09.279 --> 00:22:12.000 whatever it is you want to do and building a 373 00:22:12.079 --> 00:22:15.039 use case so that it makes it into the budget. 374 00:22:17.519 --> 00:22:22.079 And then like we already mentioned potentially depending on your industry, 375 00:22:23.319 --> 00:22:29.400 increase in traffic for your end sales and special and 376 00:22:30.359 --> 00:22:33.519 you know, for a lot of companies that's just largely 377 00:22:33.640 --> 00:22:37.279 a scaling issue, Like, yeah, I've got auto scaling, it's fine, 378 00:22:37.359 --> 00:22:40.160 but I always like to go ahead and just kind 379 00:22:40.160 --> 00:22:43.680 of cross check everything before we get to that point, 380 00:22:43.759 --> 00:22:48.200 because we've probably made a lot of changes throughout the 381 00:22:48.319 --> 00:22:50.920 years since we last tested this really hard, and so 382 00:22:50.920 --> 00:22:54.240 I just want to make sure that we didn't inadvertently 383 00:22:54.359 --> 00:22:57.319 turn something off that we were counting on or something 384 00:22:57.400 --> 00:23:02.359 like that. And then their category for me is like 385 00:23:02.799 --> 00:23:07.079 ye're in closing of the books, you know, which in 386 00:23:07.079 --> 00:23:10.240 my mind that's that's a financial thing, but I also 387 00:23:10.319 --> 00:23:12.440 think there's an infrastructure side of it too. 388 00:23:12.680 --> 00:23:15.920 It's a good chance to. 389 00:23:15.119 --> 00:23:17.960 Check all your backups and your data retention policy and 390 00:23:18.440 --> 00:23:22.319 you know, restore from backups into a dev network and 391 00:23:22.759 --> 00:23:24.799 validate those and just make sure that all of that 392 00:23:24.839 --> 00:23:26.119 stuff is working as well. 393 00:23:28.279 --> 00:23:31.480 Yeah, I mean, you don't want to be that Australian 394 00:23:31.920 --> 00:23:36.240 pension fund company where they lost all of all of 395 00:23:36.279 --> 00:23:41.720 their one hundred billion dollars worth of financial bookings for 396 00:23:41.880 --> 00:23:45.519 all of the citizens of the country because they were using. 397 00:23:45.400 --> 00:23:46.720 One cloud platform that. 398 00:23:48.759 --> 00:23:51.960 Decided to be extra helpful in setting up their environment 399 00:23:52.319 --> 00:23:56.759 one day. So I don't know if you know the 400 00:23:56.759 --> 00:23:59.920 story here, but apparently yeah, so apparently there was an 401 00:24:00.119 --> 00:24:03.759