Destroying Momentum For Innovation - Principal Software Engineering Manager AMA

just getting things going here the classic startup sequence of trying to make sure everything's connected we're good we're good cool I don't know um my streaming software says that LinkedIn live is currently down I don't know if that's the case I kind of want to test it out so I'm trying to see if I join it do I see it happening looks like yes so I don't know the streaming software said hey it's down like don't use it but seems like that was a lie but um yeah I think it's working I think all the platforms are up and running so sorry if you joined on YouTube because I told you LinkedIn wasn't working I promise that wasn't some type of trick to get you on to YouTube I put a screenshot even on LinkedIn of the of the message that they were putting so I apologize for that it does seem like it's working though so that's good news but um as always I want to remind folks that the chat is where I'll be looking for for messages and stuff I'm just double checking okay I had to refresh the chat on my side it said that like like two entire platforms weren't working but uh that's not the case now so that's good but yeah please as we're going through today's session and any live stream that you're on with me please put messages in the chat I am happy to be answering questions and kind of dedicating the time to whatever questions you have that are coming up in the chat like reminding people that I could be making YouTube videos that are recorded instead and I would much rather spend this time like talking with you so uh by all means please do that uh another thing that I'll just call out to is usually I do these at 900 p.m PST I did a bit of a survey and um basically the majority of people it's hard to pick a good time but the majority of people were saying please something earlier so this is the something earlier that I'm trying out hopefully this time is okay should be a little bit better for people on the East Coast but I realize it's still like 10:00 at night so apologies for that hey Nick Hodge good to see you thanks for joining again I appreciate it so yeah let me know if you're joining in or if you're watching the recorded version of this and you're like hey sucks now because the time doesn't work just like let me know I'm trying to find a better time um I think the earliest I can probably go though on a Monday is like 6:30 um p.m. it just lets me make sure I can get back from work and stuff because I like to go to the office on Mondays and uh I should also remind people that I am planning on doing a live stream tomorrow morning I know I've been saying this for a while but that is the plan it should be at 700 a.m. PST so hopefully there's other people that can make that uh otherwise you can check out the recorded version but tomorrow's live stream is going to be on uh trying to migrate it's not going to happen all in one stream just a heads up it's going to be about trying to migrate my WordPress blog over to a Blazer uh blog engine and I can't pronounce his last name but Stephen uh geil perhaps uh he's a he's a pretty well-known net creator has a popular blog and stuff but he has this blog engine that he's been putting together it's all open you can check it out on GitHub I think it's called Uh link.net or something like that like i l i n k so anyway um I'm going to be doing that tomorrow morning uh infected FPS good to see you yes slightly earlier than normal stream but maybe this is the new normal time we'll see so um today's conversation is like usual based on my most recent newsletter I'm just going to put a link into the chat if you want to check it out more than welcome to I understand newsletters aren't for everyone and this is why I try to put out as much content and as many different formats as I possibly can so hopefully you find something that works for you um if you're here maybe it's because the live streams work well for you um but yeah try to post daily try to make sure that I get a newsletter out once a week I am not back to blogging as much as I'd like so the newsletter is sort of the only blog post I've been doing for months now just because because I've been dedicating more time to coding to get a uh a product and platform launched so once that's uh more sustainable I think that I'll try to get back to getting some blog posts out so apologies for not uh kind of focusing on that I I do enjoy being able to write stuff up and help have explanations for people so anyway uh that is going to be the link to my newsletter it's called um well the thumbnail says technically infeasible and then it's it's really about destroying momentum for Innovation so we're going to be chatting through that again if you've just joined please feel free to use the chat ask questions about anything you want even if it's completely unrelated to uh the topic of the newsletter so uh with that said I'm going to try to dive into things so this um this came up recently because I was chatting with a couple of friends about this concept um sort of in terms of like what I would call like true agility and soft development and I've also had a couple of things at work that have reminded me of this so uh the beginning of this newsletter and what I'm going to be talking about is kind of like what I was doing before Microsoft just so people have some context if you've seen my live streams or my other videos and stuff you might you might know my whole life story by now but uh I am going to be kind of covering some of that ground first that way you understand where I'm coming from because I think it's important people understand this like I'm just a dude on the internet right I have my own lived experiences like everyone else I'm going to have biases about things and when I talk to you about my experience is I never want to come across like what I'm saying is the absolute law or the absolute truth like it's one way or or no way um I want you to know that like I I'm acknowledging my biases and I want you to be able to think critically about what I'm saying so this is just my perspective on things so um yeah before Microsoft uh so Microsoft I've been at Microsoft now for just over four years and prior to that was working at a startup company and the startup I got to be there like from the time it was around eight people and then after eight years I uh had come to Microsoft but that company had grown from around eight people to like between 250 to 300 people so it had grown pretty significantly that's a a pretty big pretty big ramp up in staff uh we didn't have at the time uh any external investment so this is something that was just like natural growth and I don't know like that's pretty rapid growth in my opinion I know that's 8 years but like for not having Capital injection and being like here's you know $100 million go hire you know all the engineers in the world kind of thing it's pretty significant growth for just being uh you know self- sustained so from my perspective a pretty unique experience because I think sometimes people are at startups and they they're there while it exists as a startup and then they leave they do something else sometimes startups don't make it unfortunately and other times people have joined companies after sort of like the time I left this company like you're coming in after that so you missed the whole startup journey and it's kind of like it's a small mediumsized business at that point but I got to go through like this really exciting journey of like hey this is a tiny company we have no idea if this is truly going to work so let's make it work and then kind of proving after after a few years like hey it's working so uh pretty cool experience and um let me just double checking some of the other points I wanted to make I guess for context um so I think this is kind of important as we go into the other parts the the space that we were in was digital forensics and while the specific space isn't that important to this conversation uh the point I wanted to call out is that we were a startup in the digital forensic space and there were already like two big companies two primary companies I would say that for computer forensics had a complete Monopoly over the space okay so U I'm not going to list the company names because it doesn't matter but there were two companies that um that truly had like I don't know like the entire market share um on Instagram you're saying post this live I don't necessarily know what you mean by post this live um and I'm looking at it from my computer and I don't necessar neily know how to do what you're saying there sorry um on Tik Tok cuz that's not being to the sh coming to the Shar chat um did you get rewarded for being there at that important juncture um that's a probably a conversation for a later date but the short story is like uh is no um and for brief context because someday I'll I'll probably talk more about this but um this was probably like the arguably the worst timing of anything in my entire life but um I had left that company yeah sorry it's weird but I left that company um because it was not public at the time and the way the contract worked I basically had to sell back my shares that I had and when I sold back my shares it wasn't even at the arguably what the latest valuation of the company would be it was probably like four years stale so I sold my shares back at um a very small dollar amount so yeah I had a payout um but that company ipoed shortly after they got bought back to private for uh $1.8 billion that's with a b and um long story short after a couple of stock splits or it was like a triple stock split or something if I would have stayed there I would have never had to work again in my life um so probably financially the worst thing that could have possibly happened to me so far um there's still time to make worse Financial mistakes I suppose but um yeah so that's kind of what happened there uh the pro the real answer that you probably want though is like did you get rewarded for being there at that important juncture no but I was rewarded I think very fairly for my time there I always felt that I was being compensated fairly um towards the end I was trying to say like I don't think my salary is quite quite fair and having conversations about that and and you know like I had good working relationships with uh with my manager and stuff so it wasn't like a hey man listen up or else it was just like a genuine conversation about compensation and the trajectory of that so um that always felt good and like I said um I felt I felt like along the way i' I've kind of said this before I used like I used to work like crazy itd work you know non-stop around the clock and um and did this for years and part of that was like I felt valued like honestly I did feel valued I know people are like oh all these companies like we're a family I'm like yeah we were a family at the beginning when it was a small startup we were absolutely like a family and people don't like to hear it because they're like that sounds like bull crap like I don't know sucks if you haven't got to live through it but it was uh it honestly felt like um like working I still have like some of my best friends are from that time so to this day right so yeah I think um felt very rewarded going through it but yeah at the at the end it was definitely having conversations about like salary compensation it's very different especially in the US maybe it's different for some other Canadian tech companies but in the US we talk total compensation like sign on bonus salary um stock like performance rewards things like that so there's different ways to factor in and I had stock at this company just from being an early employee but really the conversation every year was just like how do we incrementally increase the salary and it was kind of reaching a point where I'm like I I'm reaching a point where I am no longer inspired to be like to be working as much because it's it's becoming disproportionate so that's kind of what it felt like by the end but uh yeah I still you know there's people there that um absolutely will be friends for life kind of thing so um I don't have the video super handy if you give me one sec I'll try to pull it up um and I don't know if I can put links so one sec uh because I made a YouTube video about this and I want to see if I can just search it on my channel quickly but it kind of talks about my time there so so one sec if you if the links don't work when I put them into the chat then you can search for uh just the word promotions or principal level actually promotions is probably one uh that'll work best but you can check that out again sorry if the link doesn't work if you're not on Tik Tok and you want the link it's that video right there that I just put into the chat um oh and then apparently I didn't know this for Instagram it as a post after the live and so we can still view it I don't get that option every time it tells me that I have to discard the video so I apologize if uh if you're on Instagram and you want to watch it later it will be on YouTube so some people are probably watching this in the future and it's on YouTube so it'll be there but yeah thanks for the the questions in the chat I'm going to dive back to the uh the article here but yeah if you have any more questions please just ask him a pretty open book um I think it's important to be transparent about things so okay so yeah the kind of the story that I was telling is that we had these two major competitors that had a essentially a monopoly over all computer digital forensics and we weren't even in the mobile forensic space at the time but we had uh later which I'll talk about we had basically one company in like all of digital forensics that had an absolute Monopoly over all mobile forensics they were backed by like a a multi-billion dollar Japanese company like they they were the company that did mobile digital Fric so um something interesting to talk about as we go through this so something I wanted to call out sort of at the beginning of this is that I don't think from my perspective I don't think that we were successful as a company because we had smart people like we did have smart people we had great Engineers we had a great you know sales marketing team a lot of things had to line up but I wouldn't say like you know are there companies that have more more smarter so more in terms of number and smarter Engineers or better Engineers sure like sure there are I I would say that's probably statistically very likely that that's the case so I don't attribute our success as a company to just having like good software engineers and certainly like when I started there like we were there were probably at times like almost the same number of interns as like as full-time people so we had lots of Super Junior people the average age of these of the software engineer team was like pretty low so it's not like we had like a a stacked team and it was like in hindsight we were making a stacked team we had lots of people that became very awesome because they were awesome but they didn't they didn't have like a 20-year career like you know doing digital forensics and all this like startup experience so yeah like we were kind of figuring things out hey David uh from YouTube good to see you uh what's good how you doing I'm doing pretty good live streams a little earlier um but yeah we're going to be going over some some startup stuff so at this point I I just wanted to call out that I think a lot of our success was attributed to the culture that we had and I don't know some people might think that's kind of weird I don't know depends if you kind of worked at startups and been able to see or even just different companies and seen like what good culture feels like versus not um again it's going to be based on your own personal experiences but um I I think that we had like a rock solid culture that that it's honestly like one of the reasons that that helped the company succeed I think I think without the culture we had even with more Andor Better Stronger Engineers I don't necessarily think we would have been um as well off as as we were as that company so anyway that's sort of the preamble to all of this so the next part I've talked about this a little bit in the past um but it's like just how culture changes right so there's a few examples that I I'm going to go through that I have talked about either on stream or In Articles or in YouTube videos um and I think like there's more examples of these types of things because culture does change as a company's growing um okay so in chat what are some indicators of a bad culture yeah this can look very very different from because there's basically if I do the inverse and say these are all the great things about culture just invert them and there's probably tons I'm going to miss when I try to explain this but um one like one example of something that's not great for culture is like um I would say like this like a feeling of complacency and this can look different so complacency in terms of how we are trying to innovate so if we're just trying to say like it's it's always just good enough and we're not really thinking outside of the box I think that can kind of uh stagnate some of your Innovation so that's that's one thing complacency can also come from like a leadership and management perspective so let's say that you bring on people that are not a great fit for the company and it's kind of a weird thing to gauge like well what do you mean not a great fit well what I mean by that some obvious cases are you've probably heard of like the I don't know like the prototypical like intelligent jerk there's usually a different name for that I don't know if YouTube will get mad at me um but basically someone that is very intelligent they're they're good at what they do but they're difficult to work with and in fact they make it very difficult for other people to work with them so this is an archetype of person um you might know someone like this maybe you are this person but basically they're like they're smart it's no one's judging like how much they know or how well they know it but the problem that ends up happening is because they're difficult to work with and that could be because um they have expectations that are very high and they don't communicate well with others they're kind of like gatekeeping certain things they're difficult to collaborate with basically if this isn't addressed early on and you have management that's just okay with this happening you have like One Bad Apple that kind of uh stagnates the entire team and not only is it like a um like neutralizing the effectiveness of the team it literally becomes a net negative and how you know this is that when that person is finally gone the entire team becomes like almost exponentially more productive and it's because the entire team can actually work so those are a couple examples of culture uh I would say like leading by example is a really good thing um creating an environment where people feel safe to make mist Stakes so um a bad culture would be like okay so someone someone broke the build or there was a bug that was found in production and then like person gets fired for it and it's like okay now no one wants to take any risk like everyone's scared um like that would be a bad culture sounds like almost made up but I'm sure there are places that are like this uh I've been very fortunate that I've never worked at a place like that it's always been uh you know people people are okay with mistakes being made as long as we're reflecting on them and that kind of thing you're also not being negligent about what you're doing so those are a couple of ideas uh so Express package if you have any more questions about that if you want me to dive in any other directions let me know happy to to do that but maybe that's a good start so some of the things that will shift in culture are like and it's going to be like one of the main things I'm talking about today but this idea that you go like for us we were we were this Scrappy startup right we were The Underdogs we have these uh huge companies that have monopolies on things and it's kind of like this insurmountable goal right they already have the Monopoly who are we right we got we got a cool product it's pretty handy but like they have all the users you know they're they're the ones who are you know they're they got their Cash Cow we're just this random company that's tiny and I guess the only thing we got going for us is that people like us like we have a tool that we're releasing and people are happy with it there's good feedback on it uh Hey Buran good to see you I see you on every platform now which is awesome great to see you on the stream so at this point right in our like early on in the company culture like I said Scrappy startup we underdogs it's kind of like I don't know like it's the typical like kind of startup thing that you'll hear about where we'd stay up late we're trying to get things done we just want to ship value to customers but we lived that that was just what it was like for us and and no one forced us to do it but when I talk about culture like we were selfmotivated to have this happen and not not every single person especially as the company grew was like that but there was enough of us that like that was our culture was to be like hell yeah we're going to get this done and nothing's going to stop us it was kind of like because it felt like we had nothing to lose right like we are The Underdogs it's not like we're at the you know we're not King of the castle and like when you're at the top you have everything to lose we had nothing so we worked really hard for it and I think that that's like something that definitely changes over time because well and I'll explain more about this but I think what happens is that as you come into the company as we've been achieving success you know over time right so in the first year the company's bigger it's more successful second year third year fourth year like it continues to have success because of this culture and what happens and this isn't anyone's Fault by the way I want to be careful as I talk about this I don't want to make it sound like I'm resenting anyone that doesn't feel this way because I understand like if you weren't part of it in the beginning it's it can be very hard to get behind things and be like hell yeah this is awesome because you didn't you didn't live through it it's okay um and sometimes people can join in and they they are feeling that way so I I just want to be careful that I don't want to make it sound like I'm resenting anyone for for not having the same mindset but what happens over time is you have more people that join that are kind of just used to the company being in a successful State and like I said nothing wrong with that but what happens with the culture is that when people are used to it already being successful without all of the things that led there the idea of like how much effort that takes and like what it what it looks like to to reach there you're kind of I don't know like you just you assume that you didn't have to do that it's because you haven't seen it and it's okay but that changes the culture over time because as it grows and becomes more successful more people are sort of removed from this sort of origin culture that kind of started it off and it's really hard like it's really hard to keep that going so some of the other things I've shared before and this was like one of the I don't know how many weeks ago this was but I did a live stream and it was like who wrote this garbage right so this idea that when people are coming into an organization and they're they're questioning code bases or uh processes or whatever it happens to be that you come into the org and you're seeing it with your own perspective going like man this is ridiculous like why would anyone actually do this it seems like it's very broken or the code's very bad but again what you're missing is like someone wrote that or implemented that at a time doing the best they could with the information they had so you need to assume best intentions someone didn't go write that code and they're like man I can't wait for four years from now when someone joins and they're like who's this idiot like no one does that maybe maybe some people do but you know I don't think anyone's purposefully doing that so the idea is that when you're joining a company I think it's very important to be curious but genuinely curious so asking about code or why things are a certain way I think is a very important thing to be doing to be asking questions but it's all about why you're asking that question because if you're being curious that's a very valuable thing if you're just doing it because you're making fun of it or like trying to show that you don't think that people are competent I think that's the exact wrong idea um Nick hodj software archaeology can be fun yet revealing reflects the organization yeah and what's cool though is even if you come across code where you're like man like what the heck is this this is bad instead of just like just as an example instead of going into it being like turning to you know a buddy or messaging them on slack or teams or whatever and being like dude have you seen how bad this code is I can't believe some wrote this because like your buddy who's been there for 10 years they might have wrote that code um if you didn't check get blame first but the um the point is instead of doing that could you imagine going to that same person and saying wow I just came across this code I'm really curious like how we ended up getting here like and then trying to do as Nick Hodge was saying software archaeology trying to understand how did we get to this point because what you might learn is that there were very interesting constraints I'm doing some foreshadowing here some very interesting constraints that led to making that decision and in if you want to go back and watch one of the live streams like I said it's all recorded on YouTube um in that I gave some examples of like in one scenario one of the best optimizations that we had put into our forensics product for performance one of the best optimizations a few years down the road was the single biggest bottleneck for performance without any code change at that spot it just became the thing that was lagging behind the most so an interesting way to kind of look at things but I think it's important to be curious and then on um this is from zoma on on Tik Tok facts their actions lead to the new guys hiring yes so you have to think that like if you're if your your culture is going to be evolving at a company and this is just the way it is it's okay um like as much as I enjoyed that very early stage culture realistically for it to to hang around for indefinitely and never change and evolve I don't think that's realistic there are aspects to it that I think would be awesome if they continue to live longer but culture has to change um so as it's changing though you need to be thinking like these individuals that are part of the new culture will be hiring more people right and then you have to be thinking like how do you if there's a culture that you want to maintain like how do we you can't dictate a culture you don't just go to your organization and say our culture is X and then people are like yes that's the culture culture is like the result of how things are lived out it's the it's the side effect it's the observed Behavior right it's not what you dictate and then people do it if you try to dictate the culture you'll probably realize you'll have a bad culture because it's the side effect of what you're doing so it's true your culture is going to change the who wrote this garbage thing is one example of that another thing that's the I wanted to share in this article um sort of the inverse factor that can happen so the who wrote this garbage example is basically like new people coming in and being like Oh man like how ridiculous is this this other example that's probably more common people have heard about is like this phrase It's always been this way and this example I like sharing because sort of this generalization but I'm talking about it as an example I think is interesting because when you put these side by side and compare them this one is very much like when you do have people coming in and being curious so they're kind of doing what I suggested in the previous point right be curious ask questions you might come in and say hey like I noticed we do we do this thing and like here's where it is in the code and or whatever we have this process like just wondering like you know why we do it or have we considered this other thing like being genuinely curious right and then someone going well we've always just done it this way end of conversation um Patrick on YouTube basically what you're saying is cultures observed not dictated that's 100% correct yeah there are things you can do to try and influence culture things you can do to try and um like encourage things within culture right but it's kind of like you you don't control people you don't make people do different things but um this is why I think having really good leadership that leads by example like can really help shape a culture because people will try to emulate that behavior and naturally if your leadership is doing all the things that like you want at of a culture I'm not saying it's going to work perfectly but that generally helps people align to to things that you you might be looking for so the it's always been this way thing I think is is very dangerous um it's it's very dangerous when you leave it at that so a lot of the time when this comes up people are being dismissive about it so someone will be curious they'll be asking like hey I noticed we do this thing like why is it this way and then instead of uh encouraging conversation and curiosity someone just says like it's always been this way end of story move on and then one of the big problems with this is that not only are you not being curious with the person entertaining the HM like what does it mean if we were to reinvestigate that now not only are you not doing that but you're also kind of teaching people don't ask questions and you're teaching them that because if they're going to ask a curious question and you dismiss it then why are they going to ask more questions right especially a new person so I do think it's important there's nothing wrong if something has genuinely always been that way you're allowed to say that I'm not saying don't I'm just saying don't stop there don't be dismissive with it hey it's always been this way it started off for this reason and uh at the time we felt like this was the best decision but based on your suggestion I'm actually not sure now maybe that should be re-evaluated uh maybe that is a thing we've already considered I wonder if there's other opportunities like you can you can transform that into something that's open-ended and sort of continues like the Curiosity instead of just being like shut your mouth we don't care about your ideas move on like it's not a spot you want to be in okay so and then yeah zoma on on Tik Tok facts the newer generation can amplify and transform yeah and like this is a thing like you want to in my opinion you want to have a culture that Embraces that so letting people come in with new ideas think is important it doesn't mean that anytime someone's like hey we should try whatever you just drop everything and go do it but like we should be listening we should be curious with them I think that's that's where I'm trying to go with that the next part of the article um was was starting to introduce this technical infeasibility idea so this is another sort of culture shift and something that I observed that I don't know if it just comes from like kind of like the air quotes like Scrappy startup times uh I don't know if this is something that is like a behavioral trait a personality trait kind of thing but um I wanted to talk about it because I thought it was very interesting in that again I don't have when I talk about things by the way I said this in a vlog I recorded earlier but I don't I don't have stats so when I'm talking to you about things like I'm not trying to say like this is I said like it's not the law earlier I also don't have stats it's all anecdote so um if you want to challenge me on these things that's totally cool I'm not here to say unless you literally see me pulling up like a fact sheet and like citing something and saying like here it is like it's anecdote so just a heads up um so the idea around this okay let me let me answer Ban's question here in the chat so is uh is it recommended to have someone between the CTO and developers uh at different points in time yeah I think so um when we were a small startup like my like when it was like eight people my boss was the CTO and over time so like shortly after like I be I became a manager within months of working at the company not not because I was an excellent manager it was because we were growing the teams and we needed managers and we didn't know what to do so so I became a manager U very early and so that that meant for other people like I had a I had an engineer that I worked with that was older than me had been in industry for significantly longer I had just started and he reported to me like you could imagine that was a super weird feeling for him but like he was not the kind of person that would be a manager not because he's like not as good or something but I think based on his skill sets and interest that wasn't something that that aligned with him so immediately for that person like he was no longer reporting to the CTO so there was someone between the CTO and Developers for him not long after that what the company was doing was introducing um they were taking advice that was basically like like build your bench strength so if you're thinking about this is like a I think it's like a sports reference I'm not big on Sports but you have your your roster of people your bench and you want to build up the strength of the people on your bench so you'd hire in people that do all these awesome things so you build a strong team and so this company did that they were trying to bring in like they bring in like a someone as a VP so now CTO VP and then us as the engineering managers um later on they would kind of expand to have uh like directors between the engineering managers and even the VP so like a scale thing gets introduced but um one thing that like if if I could go back in time If This Were it's not my company by the way but if it were my company and like one of the lessons that I observed was like I think there was a lot of missed opportunity to take people that were that were doing a good job and put them into those positions and what happened was like they would hire in external Talent a lot and then that external Talent genuinely was not a good fit so the goal was to bring in someone awesome and kind of level up everyone and what would happen is is like someone would be brought in and it would be like a net negative effect then that person would leave and then basically you would feel like the entire org like kind of like uh catch up and like and and get better so I think there was a lot of missed opportunity to say like take someone who's already basically doing this and give them give them the chance to do it or back to what I was saying earlier around complacency is like be more aggressive if you're bringing in someone that's that influential like I would say you got to be ready to make decisions like that to get rid of people if they're not good um but we were learning like we hadn't done this before right so a very interesting and challenging kind of kind of thing thanks for joining Z I appreciate it um so Patrick is it normal that a startup is giving a junior Deva task that nobody else on the team knows how to do H and they call and that they call R&D yeah I think uh if you're asking if I think it's normal for a startup to do 100% yes do I think it's awesome and the best way to do it probably not but I think that uh startups and things like that can be very unique and different experiences from startup to Startup right so in this example is giving a junior Devas that nobody else on the team knows how to do is that good I would say it's very situational right so you might have and I've certainly worked with more Junior developers that are very hungry to go learn things right like they're passionate about problem solving they're eager to do it um and they don't need a lot of structure and you kind of set them off and they can do great is that common absolutely not um it's not common I don't think until for for many people until they're more like at a senior level engineering position because they've experienced enough to go like do that effectively but I do think that some people can do this very effectively even as a junior but um a very situation so if an entire company's approach just as a blanket statement was we got Stu and we don't know how to do it so give it to the Juniors and hope they you know throw them in the deep end and hope they swim I don't think it's a good strategy but I think it is going to be situational so hope that helps okay technical in feasibility agile and estimates so uh I am a person that likes agile software development I don't like the the rules of agile because I think that is completely counterproductive so uh while I like a lot of the concepts of agile I talk about agile more as continuous Improvement because that's how I like to approach agile in general um I have seen scrum work well I have seen can band work really well um and I have seen many times where people try to make these things hard rules and processes that you must follow and then the side effect is that you have scrum that does not work well you you have can ban that does not work well and at the end of the day when at least from from my lived experiences when I hear people talking about like agile doesn't work I think it's because you weren't doing agile you were doing a a like a hardened process and then labeling it as agile because someone said scrum looks like this go follow it to a te and then you said that didn't work so therefore agile doesn't work I just think that's kind of bull crap it's like I don't have another com comparison off the top of my head but like in my opinion doing things an agile way means that if like what's recommended for scrum or recommended for cban if that's not working don't do it like I think it's I think it's that simple and if you're talking and working with your teams you come up with these things you're like hey man like we've been doing story Point estimates they freaking suck like I don't get any value out of them we waste so much time and then you go okay well what was the goal of the story Point estimate well it was so that we could figure out how much work we can do and when we start thinking about that more it's really just so that we can tell product like what kind of features we're going to have for the next release then you start asking better questions about this like can we accomplish that in a better way can we work with product to Give Them Enough insight for what's coming up if we're on course for that if we're deviating and can we do that without story points yeah okay let's do that and that's kind of where I'm headed with this conversation so I had managed a few different teams I would absolutely say that when I talk about uh like agile this way I literally did all of the wrong things following agile because I'm like I don't know what agile is here's what scrum looks like when I read about it online so I did all of the things where it's like put the rigid process in place but I think one thing that was common and consistent was just like genuinely trying to listen to problem areas in retrospectives or and and outside of that too not just in a retrospective but always trying to listen to where do we have problems and like let's just do something about it so in teams I managed at least we I don't want to say very quickly but after a couple of years at least just started moving away from things like estimates and and I'm trying to think like I never went back to I never went back to things there would be times where we're working with like our partner teams and their product owners would want estimates and we would just say like we can't give you that accurately so like we could talk like you might have heard of like t-shirt sizes we could say like that's going to be something that is big and ambiguous and we actually don't know but that could literally be on the order of of months could like we just don't know um because you don't even have enough context to give us so we can't possibly give you a good answer um now for us this worked well because we had really good working relationships not only within the team but with our product owners they were always brought in but um what I wanted to share and I'm like I'm already like 45 minutes into this but the the the goal was this for for talking about this was this cultural mindset of like um we don't we don't talk about things as in like here's all the reasons that it's going to hold us up and we can't get it done we always approach things in the exact opposite direction and what I mean by that is like if product owners came to us and they said like customers like we've done the analysis customers need this or the business wants us to move in this direction we think it's important um here's like the reasons why it's not like like when I say we had a good working relationship with product like we could push back on product right we could push back back on them we could ask questions they would give us data they would help us understand things like it was it was a good working relationship and that meant that when product would tell us after we'd go back and forth if they're like and at the end of this sort of debate or conversation they're like and that's why we need to do this hell yeah we're doing it so it wasn't a matter of like oh like that's going to take us months and months to do like here's a six-month estimate or a year estimate we'd say like when do you need it by and instead of finding all of the reasons to go push out the deliverable oh we're going to have to go refactor all this this other thing we have to go we don't even know if that's feasible like we have to go do this we have to go do that we're going to have to we don't have tests in this area this this part of the product doesn't even exist yet it's going to take us two years instead of going through every single reason why it won't work we started doing the opposite we started saying like what's the quickest way that we can get you some of that value right and what we found was that by focusing the conversation this way is that we could always move forward in a positive direction that would work towards adding value and instead of being in a position where you're telling your product owner you know we're not going to be able to get that done for eight months and they go okay well what about this other thing and you're like yeah like I don't know another eight months for that this other thing well that's that's a year they're kind of left with like a okay every opt sucks so let me pick the least of the crappy options and then development teams go off and do it and then 5 months go by and then products like customers aren't even talking about this thing anymore because we' kind of missed the opportunity so like what about this other thing and you're constantly trying to like work towards these goals that are super far out and because they're super far out things change over time and you're like kind of like spinning your wheels in the long run so in the chat um my own view the value of any buzzword that doesn't have categorical or similar rigorous interpretation is suspect what I've seen from scrum agile various estimate cultures just a form of gatekeeping if you're not involved in prioritizing what's task it done and which do not there's no point to estimates yeah I think so on this I don't I just don't think that estimates are like ever accurate and I think that I think the intent is good or can be good like ultimately people are trying to figure out how much work can get done in a period of time because based on someone's role especially depending on on what kind of software you have if you have a release where you need to get a bunch of features in you need to communicate that with marketing and stuff like that like I could understand why people are like we need to know what to tell them like they have to start on that material now so there's a lot of reasons why I can see that people want it I just don't think that a lot of the time the estimates are good they're not realistic but what do think kind of like is kind of funny but I I think the only value I've ever gotten out of doing estimation meetings has nothing to do with the estimate itself like I think I've never been in an estimation meeting where I was like oh that's a good estimate I can't believe we came up with that can't wait to go work on that because odds are we could have finished the work by the time we finished the estimation meeting but what I've noticed is valuable is hearing about how other people think about this thing so if we could could just repeat those things and not even put estimates out there and just listen to how people think about stuff I think that's super cool and the same thing with planning meetings for what it's worth when you're doing like strategic planning that's like over a year out you're not going to that plan is not going to happen like that's the only thing I have 100% confidence about in a planning meeting that's like 6 months to a year out the only thing I can tell you is that plan is wrong not that the whole thing is wrong but that plan is wrong like you're not going to do that plan so again the value is in my opinion is not how accurate the plan is because it's just not going to be but it's the conversation and learning the different perspectives about these things that I think is very valuable so um Elemental Magic's card game thank you for that I I thank you for sharing your perspective on it that's couple of other things that I'm thinking about when you said that uh ban the estimates put much pressure as we used to do uh put much pressure as we used to under estimate user stories but it helps when the team has good experience yeah I think at the end of the day like whatever you're using if you it's I think it's just about getting alignment I've not personally seen story Point estimates and things like that work well in any team I've ever seen but I'm not trying to suggest that they can't work well I've just never seen it happen and that's why like I don't go into teams and suggest doing it just because it hasn't been my lived experience um but yeah Nick H funny how communication ends up being at the center of everything and yeah so um this is a good reminder let me do um thank you Nick for the reminder you're not a plant in the audience although you probably should be at this point um let me flip over to this um I'm by the way this is just a newsletter article I have um course time so I have a course on nailing the behavioral interview and it's because as software Engineers we are hyperfocused on all of the technical things it's just how we are I get it people love to program people love tough problems but as Nick haod was saying communication ends up being at the center of everything and this is more and more obvious the more experienc you become as a software engineer because you start going from like hey I can work on these small tasks mostly in isolation into I need to collaborate and coordinate across the team across multiple teams across organizations I need to work with other roles so all of your like non-technical skills become incredibly important especially as you become more senior so uh Ryan Murphy and I created this course specifically around the behavioral interview part um if you for I imagine many people watching this have already you know you're you're working at a job right now you've gone through something like this if you have not the behavioral interview portion of your interview is not focus on anything to do with your code it's not about system design it's it's all about different sort of like behavioral traits and Ryan Murphy and I try to cover that in our course so I'll just put the curriculum up on the screen so you can see it here um we do have a portion I thought was pretty fun we interview each other now the answers to the interview like mine are made up uh I think his are are true but we didn't tell each other the answers so we it's a it's a real interview and when we do the analysis after you get genuine feedback that we give each other so hope you find it interesting it is on doome train so I'll put a link in the chat if you're interested and Ryan and I are working on more courses for Dome train that are not specifically about C and.net they're all going to be about career growth so hopefully you find this kind of stuff helpful but that's my little plug for now so kind of got to find good opportunities to insert this stuff because it's why we make it we're trying to be helpful so our team that we had focused a lot on all of the stuff that seemed like it couldn't get done and it's funny because I managed several teams where it was almost always like this so um I I'll share a couple of stories and each one of these teams took this perspective that I was talking about which was we're not here to tell you all of the reasons why it can't be done we're not here to tell you all the reasons why we have to push the deadlines way out into the future we're here to tell you that we're going to start working on it start making progress and we will constantly keep you updated with where we're headed so we changed our perspective from trying to say cannot be done to let's find all the ways that we can get something done and more often than not statistically for us getting something done was really all that mattered and we had a lot of success doing this so um the couple examples that I talked about in the article was at one point I ran a prototyping team um and by the time I left we were just sort of uh I was doing a transition between managing two teams in particular and we were kicking off the prototyping team again sort of as like a as a real boy it was like a first class thing that was going to exist cuz when we did it originally it was kind of like a trial run but the prototyping team we had originally was so successful at prototyping that we put ourselves out of prototyping jobs so we approach things as okay there is a question to be answered we're not going to take the things that are coming in from product owners and be like oh man like that's not going to work can't be done we're not going to do this it was literally okay you need something done we're going to start and again focus on all the ways that we could try to get things done so uh we prototyp typed off the top of my head at least two products at least that became fullon things so one of them was like uh we have Cloud acquis well I say we I don't work there anymore company has like Cloud acquisition software so we prototyped that we built the first variation of it to say can we do forensics on cloud services the answer yes um we I'm not going to go into the details of the other ones but like we basically had this cue of work and we blew through it faster than they could fill it back up so we basically put ourselves out of work um but the whole framing was we we'll find all the ways that we can make progress not the opposite um I'm going to talk about another team briefly I I forgot about this is kind of funny I forgot about this team in particular until I was writing this article and this team was kind of funny it starts off with the name the name was called The Expendables which is an action movie if you haven't seen it um but the idea with this team was that they were able to they as in like product owners and Leadership they were able to drop us into areas where we could go effectively get things done and I actually so I vlogged about this again um which is another good plug I have another YouTube channel called code commute if you are interested you can check it out I I'm just going to put the link in the chat so code commute every time I drive to the office so to the office and from the office and sometimes when I'm driving back from Crossfit I do a little Vlog in my car I'm just it's literally just me driving and doing a stream of Consciousness mostly about software um and software engineering uh sometimes like entrepreneurial stuff and things like that but it's just a stream of Consciousness but I vlogged about this today and the expendable was a team that very small team and we didn't have our own area of ownership so what would happen is that this is a pretty common thing is like there are business priorities that have to get done and what would happen is like a team would say like well we have our Charter we know what we're responsible for and based on our team's priorities like that work doesn't fit and then another team would be like yeah also like that doesn't fit our stuff like doesn't fit our priorities but if you to zoom out across these teams and look at it from a more of like a holistic view the business is saying this work is critical and needs to get done but we don't have a team that's sort of like able to schedule it and I'm not saying that the solution we came up with is the best solution I think that probably suggests there was maybe some things with product owners or even engineering culture where we should have done a better job to handle this kind of thing I don't have a good solution for it our solution at the time was this team I had called The Expendables so they would say look Expendables no one wants to do this work not quite that way it was more like other teams are tied up doing this stuff and it's not fitting in with their priorities but the business needs this done and we would say hell yeah okay let's go and effectively we would parachute in without actual parachutes it's mostly like a a g pull we pull down the code uh and we would go understand what had to get built and then we would go build the thing so yes we would have to go make sure we're talking to the other team we probably didn't do this effectively right in the beginning but um our team was basically focused on how do we get done what you're asking for and it's not about excuses for all the reasons it can't happen like we're going to go and we're going to get it done so um I should also be careful as I'm saying this I don't mean to suggest the other Engineers on the other team wouldn't get it done that's not my point my point is that as an entire team they were unable to prioritize this work so that's what I'm trying to say not like they sucked or something or they weren't capable nothing like that just that our team had the focus and the mission to go say like we will go get these things done for you it's not about finding the reasons we can't and a lot of the time one common theme with all of this is like what we're not promising is that the thing that you're requesting we're not promising you that we can 100% deliver it we are promising you with 100% confidence that we will move in that direction and like I said earlier that that framing was almost always completely sufficient to be able to move the product and the offering in that direction offering value because we could go repeat it later or the business could pivot and say that's good enough we actually don't need to invest there because there's these other opportunities and thankfully we didn't waste another eight months on it because now we can go invest in these other directions the last one I want to talk about is this mobile acquisition team that I managed and this is um I think to this date probably my most proud like kind of uh sort of like career accomplishment so um magnet forensics I started with a with a colleague and really good friend of mine uh started the mobile acquisition team that they have and the entire team started with the philosophy that I'm sharing here which is like there is a way and we will find the way not it's technically infeasible because and I should have been repeating this more throughout this conversation when we take this framing of it's technically infeasible if we would have been doing this more early on at this company I can say I feel like with a high degree of confidence I don't think that this company would have succeeded and I'm not saying that it was just us because there were other situations where people would do this but I think that was a part of the culture trying to bring It full circle here I think one key thing that came up at least enough in the culture was that we would find ways to get things done and as long as we did that more often than not which was sort of the opposite is like let me find all the reasons why that's not going to happen or take ages if we could at least say more often than not we will try our best to work in that direction and we get it as long as we can do that more often I think that's what led to the success of the company with the mobile acquisition team there was a I don't need to go into all the details I guess but basically there was a project that was pretty far off course there was um Financial spend and a project that was just completely off the rails and we kind of looked at the situation and we said there's there's almost like no excuse for that because what we're hearing back from the people working on the this project is like it's literally like it's technically infeasible to do these things that you're asking for like it's going to take so much more time and we're like man it's already been like it's been six months and you don't have it working you don't have you don't have anything working not even what we asked for but you don't have anything working so we're like this is a problem if it wasn't obvious this is a problem and um we said like we think that this is we think that this is feasible and we think that we can do it and a colleague of mine and I set out to go try this out in a short order we basically had a working prototype we had it working so the example was that we could take a mobile phone so an Android phone I could take a phone and plug it into a computer and bite for bite I could extract every single bite from your phone and have it on the computer and we had a working prototype as we were taking off in an airplane and we did our first our very first mobile acquisition in an in-house built product taking off in an airplane so it was technically feasible and we proved it and we had gone back and we kind of explained our demo and we said we think this is absolutely something that we can continue to build and if we build it with the expertise that we have we're confident that we can have a successful product because we have sort of the in-house knowledge to keep doing this and we can iterate on this and they said okay let's give it a shot and that's where um I ended up forming a team around this and every single step of the way was essentially things that looked like they were technically infeasible so we had to do things like using uh known and some times lesser known exploits on Android devices to be able to do full bite forbite images we had to do you know passcode bypassing again for what it's worth we're not hacking this is meant for law enforcement government forensic investigations a lot of the time just for the record for people that get uncomfortable with this stuff um we were trying to help people solve crimes that involved pedophilia so we were helping to rescue children so if you're like hey it seems kind of sketchy that you're going through people's phones first of all not us second of all it's law enforcement third of all it's to help save children that's why we're doing it so um for us it was nonstop is this something that can be done we don't know but we have to try we're not going to sit here and say can't be done push it out we're saying we're going to try and we did this Non-Stop and I want to go back to saying that we had really good working relationships with our product owners to be able to tell them look we're working on this thing we're actually not sure if we're making progress like we don't it's been it's been a week it's been two weeks we're not sure do you want us to Pivot to something else that you have in mind or do you want us to keep trying because we will keep trying we will keep doing it and I would be lying if I said that some of these advancements didn't take half a year we're not going to go into it saying oh it's gonna take half a year like that's why we shouldn't do it we said we're going to find a way and sometimes it took that long sometimes we would get a couple months in and say we got to pull the rip cord on this we can't do it but we tried and what would happen is we'd revisit something later and all the learning that happened carried over into being able to have a successful product or some other feature Tik Tok always likes kicking me off they're like oh you're Idol like I'm absolutely not Idol talking to a camera I can see the audio being recorded um so I think for us it was always that framing of we we don't know if we can get it done but we're damn well going to try and more often than not we were successful again maybe not with the full 100% thing that we predicted in the beginning that was being asked for but um but we would be successful and I I genu genely think that if you invert that culture and and you go into your your meetings whether it's a scrum meeting some planning meeting or anything else and you have Engineers telling product owners it's not going to get done because it's too complicated it's going to take a year it's going to take whatever you like the reality is the engineers might be right about that it might be but I think it's more important to have a conversation not about tell me all the reasons why it can't be done change the conversation tell me what you can do and give a constraint so this is the last part I want to talk about when I say give a constraint um a section that I wrote in the newsletter because I read this a little bit out of order but a section that I wrote is titled constraints breed creativity and I didn't coin this and I'm not the only person to talk about it but I like talking about it because I think it's important and it's this idea that consider and I think some people resonate with this if you've ever worked on what we call like a green field project so you're at work or a hobby project whatever it happens to be and someone's like we need to build this thing that does X and you're starting from scratch you can pick any technology you want you can pick your favorite language your favorite database your favorite everything you pick your best friend to go work on it with you you have a green field project and all that we know is we need to accomplish X how much time is it going to take I don't know just get it done you know just go build that kind of thing you can be creative for sure because you get to pick all these things but in that example I was trying to like articulate there's no constraints you have one goal and I didn't constrain the technology choices the programming language who you're working with the time frame anything you just have some goal go build a thing that does whatever and I think that this might sound a little extreme but I think that's like the I don't want to say the laziest but I think that's like the least creative type of like software development that we can do it sounds kind of backwards because you might say well Nick like you can literally pick anything you want and get creative I'm like yeah I get it but like you don't have constraints and I think that for some people people get frustrated when they have to work in Legacy code and stuff and it's because it's hard because you have constraints you literally have to start making engineering decisions you have to say yeah I know the best pattern to use here would be to switch everything over to pendency injection and we could refactor this and write all the tests but guess what you have a time constraint and you're not going to be able to do all that you can't freeze the code base for 200 other Developers to just say oh let me go clean this up don't worry let me just clean it up don't deliver any features it's going to take me two months there's no constraints you don't get to do that it's just not real so it's hard because it's made by idiots hey man I'm one of those idiots that built that Legacy code but I think the the point here is like when you have constraints put in place you get creative so when I was talking earlier about hey look like we don't know if we can do it but we're going to show you everything that we can do we would come back to constraints and we would say things like what do you need by when well we want this feature we want it in by the end of the month and we're like okay like can we do that like we don't know but like within a week we can tell you like how how confident we feel or where we can get to right and we would just constantly have these conversations so the idea was like if you're not constraining things then you're not going to end up solving them in creative ways and I think that that needs to come up more in our software engineering conversations because when you have product owners or or whatever it looks like where you're working and you have people asking for functionality for features for bug fixes um if there are no constraints then you will of course have Engineers coming back and saying well push the timeout push it out cuz because you're not constraining it any other way it's an interesting exercise and I encourage you to try it not not saying it's the right thing to do but to try it instead when that's happening so if you're working in a group and people are predicting it's going to take us like six months to do it literally try this say what could you do in two weeks you don't have six months you have two weeks what can you do and you'll have people going oh it's impossible we literally can't do it it's impossible can't be done but like that's in this exercise that's not an option you have two weeks you have a twoe time period what can you do and try to see if people get creative because sometimes what happens is when we have these constraints in place people are saying yes in the current Paradigm that we have it is impossible and like I said earlier they might be 100% right in the current Paradigm it is impossible to do what if you change that what if you start thinking outside of the box so one of the things that had um been on my mind recently is um and I'm not going to share the example from work I'll share an earlier one also from work uh that I lived through that was pretty interesting and was successful for this very reason uh and then I'm going to kind of wrap up so as I'm wrapping this up by the way if you have other questions and stuff you want to ask please let me know I am watching the chat happy to answer anything that's coming up but this last example I want to give is on the previous team I was on that was for deployment we had um so we do uh okrs at work so objectives and key results and if you're not familiar with this kind of thing okrs are this idea where a key result itself is something that has like a quantitative outcome so you can say like we improved something to go from X to Y it's a measurable thing with like like goal post right you move something from X to Y it has a scale right so if you didn't get all the way to Y but you got like halfway between X and Y then you were 50% to your goal so okrs are are measured and designed this way there's more to it high level we had a key result that was about driving um some metrics that we had in deployment what they are doesn't really matter and when we were doing the planning uh my my manager at the time and I'm new to the team by the way at this point my manager at the time had said I want this to be the goal and I said okay like I have like I'm going to go back and talk to the team about this but like there's other key results I'm going through them with him and when I presented that one to the team so we could work through and see what that was like I had one person on the team that was like that's impossible it's it's simply impossible and they had a lot of experience and they they know from their experience they had already tried to optimize this stuff they said we already came a long way already come a long way and here's how far we got and now you want us to go that much further they said it's going to be impossible but they said okay like the thing is in with this individual they they weren't um they were trying to help me they were trying to be like look like I know you're new here so like let me tell you this is going going to be impossible but they weren't trying to like stop the team they weren't trying to say like no screw you the team can't do this they were just trying to say look man like we've already done a lot of this and to to stretch that much more like I'm telling you it's not going to be doable but we set out and we had to go set up a lot more observability to go make sure that we could go see things properly to measure different scales of things and sure enough over time we chipped away at things and we achieved that goal and and I wanted to share this one because if we would have just taken that initial feedback it can't be done and we say okay I guess we have to Pivot to something else we wouldn't have achieved it in this particular case what we didn't do was we didn't necessarily change the entire Paradigm we didn't say okay like if we rearchitecturing that maybe would work but what we did in practice for this example was that we just incrementally chipped away at it and the more observability we put in place the more insights we had like hey look this this is for um for performance optimization Just For What It's Worth um that's the detail I'll give so we were finding these spots where we were like hey look like that's actually way slower than it should be but we didn't have the observability so we didn't have like a paradigm shift but we actually chipped away at it and achieve the goal now if that came up one more time and someone said reduce it by another 50% or something then I might be skeptical at that point but the point is that we went into it being like we actually had talked with leadership and said that's going to be a stretch it's going to be a stretch for us to do and they said that's okay because we want you to try okay and the team knew the team knew that if they didn't achieve the goal it's not like we were going to lose our jobs but that's our goal and we're going to try to figure out as a team how we get there and we did we measured and we incrementally chipped away at it all the engineers worked on it it was awesome so again I just want to share with you that my My Philosophy here that I think can really help is like number one constraints can be your friend because you can get creative and number two try to frame things as more of like what can we do versus all the ways that it will not work and I think if you try those things out give them a spin I think you might see some some cool cultural shifts where you're working so that's it end of story but uh yeah uh if people do have questions please let me know happy to try and answer them at the end here um I am going to check to see if there's anything else I wanted to share I don't think so um I mentioned code commute which is the the uh the Vlog I do when I'm driving to and from the office um one of the things I talk about on code commute a bunch is even stuff outside of work for me so I'm just going to switch this back over um I work on uh the SAS I'm building called brand ghost so brand ghost is what I use for posting to social media um I have been using the back end of this service for a long time now because if you see me on social media and what I'm posting and stuff like that it's done through brand ghost and now we're putting a front end on um a front end on it and then other people if you want to get into content creation if you have a small business and you want to be able to to post content more effectively uh brand ghost is what I am building so on code commute you'll hear me talk about this a lot that's why I was saying you'll hear more of the entrepreneurial like startup side of things on that Vlog because it's also top of mind for me so that is brand ghost um joy in the chat um how long have you been doing this which part in particular um let me know what you mean by like by this because I can answer your question more effectively uh as you are writing back the more specific thing you're interested in I have been uh programming for over 21 years I have been in industry for uh for 14 years I have been managing software engineering teams for 12 years um eight of those were managing within a startup and four of those at Microsoft for big Tech um yeah I don't know uh if you want any more details content creation uh just under two years now the live streams in particular I started at the beginning of this year so those are a bunch of times cool um I am doing one more pass over the chat I don't see anything else folks um please if you still are in chat or if you're watching the recorded version of this let me know in the chat um I know some people responded to the the poll and the survey I did for times but um let me know if this time worked well for you uh I think it's a very sustainable thing for me to do it at 700 p.m. PST instead of 900 p.m. so if it worked that's great um if not let me know I'll try to see if I can adjust if there's a majority and the last thing I I mentioned at the beginning of the stream but there's way more people on now I am going to be streaming tomorrow morning so that's 7 a.m. PST let me just put the link in the chat actually um so let me find it because then I can just put a link to the next stream so I'm going to be migrating it's not going to happen all in one stream but I'm going to be migrating my my WordPress blog into um a Blazer blog engine so I'll be starting that at 7 a.m. tomorrow um Buran I'm planning to start working on BPO I want to help my team beond that standard any advice on it um BP what is Bo I don't know the acronym business process Outsourcing um no this is interesting I'm not I guess I don't necessarily want to force you to kind of share like what processes but are you able to share which processes in particular um like which process you you plan to Outsource because that might kind of change my perspective on it um I have I don't have a ton of experience with uh Outsourcing business trying to think I've seen I've had experience that did not go well with Outsourcing a project where the entire project was managed uh externally so the development was all external and and then I think what was supposed to happen and why it failed pretty miserably was that um I don't think there was a project manager on their side and I think that we had a project manager that was not informed they were supposed to be managing the project so as you might expect that led to a big discrepancy um so I have not seen that work well in my experience um trying to think there's other I think it really depends on on what the business process is that you're trying to Outsource and I would suspect that if it's not a strength that you're your current team has or your business has could be a great opportunity but anything that's not in house I want to even if it isn't house like communication is going going to be so important and making sure that everyone's on the same page so if you're taking a critical process to your business and taking it outside like just think about the impact of that right so I want to give you another example um because I was talking about brand ghost and stuff if social media as a as a business process and someone doing marketing and social media presence and stuff branding if that's not a core part of your business can that be outsourced sure right but you don't want to be so detached from it that you have no idea what's going on so I think that's an important consideration um I am not an Alex Heros um Guru but one thing that he said that I thought was very interesting and not every business has this luxury but if you think about a business process that you want to Outsource he talks about a sort of an inverse strategy which is like or it it moves to an inverse strategy which is hey look we're going to Outsource this to you but even for we might even if you're willing to we we'll pay you even more money but we want you we want to Shadow you we want to learn from you as you're doing it so again the social media example you might say look social media and branding is not a core part of our business so it makes sense to Outsource it but long term like you will always have that dependency if you never build up the skill set internally so if I can Channel what I understand from Alex Heros effectively his approach was let me Outsource it let me learn everything I possibly can and it comes at a premium but it's worth it you have to go find the right place but then if you learn everything they're doing now you can actually bring that back in house and do it effectively uh not only just effectively because of the cost but you you don't have to translate business domain knowledge to some other group because you can do it all in house like I feel like the way that I would look at this is there's probably an efficiency loss anytime you have to Outsource something okay and when I say efficiency loss I don't mean that like as a result therefore you shouldn't do it but I think anything outsourced will come with some efficiency loss and if that efficiency loss is less impactful than the gain you get from Outsourcing it it makes sense right but if if that efficiency loss is outweighing the gain you're going to get I think that's probably something to look at now how easy is that to measure I don't know and it's going to change from process to process so something to think about um but yeah I hope I hope that helps sorry I don't have like a lot of like anecdotal experience to kind of back all that up but something to to Think Through okay folks I don't see any other questions um just checking again across the chat looks like no um thank you all for for tuning in reminder 7 a.m. PST tomorrow morning we're going to be looking at some net codes so uh I'm excited and also nervous because I get stressed out thinking about my blog and having to migrate stuff like it feels like it's like worse than moving houses like no one likes doing that but it's got to happen so thanks again I appreciate all of your support and I will