Making Technology Choices Kevin: [00:00:00] Hello and welcome back to the It Depends podcast. I, as always am your host, Kevin Goldsmith. I'm delighted to be back with you. You heard me in the weeks leading up to it, talking about, speaking at lead dev. I ended up speaking at both lead Dev and leading ENG in New York. This year is a great experience. If you haven't been to those conferences. They do an excellent job of curating them and I highly recommend you go. There should be recordings for my leading dev talk, hopefully posted soon. I actually recorded a rehearsal of it, so I will post that, at some point. It's a nice. Contrast to see how I rehearse a talk and then how I actually give a talk. If you're interested in public speaking, there's the way I rehearse it and then there's the way I actually end up giving it and you'll hear how much it actually changes on the day . One thing that was interesting about both leading ENG and Lead Dev, but not that surprising given how [00:01:00] many conference agendas I've seen that really have been revolving a lot about around ai. It's not surprising because that is almost all I talk about when I talk to my peers. We are all thinking about it. It's obviously huge in our industry. It is continuing to evolve. It's changing rapidly. We are feeling, those of us in the exec team, we're feeling a lot of pressure from our CEOs, from the board to be active and to plan actively and incorporate this new technology into our strategy. I haven't talked about it on this podcast for a few reasons. One. It is being talked about in lots of places right now, I'm not a hundred percent sure what value I would add to the discussion. Like most of my peers, like most of you, I'm learning about it. I'm continuing to deepen my experience about it. My thoughts [00:02:00] about it continue to evolve the more time I spend in it. I generally don't like talking about stuff. That I don't feel confident. I've sort of have something novel to say about, and usually that comes from my own experience. Like most of you, I'm in the middle of it and I don't like talking about things generally when I'm in the middle of them. I like talking about them when I'm on the other side, and that way I can give the sort of real lessons and their outcome rather than just. Talk about what's happening without knowing how it'll work out. So that's one reason I generally don't like talking about things I'm not on the other side of, but I promise you this is a huge part of my work right now and has been. For the last couple years at least. Certainly been a since these things started to emerge. Been paying a lot of attention to them, but it's very much dominating a lot of my thinking and thinking about how not only our technology stack will evolve, what [00:03:00] new things are possible, but also how the industry is going to evolve, how the work of my team is going to evolve. At some point, I will feel like I have. Enough of a unique position there to maybe devote an entire episode or a blog post about it. The second reason I have not talked about it is, as I said, it is pretty much dominating a lot of my time as a CTO and a lot of my time mentoring other CTOs. And I'm very aware that people at my company listen to this podcast. And the last thing. I want is for any of them to learn something from this podcast that they haven't heard from me already, and that's entirely possible just in how information disseminates. I have had the experience of working for A CEO, who is an active blogger and everybody at the company would read his blog because we'd learned things about the company that he hadn't told us. There's nothing I'm going to tell you that I haven't told some people [00:04:00] at the company, but I'm not sure. I wanna be in a position where people feel like they have to listen to this podcast to learn about their day jobs. 'cause that I can tell you is super awkward. those are the main reasons why I haven't really devoted an episode or a blog post or newsletter to ai, even though it is very dominant in my thinking and has been for a while. Instead, what I wanna talk about today is related. It's not specific to ai, but it's very much related to a new technology. Emerging becomes the darling of the industry. Every company has to decide, do we embrace it, do we wait? How do we want to approach it? And that is just making technology choices either as. An executive technology or engineering leader, or as a dev lead or engineering manager. And seeing something new that's interesting and deciding is this something that would make sense for my company or my [00:05:00] team? Because we do this all the time and this is very common and new technologies are merging all the time. Like we think about ai and when I think about ai, I actually put it as a transformative thing as like when the web came, 'cause I'm old enough that I remember a time before the web, I was working professionally before the web was our thing. Similarly with mobile, how mobile just came in. It was this new thing. A lot of companies weren't sure, but it seemed really transformative. And of course now it's a huge part of what we do. So each of these things comes and for each of these things, there's also the technology that everybody's super excited about and just fizzled out. Web3 being an example back in the day. For those of you who maybe weren't aware, we were talking about a 3D web in the nineties. Not only were we talking about it, but people were trying to build it. I was part of that group trying to build an open [00:06:00] 3D web, a metaverse, and then a couple decades later, oh, we also had the metaverse. Another thing that sort of emerged, didn't really get the traction, and we don't talk about it anymore. There's definitely companies still working on it, but it is not something that's really dominating discussion. So for every web or mobile or ai, and we're not to the point yet where we can definitively say, no, AI is. Transformative forever, but it seems like it will be. But Web3 seemed like it would be, as did the metaverse at one point or another. So for every kind of new technology and you can think of smaller things that are also very pivotal, Kubernetes was a huge change. Public cloud. I remember public cloud. That's another massively transformative technology that companies had to decide, do we adopt or do we not adopt? And that was, if you remember, there's a chapter in the book where [00:07:00] I actually talk about being at Adobe and wanting to, or needing to embrace public cloud because we were starting a new business and we didn't know how it would work, and the traditional way of racking servers in the company's data centers just wasn't set up for the kind of new product launch we were trying to do. So we pushed and were able to launch on public cloud At the time, like this wasn't seen as oh, this is going to be a thing. It really wasn't. It was like, Amazon's doing this weird thing. Maybe it'll work out, maybe it won't. There are both big technologies, smaller technologies. That are absolutely transformative, and we have to decide as leaders, which of these are important, which of these aren't? How long do we wait? Before we decide to play with them or examine them, how long do we wait before we choose to adopt them and incorporate them? How much rework is it gonna take to adopt this [00:08:00] new technology? Is it solving problems we have or is it just a cool thing that developers on the team are excited about and trying to convince us is going to be really transformative and we're not so sure. And then there's the next part of. Some of the team are gonna be very excited to take on this new technology, and some of the team may not be . They have a way of doing things and it works for them. And all of a sudden we're telling them, no, we gotta do it in this new way that you don't understand and you have to learn something new. So you have both really excited developers and really laggard developers and how do you get the whole team to embrace these new technologies? So that's the topic of today's podcast. The challenge we have when a new technology starts to emerge, and this could be, you can think of all these technologies have appeared in the last few years, on the front end, you have React, you have Svelte. These things are now seem like, oh, well these are boring. These were not boring, not that long ago. So the challenge when something new starts emerging, you start to hear about it. You start to see blog posts about it or [00:09:00] podcasts about it. A new technology, let's say like on the front end, like react or spelt or on, the back end go, which now seems really boring but wasn't. Rust is emerging, even though it's been around for a little while. It seems like, oh, this is really old. It's really not. These technologies emerge and you have to decide, do we care about them? Is this important? Should we be paying attention to them? That's your job as a engineering leader or as an architect, as a leader on the individual contributor side or a leader on the management side. We do have to have our antennas up. We do have to be paying attention always to what's going on in the industry. It is very easy to miss out on these things, and it doesn't mean you have to be on the leading edge of everything, but you need to be aware of them because sometimes these are transformative and they will actually help your team. They will actually help your company, so you don't want to have your blinders on and this is what we do and this is what we've always done. 'cause that's [00:10:00] actually how you end up in a position where you find yourself so far behind a competitor comes outta nowhere leveraging all these new technologies, and you just can't make the shift to catch 'em. And they just start iterating and they go right past you. That happens. There's a business cost to ignoring what's going on in the industry and missing both product and engineering opportunities. So you do have to pay attention, and you do need to be aware. You do need to follow the blogs, you do need to listen to the podcast. You do need to go to conferences and see what the talks are about. So you want that curiosity. You want to be interested, and hopefully you are because this is your job. I'm hoping that all of us listening to this, if you're in technology. Which I'm assuming most of you are, are excited by technology because if you're not, you might be in the wrong job. Just this is what we do and it should be interesting to you, so that isn't [00:11:00] hopefully too much of a undue burden is to be paying attention to what's going on. There's the other side of that, so you wanna be paying attention, you want to be aware. Do you wanna follow? Is this emerging? Is this fading? 'cause sometimes stuff kind of emerges and doesn't quite. Get over the curve where it becomes adopted by a lot of teams and just kind of fades. So it's the new hotness, but it never really makes it, you wanna be paying attention to this stuff, but you of course wanna balance that with some caution because if you jump at every new technology and figure out how to incorporate in your stack beyond just the constant amount of rework, and let's be clear, a lot of these times that technology, sometimes that's enabling all new functionality or new products that you couldn't build before. But a lot of times that technology is just making what you do today, just more efficient. Maybe makes it scale better, maybe saves you some money, maybe it has a slight user advantage, but it's more a technical advantage for your team. And you don't [00:12:00] wanna be jumping at all these, 'cause it just takes some amount of, a huge amount of rework. And then the product team wonders why you're just constantly refactoring and incorporating new technologies and not building any new product. You wanna be careful, but you do wanna be paying attention. What happens though, when that new technology, this new thing, gets to a certain point where it doesn't have to seem inevitable. There's lots of technologies that lots of teams are adopting right now that aren't necessarily inevitable, but they've shown enough value that teams have decided it's worth embracing them when it starts to get to that point where it's not just a, a small crew of avid supporters making lots of noise in blogs or in Reddit, or in Substack or on YouTube or whatever, but you start to hear more about other teams adopting it. Maybe teams at companies, you know, friends of yours at other companies are starting to play with it. That's a really good time where you get, okay, well this is maybe starting to get generally adopted. The reason [00:13:00] why you don't want to just jump on stuff now. There might be an opportunity or there might be a reason to jump on something super early if it's solving a unique problem you have. So I don't wanna say like never embrace early technologies. Sometimes you and your company, you and your teams have a problem and nothing right now. Solves it. There's no easy way to solve it, or you can solve it within your existing frameworks or your existing stack, but it takes a lot of work, or it takes a lot of time and something new comes out that actually solves that problem in a good way. That might be a reason to come in early. There's the other school of thought that says Choose boring technologies. There's a really famous blog post about this. Choose boring technologies because they're tried and tested, they're well documented. There's tons of sample code, there's tons of, articles that people have written that help you use it. There's a lot of arguments to say wait until it's really been adopted by the entire industry and don't touch it before them. [00:14:00] I think that's more important for larger companies. Bigger stacks, more traditional code base where you have a lot of scale and the danger of adopting a new technology disrupting your stack or interfering with things may be a lot higher. I don't necessarily think that's critical for an earlier stage company where you're willing to take on a little bit more risk, but there is still a value in waiting. Until it's relatively safe, until there is some decent documentation where, you know, other companies are using it. If it's an open source technology, you see lots of contributors to it from lots of different places, that starts to tell you no, there's a healthy ecosystem here. If we wait another two years, it might be a much bigger ecosystem, but we know that, if the core contributor drops out, the whole project doesn't die. Or we know that if we have trouble. We can find a consultant that knows it, or we can find somebody else that can help us out, [00:15:00] or, we can contribute to it if we need to adopt a bug fix that's critical to us, or those kinds of things. So you want a healthy ecosystem that you can be part of, but you don't necessarily need to wait until there's conferences just on this technology. So that's where the curiosity. You need that curiosity, but you also need that caution. Another way to find out new technologies is to leverage your team. So just like you should be curious about what's going on and the new things that are happening, your team should be curious as well. And because they also have chosen technology as a career, they should be interested, they should be curious, they should be coming to you. And telling you, Hey, I was reading about this. Could we try this? Or whatever. So leverage your team because also there's nothing a developer likes more than telling their boss or telling their lead or telling the architect about something and hearing from that person, oh yeah, that sounds really interesting. Maybe we should try it. So absolutely leverage your team to [00:16:00] help you find new stuff. It's a great conversation. It's a way to encourage them, especially if you'd end up adopting it. And if you choose not to. It's a great conversation to have with them to help them mature into how to make better technology decisions. These folks on your team, they're technology scouts and there's probably folks, it may not be uniform across your team. You might have a couple really curious, really excited about the latest stuff. People encourage them don't discourage them. I think a lot of times those really eager folks on your team, every week it's something new. Hey, we should try this and we should try this. And you end up having to tell them no a lot, and that can be really discouraging for them. They don't feel like they aren't being heard. Do say yes to 'em. Do give them some opportunities and do encourage them to keep looking even if you can't adopt every new thing that they find because they're great. It's a great resource to have on your team. Another person or another few people that are really paying attention are really looking around for what could be interesting for your [00:17:00] team. Another thing you can do is you can have within your team or within your larger organization, if you're an engineering manager, you can have it within your team. If you're a director within your part of the org or VP or whatever, is having regular sort of round tables or demos where people can. Present on these new technologies. Maybe they've been using it for personal projects outside of work, or maybe they did a blessed prototype with it for work, and they wanna show it. These are great and it also keeps the discussion going. It encourages other people to look for these things and to try them out. Having a Slack channel or an equivalent in your company where people can share stuff that they're reading about or share stuff that they're hearing about and discuss it with their peers is another great way. Again, encourages people to be looking out and paying attention, and also to learn about new things. And, again, we wanna encourage that. We want people to continue to grow technically within our teams. The other part, is if [00:18:00] somebody approaches you and they tell you about something, maybe you've already heard about it or maybe you're interested, give them permission. Go try it. Go build a side project, you, get a day, go build something with this technology. Not for our production, but you wanna put it in one of our other. Environments. Go ahead and like we can look at it or you just wanna run it locally or whatever, and show what you think we can do with it. Give folks that opportunity to do that and that encourages them also to play and to experiment. That experimental culture will, be a value to your team over time. It's a good thing to say, Hey, we are paying attention. We are looking for new things. That is really helpful for people on your team. It gives them a little bit of a sense of autonomy, gives them a little bit of sense of purpose and this is important for them in their happiness on the team. Your team already has the radar. Your job is to just help them tune it and the feedback that you give them could be like, this is why this isn't [00:19:00] necessarily the thing that we need to be looking at right now, but. This over here or this other thing you mentioned last week that is more in line or these are the problems I'm thinking about that we have to solve. If you find something that could maybe help us solve these problems, that might be something we want to try. So, you know, help them and be encouraging. Now, when there is a technology that you want to evaluate, how do you do that? I just gave one example. You encourage somebody on your team that's excited about this technology to go build a proof of concept or a prototype, either locally or in a non-production environment where they can actually demonstrate it and see, is this solving a problem you actually have? Is it solving the right problem? You can see also is it mature enough for your team's scale? If this is something that needs to be called thousands of times a second, how is its performance? How is its memory [00:20:00] usage? If this is something that needs to be called once a second. Okay. Very different kind of question. Is this something that needs to be real time? Is this something that's async? These kinds of questions are the ones you need to answer in retrospect to this new technology to make sure it's actually appropriate for the problems you have today. Think about too, the maintenance implications. A lot of times I see a really cool technology that solves a problem we actually have. The problem is it's not so mature that it's sort of self-operating. And that means that it's gonna require somebody's time to maintain it. There are great technologies that we won't adopt because it's basically gonna be somebody's part-time job just to maintain the infrastructure to support it, or the system itself, and it's just not worth the trade off. So we find other ways to solve that problem, even though this might be the perfect solution for us. I think one of the things to [00:21:00] understand, especially when you're looking at open source systems or open source technologies or frameworks, especially those created by big companies, is that these were created by big companies who have a lot of resources and it's great that they're open sourcing this thing that they actually use and maintain, and that's awesome, but a bigger company also often has the people they need to maintain it and to keep it up to date and to babysit it. And they're not really thinking about how would a company that's, much smaller, how would they adopt this and how would they use it? Because that's not their experience. They're solving a problem for themselves. They're just happy to share this solution to their problem with other companies. So that's really something to pay attention to. There have been technologies, open source technologies that we've adopted at prior companies that ended up taking like a full-time person's effort to just maintain and keep going and like patch when it failed and that kind of [00:22:00] thing. And so we then really had to look at it and say, is this worth the cost? Because the cost is significant. So keep that in mind, especially if you're looking at something that's coming out of a much, much bigger company and they've open sourced it and it's like they're solving their problem. We have the same problem even though we're one 10th or one 50th their size. Make sure that you're aware of like how much effort it's gonna actually be to get it going and to keep it going. Because that oftentimes tends to be a much bigger problem than you might have anticipated, even if it is really solving a problem for you. A great way to do this is to also see what other companies that are equivalent to yours that are similar to you have adopted it. So open source projects especially, or vendors, will very happily rattle off all these companies that are using this technology. How many that would be equivalent to you. Oftentimes with new technologies, you'll see like a whole bunch of early stage startups that are [00:23:00] using it on their site. That's great for them. They are willing to take that risk. But if you're not seeing more mature companies adopted, and you are a more mature company, that should give you pause, right? So early stage companies, they don't have a lot of people. They have a lot of problems to solve. If you're a more mature company a mid stage startup, you probably have solved this problem already. Do you wanna take the risk of adopting a sort of less mature technology to solve a problem slightly better than the solution you currently have? That's an open question. You should be hopefully finding folks at other companies that are. Similar to yours. Building a bit of a network where you can go and ask, Hey, is anybody else using this? We're this size company, we are this old. This is our stack. Yeah. Is there anybody else like us that's using this and what's your experience been? And there's tons of great communities. If you haven't built a network [00:24:00] of peers yourself, you can go look at things like the Rands leadership Slack or. Lots of cities have mailing lists of EMS or whatever, or go to meetups and try and meet some folks that, that are similar to you. I absolutely will ask my peers if there's something we're thinking about adopting, and I'm not quite sure if it's mature enough for us, and I'm not quite sure if it's maybe too mature for us and it's, we're a little too small to adopt it. So I will ask my peers and find out who else is using it and who else has tried it. And oftentimes I will find that some of my peers maybe have tried it and don't use it anymore, or they have tried it and they're still using it. And that's the number one way I decide if maybe we should try it, is I go and see who else do I know that I trust is using it and finding value from it. Once you've decided to try some new technology, some new platform. How do you actually figure out if it's gonna work for you? You don't [00:25:00] want to just throw away part of your stack and just completely adopt it. What you wanna do is start to play with it and play with it in a sandbox and play with it next to your production stuff. You can use sandbox projects, you can use hack weeks, you can build proofs of concepts, maybe it's a very powerful tool. You can use it in just the simplest possible way. Maybe be behind an interface where you can just start to try and use it and see how it works in your stack. Gather feedback and metrics before committing if this is really gonna replace part of your stack, and you're gonna be dependent on it. You wanna really spend some time. If this is a drop in replacement or you can make it look like a drop in replacement by putting a facade around it, ab test it, run this, and your current solution both in production, send half your traffic to one half the traffic to the other, or scale up. Don't just immediately do that, but scale up and see, make sure the results of [00:26:00] those are equivalent. If you can, not every technology lends itself to that, but whenever you can, that is absolutely something to do. Or you can run it in parallel, but just not not taking real traffic. You can fork all your traffic, send it to it, and just see how it works. But you are still running with your existing technology, but what you're seeing is, does this work? So watch the metrics, see how it performs. The more critical it is, the more dependent you're gonna be If you adopt it, the longer you want to do that till you have full confidence and then you can either start to turn up the dial where you send it more and more traffic and make sure it works. Or you can, once you have full confidence, you can make the switch if it really is a one way door. Just avoid premature standardization. Don't rewrite the stack for a trend and let the new tech prove itself. Let's talk about getting your team to adopt it and also working with those [00:27:00] really eager folks on your team that are excited about every new technology and have decided it's the solution that the whole company needs to adopt. 'cause there are plenty of those folks that we work with for those folks that every Monday they come to you and tell you about this personal project they spent the entire weekend doing where they learn this new language or they adopted this new framework or whatever, and they're like, this is the solution to all our problems. We need to do this as soon as possible for those folks, channel their energy into more structured exploration, say. That's awesome. Here's why. That isn't really what we're looking for right now, but here are the problems I'm actually thinking about. Here are the problems I see us having. If you wanna explore new technologies, help me figure those out, right? Go play with those things. Or even, these are some of the technologies I've been wanting to play with. I just haven't any time. If you're looking for something to do on the weekends or something to do for [00:28:00] fun, or we have a hack day or a hack week and you wanna play with. This is what I'd recommend because I think this is potentially gonna solve a problem we have right now that I'm really thinking about. So enlist them, make them part of your sort of exploration team, your scouting team to help you, but to direct them into the stuff that's actually relevant for the problems you're trying to solve. And give them that space to prototype and give them that space to then present it, not just to you, maybe to you first, but if it actually looks good to present it to the whole team. So they also get that benefit of having done that work and they get their kudos of their peers. You might encourage other folks who are. Also maybe interested in these things, but then feel like they could explore you, give them permission, and then you get to enlist them in the same way. So give them that space to prototype and present their findings and make it a reward. Make that experimentation a [00:29:00] reward, not a rebellion, because it can sometimes feel like a rebellion, like you went off and did this thing. I needed you to do your job right? There's important stuff to do, and you're off playing with this stuff that isn't relevant to what we deal with. That's gonna shut people down, and that's gonna make them afraid to try things Instead, you wanna say this is awesome. This other problem is much more important or I can't give you a few days right now because the thing you're working on is really way too important. But maybe once you're finished with this, we can figure out giving you a couple days of team time to, to explore with this. So you want to, you wanna encourage exploration, you wanna encourage curiosity. You don't wanna shut it down, but you wanna guide it and you wanna make sure people understand where can they do that? When is the appropriate time to do that as part of their job, as opposed to whenever they want. So make it a reward. Make [00:30:00] it, you finished this great project, go take a couple days. I know you wanted to play with, go and go see what you can do with it and how it might be useful to us. For the folks on your team that are laggards who are maybe distrustful of new technologies. 'cause we already have a way to do this. Why are we looking at a different way to do this? Acknowledge that fear with them, right? Once you've made a decision, we are going to adopt this new technology. Here's how we're going to adopt it, and we'll talk about having a plan for adoption in a minute. And you start to hear from folks on your team, maybe not directly, maybe indirectly, why are we doing this? This isn't valuable. It's just the new trend, and why are we wasting time on this? We already have a way to do this. Acknowledge that fear. I. Yeah. New tools often mean relearning or taking something you've known how to do for a really long time and telling you, yeah, that's the way you used to do it. We do [00:31:00] it a different way now and that is fearful for a lot of people. Maybe they got to that level, especially for your more senior folks. They got to that senior level for being an expert in a technology. You've just told everyone you're not going to use anymore and wow, is that gonna be scary? For somebody like that who's built a career on it, so acknowledge it, understand it. Pair them with the early adopters. Let them work with those folks who are already into it and are already excited about it, and show them how powerful it can be or how it does solve this problem in a much more elegant or efficient way. Show them the incremental benefits, how it's improving the metrics on the team, not just, the novelty of it. It's this new thing, so we're doing it right. So talk to them about why. Make sure they understand the why. Make sure that you acknowledge their fear. Pair them with the folks who are eagerly adopting this and maybe getting some real benefit from it that they [00:32:00] can demonstrate to these folks who are worried about it. And then also just track like how it's actually improving. And you should be doing that anyway, right? If you're adopting something new, you should be understanding how this is impacting the business or impacting the stack, or impacting your efficiency or your costs or whatever. You can't let your early adopters run wild, but you also can't let your skeptics stall progress. You gotta find that middle road. So how do you adopt it? I already talked about a few ways. How do you actually switch to this new technology or incorporate a new technology into your stack? One important thing is hopefully you have enough telemetry. Hopefully you have enough vision. An understanding of your current system so that as you switch to this new technology or add a new technology into your platform, that you can actually make sure that it is giving some of the benefits that you were expecting from it. So at the beginning of [00:33:00] we've decided we're going to use this new technology, or we're gonna use this new vendor, or we're gonna do this in a different way than we've done it before. You should have a hypothesis. What is this going to do for the company? Or what is it going to do for the team? Is it gonna make development faster? Is it gonna make the platform cheaper to run? Is it gonna make your platform more scalable 'cause you are having scaling problems? All these things are important. All these things are valuable, and you should have a way to measure them before you start this adoption. And be aware, any change like this is gonna follow that Kübler- Ross change curve. 'Cause it's gonna take a little while to adopt. It's a new technology. People aren't gonna understand it immediately. They may have a way to do something and all of a sudden that way doesn't work anymore and they haven't figured out the new way and it's gonna seem worse and everybody's gonna hate it. But if you continue to persevere, you'll start to gain the value. So just be aware of that. Kübler-Ross change curve. If you haven't heard of [00:34:00] it, you should look it up. Elizabeth Kübler-Ross. It's understanding how people incorporate change and how people handle change. It's a well established thing and having led through lots of different kinds of changes, both cultural changes and technology changes, it has held very true to my own experience. So check that out. Worth looking at. Maybe I'll talk about it in another episode. In any case, Having those metrics and having that be your ground truth and then deciding. If you're not meeting the benefits you were expecting in your hypothesis, how long you're willing to persevere. And you should try and persevere longer than you think you should because of that change curve. 'cause things are worse. And then as people adjust to this new way of doing things, you'll start to see the improvement. While they're adjusting, it gets really easy to give up. And just go back to whatever you were doing before. So you have to decide how long you're willing to continue to [00:35:00] persevere, even if it's not quite meeting your expectations. And you should expect that to be longer than you think you need because of this reason. And that'll be helpful to communicate to your team how much longer you're gonna do that. Because if people are starting to get frustrated 'cause they're still learning how to use this new technology. And they're, wondering, why are we still doing this? You want to be able to have the conversation, we're gonna try this for this much longer, or we're starting to see some benefit from it. I want to give it more time, but also be frank with them if we don't see the benefit we were hoping for. Yeah, we, I'm not gonna force us to keep on this path. If we don't get the value we were hoping for, we will go back to the old way of doing it. People need to hear that so that they don't think you're just forcing them to do something that clearly isn't working because at first it, it may not, if you're lucky, the benefit is obvious immediately and then it's a lot easier. But oftentimes it isn't, again, people have a way of [00:36:00] doing things, especially if you're replacing a way of doing something with a new way. So put it behind a feature flag. Do a progressive rollout. Compare the results. Compare them against what you were hoping for your hypothesis. If you see this new technology achieving the goals that you were hoping for, declare that a win. Make that public, make that visible. Congratulate if there was an earlier adopter or champion of this technology that raised it for the team. Congratulate them. Make sure people understand 'cause that will also encourage them if they are interested or if they wanna play with stuff You wanna encourage that experimentation. So yeah, and then celebrate that win and if it doesn't give you the value you were hoping for. Remove it and celebrate that win as well. Hey, we thought this would be helpful. Turned out it wasn't. We're not using anymore. We tried. It was great that [00:37:00] we tried. Let's all be happy that we're not afraid to try something new, and if it doesn't work, we're not afraid to not do it. People will appreciate that as well. At the end of the project, where you've either adopted the new technology or you've tried it and removed it, have a retrospective talk about how the adoption went, talk about how the exploration went, talk about the things you learned in the process to help you the next time is super important to do that. So you are constantly learning. You're not just experimenting, but you're learning. Make technology choices part of your organizational system, not a one-off decision. Encourage shared ownership of tech direction, right? You, if you're a CTO, you own tech strategy. If you're an em, you own some of it for your team, but if it's only you. You're not gonna do as well as incorporating your team and having them participate and having them contribute. The technical direction is a shared [00:38:00] goal for your entire organization. You might be the arbiter for your team or your division or the company, but if it's only you making decisions, you're not gonna make the best decisions. Leverage all these really smart people you've hired. And encourage a shared ownership of that technical direction. And as I said, those retrospects is really valuable. Document the learnings from both wins and failed experiments and celebrate both curiosity and discernment. Equally, somebody tried a technology and said, this is a really cool technology. I'm gonna use this for all my personal projects, but it's not the right technology for the company. That's a win. And that's something also to celebrate. Just a few final thoughts. The best technology decisions aren't about what's new, they're about what's right for your context, what's right for your business, what's right for your company. It may be 50 billion other companies are adopting it, but if it's not right for you and your company, then it's not right. You don't have to do it just 'cause everyone [00:39:00] else is. The framework I talked about today in, in sort of a very informal way, was discover, find out about new technologies. Experiment with them, evaluate them, and then adopt. Very deliberately have a hypothesis. Test your hypothesis if you're hypothesis is proved, adopt. If your hypothesis is not approved, remove, and then in both cases, learn. I would love to hear from you, what's one technology your team's been adopting and what would it look like to test safely before making that decision? Send those things to me. You can email me at contact at, it depends book.net. You can also contact me on social networks, all the links to the places I most frequent. Are off my website, kevin goldsmith.com. You can contact me through one of those places, but pretty much my name on most social networks, if not all of them. Although almost all of them definitely. [00:40:00] So you can reach me that way as well. Also on the substack, kevin goldsmith.substack.com. You can send me messages there too. Can also subscribe to the newsletter there. One other announcement. If you are in Canada or like going to Canada in the winter, I will be speaking at the ConFoo conference in Montreal in February. Would absolutely love to see you there. That's a conference I really, really like. I really like the organizers. I like the way they approach it. They put together a great conference. I have spoken at it before, but I haven't spoken at it in person. Because the only time I've spoken at it was during COVID, so I spoke over video. So I'm really looking forward to actually speaking in person there. And if you're up in Montreal in February, I'm excited to meet you, so I will see you next week in the newsletter. I'll see you back here in two weeks on the podcast. Have a great week.