Kevin Yank shares the challenges Culture Amp faced when scaling Elm & React with a Design System team in the middle, and how an acquisition tipped the ultimate decision to move Elm from “adopt” to “contain” at the company. Oh yeah, and there’s a new host, Jared M. Smith...stay tuned for more episodes!
Kevin Yank shares the challenges Culture Amp faced when scaling Elm & React with a Design System team in the middle, and how an acquisition tipped the ultimate decision to move Elm from “adopt” to “contain” at the company.
Oh yeah, and there’s a new host, Jared M. Smith...stay tuned for more episodes!
Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.
Music by Jesse Moore.
Recording date: 2023.04.06 (07 on Kevin’s side of the world.)
00:01:03 Some of Kevin’s contributions to Elm
00:01:45 History of Elm at Culture Amp
00:04:49 "Why didn’t you just…"
00:05:54 The exciting challenge: styling Elm
00:10:50 Sharing a design system
00:13:48 Design System team challenges
00:16:30 Acquiring a large React codebase
00:17:24 Upgrading to Elm 0.19
00:19:24 Momentum before the acquisition
00:24:12 Communicating the decision to “contain” Elm
00:32:43 An alternative reality with Elm for Culture Amp
00:42:26 How Elm changed the way that the teams at Culture Amp work
00:44:34 Elm as a secret weapon for recruitment
00:48:00 “Why didn’t you just use web components?”
00:49:25 Kevin's blog post
00:55:56 Success, or how never adopting Elm at Culture Amp would be worse
00:59:34 Take responsibility for user experiences
01:00:23 Reminiscing on past episodes
01:06:15 Elm Radio rocks!
01:08:10 Thanks
[00:00:00] Jared: Hey folks. Welcome back to Elm Town. I'm your host Jared M. Smith. You may be wondering what happened to your host, Kevin Yank. Well, that's who we'll be visiting with today, talking about the decision to retire Elm at Culture Amp. But first, let's talk about our sponsor. Logistically is the company where I work at Logistically.
[00:00:28] We make transportation management software for third party logistics companies and shippers. I'm grateful that Logistically pays me to spend a bit of my time recording Elm Town episodes, as well as pays for our recurring production and hosting costs. We build the front end for all new features in Elm.
[00:00:44] We have over 100,000 lines of Elm code in production. We're always eager to talk to folks who enjoy writing Elm. Please drop us a line, Elm Town Logistically inc.com. I'll put a link in the show notes now. Kevin Yank. Kevin has contributed several things to the Elm community. He has, uh, recorded several videos, developer Happiness on the Front end with Elm Elm in production surprises in pain points, Elm at Scale, more surprises, more pain points.
[00:01:17] He helped organize the Elm Melbourne Meetup, built the Culture Amp, LM CSS modules, loader package. And of course, if you are familiar with Elm Town, he hosted it for two years, from mid 2018 to mid 2020. Episode 33 to episode 53. Aloha, Kevin.
[00:01:37] Kevin: Hello. Nice to meet you, Jared.
[00:01:39] Jared: Nice to meet you, Kevin. I wondered if it would be okay to give a brief recap of how Elm came to be in your life and at Culture Amp. Of course, there are a couple of episodes we'll point people to two from. For more details such as Elm, Town 10, about being in production, and Elm Town, episode 14, spotlight on Kevin Yank.
[00:02:01] But if you could maybe just give a brief review.
[00:02:05] Kevin: Yeah, of course. Back in 2016, culture app was roughly a year into using React. And at that stage, react had successfully powered some features, but was starting to show the problems of scale. Once, once React gets to a certain size, you have some new problems to solve.
[00:02:26] You have to come up with some patterns in your code base. There are things that start to creak at a, uh, one year in sort of size in, in almost any language, in almost any code base. You have to figure out how are you gonna do. Big. And, uh, we had just hired, uh, a new developer on the team that I was leading at CultureAmp.
[00:02:44] That team was about to set off on the adventure of building culture a's second product, which was the Culture Amp Individual Effectiveness Tool. Uh, for those who, uh, know these sorts of things. This was a 360 survey tool that helped you as an individual, get feedback for your, for your development from your peers, your manager, your direct reports, and help you decide what to focus on next for your growth.
[00:03:09] And this whole product was going to be built by a team that I had just formed. We had just hired, uh, an exciting new engineer into that team. His name was Marco Matos. He no longer works at Tremp, but he only recently left. And, uh, he's still a good friend. And at the time Marco said, look, this is gonna sound crazy, but I've been playing with this language called Elm.
[00:03:33] Is there any chance we would even consider using it here at CultureAmp? Um, and long story short, I've told this story on the podcast before. Uh, I, I'll be interested if the version I told today was very different from the version I told back then. But, uh, but long story short, he did enough internal advocacy, enough kind of lunch and learn sessions that I got.
[00:03:57] Just curious enough about Elm that I agreed to try to. One small screen with it, if he, in return, agreed to try and write one small screen with React, which he had never used before. And I was sure he was going to be convinced that React was good enough and that we should go with it. But it turns out I was convinced that Elm was exciting enough that we should give it a, a bigger shot.
[00:04:21] And, uh, yeah, we spent, we spent, uh, a, a good number of years after that, uh, building, uh, stuff with Elm, including, uh, beginning with that first, uh, major new product, uh, culture of Effectiveness, which even today in Ru in production is still 100% written in Elm. Um,
[00:04:41] Jared: Before we get into it again, one, one thing I want to uh, mention is folks who are listening in, uh,
[00:04:47] you might wanna say, why didn't you just. And insert whatever thing you're thinking there. Um, but please withhold your judgment. Uh, I do recommend checking out Evan's talk, uh, "The Hard Parts of Open Source".
[00:05:01] Um, he talks about this a little bit in there. And, um, there's an episode, uh, where Murphy, uh, talks about this, about how Evan Czaplicki, the creator of Elm, has pushed back against the idea of wrapping your identity up in a tool. And even myself, I have to ask, um, when I have a reaction, uh, why is it so strong?
[00:05:22] You know, why, why is this, uh, my meaning tied to this thing?
[00:05:27] Kevin: Even beyond, even beyond judging people for their tooling choices. I've just gotten, ha, I just said it then. I've gotten used to, uh, um, noticing when I use the word just, and most of the time I realize when I've just used that word. Uh, it is, there is a, uh, there is a better way to express myself or I am assuming something that may not be true.
[00:05:54] Jared: Yeah. Yeah. I catch myself doing that too what were the challenges that you faced, using Elm at culture?
[00:06:02] Kevin: Oh well the challenges at first were exciting ones. They were how are we gonna make this work for us? Sort of challenges. And, uh, they led to, um, solutions like the Elm CSS modules loader that, uh, that you mentioned there. So that first, that first challenge that we were up against, like we had started to build a feature with, with, uh, Elm.
[00:06:27] And the question as many face when they enter Elm is, how do I style my ui? It, it is often, that is often the first surprise for people that, um, Elm with so many batteries included, does not include outta the box an opinionated approach to CSS or to styling. There are obviously, um, a couple of great solutions in the community.
[00:06:52] There's, uh, Richard Feldman's, Elm, c s s, there's the Elm I that, that a lot of people really love. At the time, Elm, I was either, uh, not out at all yet, or it was still getting started. So LM c s s was the, the way to write it. But, um, although I think I was. Me and, and the team was ready to embrace and were excited by writing, replacing JavaScript with an ML based language, uh, that had a great compiler around it.
[00:07:22] I don't think we were quite ready to replace CSS with that same language, uh, which is what Elm c s s, uh, invites you to do. We were still quite happy with CSS modules, which let you. One CSS file per component. It generates class N IDs that are scoped to that single component so that they won't step on each other or interfere with each other across those component boundaries.
[00:07:47] And you could write it all with sas with a nice kind of layer of extra syntactic sugar. On top of the basic capabilities of css, uh, sitting here in 2023, I would say most people don't need that layer anymore. CSS has gotten a lot more capable out of the box and post-process are doing a lot of the same thing for less of a performance penalty.
[00:08:07] But back then we really loved our sas. We really loved our CSS modules. We were, uh, increasingly basing shared componentry. And we didn't want to give that up. So, uh, initially we would pass all of the CSS class names for an entire app in as flags at startup to, to an Elm app at Culture Amp. And we knew that was working, but it wasn't fun.
[00:08:37] And any, any you wanted to add a new style to an L map, you added had to add a new flag to the top level L module. You had to, uh, write some JavaScript to pass that flag into the L map at startup, it was, it was like a cascade of, of, um, changes that needed to be made every time you wanted to add one more class name to an L map.
[00:08:59] Uh, and so I spent some time hacking on a sweet solution, as they say, which, uh, It was a post-process for the output of the Elm compiler where it would detect, um, effectively CSS class names in the JavaScript source code that came out of Elm and replace them with the equivalent, uh, class names from our CSS modules.
[00:09:24] Uh, it was a Babel transform. Uh, and, uh, once we got it working, it worked great. It was one of the, the, one of the things that Elm will always fight you on is injecting something, um, deep inside your app out of nowhere, like Elm a's very strict, like any functional programming language that everything needs to be passed down without side effects.
[00:09:47] And effectively we wanted a side effect of class names to come in, uh, deeply nested inside of our Elm maps. So that was the, the first real challenge we had with it. And we got over the hump. I think I was a little worried by how hacky it was, but uh, and certainly even back then, the advice was, don't depend on the output of the compiler, cuz the compiler output may change, but it seemed just robust enough and it, as it turns out, Elm is stable enough that you can go multiple years, uh, coupled to the output of the compiler and not, not be disrupted too badly.
[00:10:27] So that worked really well. And, and that was really early on. It was our one biggest concern about Elm and when we solved it, it gave me a lot of confidence that we could do anything. Uh, and, and from there we spent several years in, in Elm Town, as they say, uh, as happy residents of Elm, Town building, UIs and product. Later on, we had some, some challenges that led to this story that we're here to talk about today, about our choice to move away from Elm and I I could talk about some of those more recent
[00:11:00] Jared: Yeah, let's get.
[00:11:02] Kevin: Yeah. So the, the c s s modules set up that I was just talking about. What one of the things that enabled us to do was to share design system components between our React source code, some of which was leftover from before Elm, some of which was still being written by some teams that had not yet adopted Elm or were carrying for it forward.
[00:11:29] Large code bases written in React. They, they needed their design system components to be consumable and react and our. Uh, Elm teams increasing in number and code base, increasing in size needed to consume those same design system components. In Elm, we needed one Culture Amp button with the exact same look and feel, regardless of whether the UI was written in React or Elm.
[00:11:54] And our early, our early success with CSS modules enabled us to build components around that solution. We would build a, a two-headed component, as we, uh, said, uh, where that had a implementation in JavaScript or eventually type script. With React and a parallel implementation in Elm, and we replicated the HTML output and the, the view logic of these components.
[00:12:21] And then the thing that held those two components together was the CSS module. The theory was that if both of these implementations ultimately consumed the same style sheet, that that style sheet would, would kind of hold them in lockstep. That if we added a feature or made a change to the style sheet, it would force an engineer to follow through and make the same change to the other implementation.
[00:12:44] And early on, when our Elm teams had recently been React teams, That worked really well. Uh, it, it Elm, uh, Elm engineers in had done react recently enough that they could backport their Elm changes to react. And our React teams were excited enough about the, the novel new thing that was Elm that they wouldn't mind figuring out how to port their React, uh, changes to a design system component into Elm, but that only lasted so long.
[00:13:19] Over time, the teams that were writing Elm wrote more and more Elm and just as the, the advertised, uh, experience, uh, is we had it happen at CultureAmp that eventually Elm filled the Viewport and those teams stopped actively writing React and their React skills, their JavaScript skills started getting rusty.
[00:13:41] And the, the longer that went on, the more they felt like, well, I, I've made this change to a design system component. I, I'm not that confident making the same change to the React component. Can I get some help from the design system team to do that? Uh, And, uh, that design system team was a small group of, at times, like as few as two engineers, uh, who increasingly were seeing their backlog filled with changes to design system components either on the react side or on the Elm side that needed to be reported to the other side.
[00:14:17] That design system team was becoming a bottleneck and they were the one team that was expected to be bilingual and, uh, to port anyone's changes at a growing company with more and more teams working in this design system. It just was not, um, going to scale. The team was starting to drown in that type of work, and they were asking the question, uh, can we solve it?
[00:14:43] Somehow at the same time, react kind of got better. Uh, certainly with, uh, the addition of type script to the mix type script. I think, um, from things like Elm. I think one of the things Evan has said about Elm over the years is that if he did nothing else but raise the bar for what good error messages are from a compiler, he would, he would feel proud of that, uh, achievement.
[00:15:12] And certainly you, you see that influence in the TypeScript compiler during this period. It went from completely byzantine unreadable error messages to now what I would describe as sometimes comically verbose, but usually pretty readable error messages. Uh, and that and a bunch of other changes to like React went from a class-based framework to very much a function-based framework where most React code, most react components are functions.
[00:15:45] And the best react components are stateless pure functions. And it was a lot of the, the good taste of Elm or the good habits that Elm forces were being adopted as best practices in React land, even though they weren't enforced, they were ways you could work and ways that were recognized as good to work.
[00:16:04] And so the more, the more Elm kind of created this uncomfortable split between the teams that were using it and the teams that were not, and the design system team stuck in the middle. And the better React got as an ecosystem, as a tool chain, the harder it was to continue to tell ourselves that Elm was clearly better. And then the big change happened at CultureAmp, which was we acquired another company, a company with a code base about as large as our existing code base, certainly on the front end at least. And it was entirely react. And so we went from a company that, uh, according to my last conference talk, we were writing about 50 50 in terms of new code.
[00:16:51] About half of it was Elm, about half of it was JavaScript and React overnight. We went to a company that was writing 75% React and JavaScript again, and Elm was now the minority, s the minority type of code at 25%. Um, and if at that moment we had still felt that Elm was clearly better and that everyone was rushing to get onto it at CultureAmp, we might still have persisted with it, but the momentum was not there.
[00:17:23] Um, around that same time, Elm 19 had come out. And I don't think anyone thought the changes to it were unreasonable. There was a long lead up to them. We were told what was coming. The, the, the language has been very stable since then as well. So it was a, a set of changes that were relatively tightly scoped and um, and it was clear how to address them.
[00:17:49] And nevertheless, it took a full year for Culture Amp to port all of its Elm code bases up to Elm 19. And the number of engineers contributing to that effort was relatively small. I could see it in how people chose to use the time that they could do anything with it at called Tramp. And they were not choosing to use it to make Elm healthier in our stack.
[00:18:13] They were excited about other things. So, um, yeah, all of those, you know, sort of challenges at that time. To Elm's continued health in our code base converged, and I was facing the choice as the director of front end engineering for culture app. Do we, do we double down on Elm or do we, uh, make a change?
[00:18:37] And we chose to make a change. I chose to make a change.
[00:18:40] Jared: Yeah, so that's, um, a lot to take in. Let me just think about this for a second. So these, these challenges first, uh, were exciting challenges, like you mentioned, the LM c s s, uh, module loaders, and then. You, you found yourself with a, a sort of a conflict between these two different, um, frameworks where you had a team in the middle.
[00:19:08] You said at one point only two engineers supporting how many, uh, different teams
[00:19:13] Kevin: yeah, it was, it was certainly growing. I would say there were somewhere between six and eight different product teams, and about half of them were working in Elm and half of them were working in React at that
[00:19:23] Jared: Yeah. And so at that point, let's say before you acquired the other company, um, was, did it feel like the momentum was, I mean, were you moving things toward Elm? What was your kind of status there? How was it going before that?
[00:19:41] Kevin: Yeah, it was, it was not that Elm had started to win the race, but it was keeping pace and that is an uncomfortable place to be I think the journey that Elm invites you to go on if you're already using React is write a small rectangle, uh, of your React app in Elm, and then if you like how that went, grow that rectangle, grow that rectangle, eventually it fills the view port and you find yourself writing all Elm from then on. And what, what happened to us, not exactly in these terms, but we got to about 50% of of our view ports full of Elm.
[00:20:18] Uh, and it wasn't that, uh, any given view port was half Elm and half react. It's, it was that half of our view ports became filled with Elm, the other half were still filled with React. And it didn't seem like Elm was gaining speed or gaining momentum. It seems like it had matched react. Uh, and we were gonna find ourselves, you know, if you extrapolate from there and say nothing dramatic changed from then on.
[00:20:47] Uh, that by itself is in an uncomfortable place. We were converging on a steady state where we were maintaining two front end stacks at a small company that, you know, it had 50 engineers at it. That's, by some measures, that's a large group. Uh, but it's, it's having 25 of them working in one stack and 25 of them working in another is a really wasteful way to run a product business.
[00:21:14] And, uh, that, that was kind of what we were facing, I think. We had sat in that state for another six months, I might have said, this is unsustainable. We need to pick one. And maybe we would've picked Elm. But it was also at a time where I felt like Elm, uh, was kind of cooling in its own momentum. We had been through a few years of the rallying cry of let's be mainstream, and a bunch of tooling effort, both from the core team as well as from the community.
[00:21:48] We were, we were seeing projects like the Elm language server come out. We'd seen the intelligent team build an amazing editor integration. Elm UI was fresh on the scene, so there was that period of high activity at, but uh, around this time where we would've been facing that choice, I think we were going into a, a more quiet period where a lot of the attention on Elm was on personal projects and side projects and experiments and games and things like that.
[00:22:17] It felt like I, right or wrong, I feel like I was hearing less about product companies, uh, adopting Elm at scale, and I was seeing less of the work going into Elm, targeting that sort of use case. Uh, and so I feel like while we might have chosen to double down on Elm at the time sitting here in 2023, I'm not sure that would've been the right choice.
[00:22:44] I feel like now, uh, Elm. Is going in a different direction. Even when you look at what, what attracts, uh, Evan and the core team, they're thinking about how can Elm change programming and how can Elm make programming more accessible to people who are learning it so they can learn programming better or have more fun doing it.
[00:23:03] What we're not hearing is how can Elm make more successful product companies, or how can Elm help a team of a hundred engineers communicate with each other really well or share code with each other really well? Um, that that just isn't the focus. And even today as a thousand employee company with, uh, approaching 200 engineers culture app probably could not justify by itself being the only force for that sort of use case in the Elm community.
[00:23:34] So even at, its, at its peak, let's say Elm was on par with React and JavaScript. Uh, it, it had grown faster during that fast growth period when everyone was excited about using Elm for building large products. But it had gotten to a point where React was now keeping pace with it, and we were going to have to make a choice one way or the other.
[00:23:56] Jared: Right. And then this acquisition happens, right? You have the, this, which is a huge tipping point, right? Uh,
[00:24:04] Kevin: Yeah. In some ways it made my decision easy.
[00:24:07] Jared: Yeah. I, I think that, you know, that really makes sense there. And then at, when you made this decision, I really like how you describe the, the communication of it, the, of the status, and, and you want to talk a little bit about.
[00:24:23] Kevin: Yeah, for sure. Uh, culture Amp, uh, for those who have not heard me talk about it before, we we're a, a product company that we build software to hopefully improve the cultures of companies, to make the workplaces of the world better. Places to work is, is what I often say. Uh, but we make tools like engagement surveys and 360 reviews and performance reviews, and we try to bake into the software.
[00:24:50] We write, uh, the right amount of organizational psychology principles to fight things like bias and injustice in the world. Um, which means that we think a lot about company cultures. And as an engineering leader at Culture App, I think a lot about engineering cultures and choosing to drop one half or the other of your front end tooling stack, or even not just drop it on the floor, but declare it.
[00:25:21] The past and our future is going to look different. That is leading from the top a pretty significant cultural change for a group of engineers. Uh, and um, on the one hand, uh, it might sound like I'm patting myself on the back of what a good job I did, but going through it is terrifying. I can say as a, as a technology leader telling a group of engineers that as far as, you know, love a piece of technology, in many cases, chose to interview at your company because you u use that technology, or at least they found out about your company because they came to an Elm meetup and, and CultureAmp was the, the, the one of the companies there saying they were hiring.
[00:26:05] Um, going from that to, okay, so, um, we are choosing to move away from Elm. That is a, a terrifying announcement to make. You are afraid. Um, I mean, Ultimately, you're afraid you're gonna lose some really great engineers. But also like, this is, this is my work family, like the, the front end engineers at Culture Amp, the, the.
[00:26:30] 25 to 30 engineers that were in the front end practice at the time. They are people that I love showing up to work because I get to work with them. And if I was going to do anything to upset the environment, the culture, the, the, uh, the thing that makes them want to come to work, uh, I was very frightened of doing that.
[00:26:53] So the first thing I did was I made a short list of the people that I knew cared about Elm the most at Culture app. I said we were 20, 25 people in the front end practice. Um, at the time, about six of those are people that I knew for a fact, had joined us because of Elm, uh, had helped us with our Elm tooling, had helped other engineers when they got stuck with Elm, had helped us with our Elm 19 migration.
[00:27:18] They were. The Elm advocates internally at CultureAmp. And so I made a list of them and I had a one-on-one meeting. I set aside an hour to talk to each of them and I, going into that conversation, I really wanted to be honest with them. Here's where we're at. I think it might be time to declare Elm. Uh, um, people don't like the word legacy nowadays.
[00:27:44] I think legacy, uh, is intended to be kind as a term, is in intended to express respect for a body of achievement that is now moving into the past. But, um, the, the word we use at CultureAmp is contain, we have a system called the Tech Radar that classifies technologies that we use, have used, have chosen not to use into different categories.
[00:28:08] And our core tools are in the adopt category. We were talking about moving Elm from Adopt to Contain. So going into these one-on-one conversations, I said to them, look, I think it might be time. I'm thinking about moving Elm from Adopt to Contain. I could talk about my reasons for that, but first I just want to hear from you.
[00:28:28] What do you think? And those were great conversations. They felt like some of the most honest conversations I had that year at CultureAmp, which is not to say that we have a lot of dishonest conversations, but you can tell when someone is saying stuff that they've been carrying around for a while and not saying out loud, and that's what these conversations felt like.
[00:28:50] Each of these engineers expressed their love for Elm. The, the fact that they still enjoy using it whenever they get the chance, but at the same time, they acknowledge that cult Tramp did not feel like the, the place to get the most out of Elm to them anymore. It felt to them, they were feeling a little guilty about the fact that we were still using it and it did not necessarily serve the company.
[00:29:19] Compared to alternatives to continue to make that choice. Uh, so yeah, I, I had six great conversations. I went in terrified. I was gonna have six arguments, and what I had was six great conversations that brought me closer to those engineers and made me feel like I was making the right decision. It didn't shock any of them.
[00:29:36] It didn't even necessarily surprise any of them. Uh, and they were all ready to, uh, to support, uh, the decision that had to be. Um, from there, I felt like that was the hard part. The next step was to write something to the, the entire front end practice to help them understand, uh, what we were doing and why.
[00:29:56] So I wrote like a four paragraph thing on our front end practice Slack that said, here's where we're at, here's what I've been thinking. Here's the conversations that I've had. So if any of you are worried that Marcos is going to quit over this, know that I've, I've had the conversation with Marcos and he's on board with it.
[00:30:13] Um, and, uh, and uh, I just said, look, the decision isn't made yet. If, if there's something you think I may be overlooking, uh, come and talk to me. If you're disappointed, even if you can't justify your disappointment, um, come and vent at me. I'm here for that. I, I, I feel it too. So I'm up for any such conversation. And, uh, whether you feel you're right or wrong or justified or unjustified, if you're just having an emotional reaction to the change, I would love to talk to you about it. Um, rather than, uh, have anyone kind of sit on that and bottle it up. And, uh, yeah, it was. It was relatively, you know, a downhill slope from there.
[00:30:57] It was, uh, it was good. In the end, I updated the Elm, uh, entry in our tech radar and, uh, and yeah, I wrote, uh, here, I'll, I'll read it out to you. The new entry it says, was a growing part of Culture Amps front end stack from 2016 to 2020, and was particularly welcome before we had access to type script as a strong and relatively usable type system.
[00:31:22] Since the acquisition of Zha and the large performance UI code base, however, and the maturing of react and type script, we believe that choosing a single language and framework react for new projects is the best path for Culture Amp as it will bias economies of scale within the front end. Practice.
[00:31:39] Code bases written in Elm will continue to need to be maintained and in some cases grown. But when we have a blank slate available to us, Elm is no longer an approved choice.
[00:31:48] Jared: I think that was well put and I really like. Technology status and of adopt, experiment, contain and hold. And, and, uh, and of course, I think for anyone out there who is going through these decisions, whatever it may be, uh, I for one, have, have had to, uh, discuss, we have legacy Angular JS code and, and talk about how we, uh, use that and when to migrate that to Elm.
[00:32:18] And so these terms I've started to adopt at the company, um, just within the past few weeks as, uh, as I've kinda learned, uh, from you about, you know, this with, with other technology. So I think no matter the technology that you are, are going from or to, I think, um, there, there's a lot to be learned here. So, yeah.
[00:32:38] Thank you for, for sharing that. Um, let me ask you, do you think that there was a way for Elm to have succeeded in. Maybe a different, an alternate reality, if you will. Um, where, you know, I think, again, my mind kind of comes to this, this kind of acquisition as a, as a tipping point, but I know you also mentioned, um, this kind of push for elms me mainstream and, and you know, a seemingly, uh, move away from that.
[00:33:13] But is there anything that, you know, in particular that, and I'd say that I asked this question because I think, you know, what you've already said, um, is, is fodder for the Elm community to think about, um, to help us, you know, do a better job of that. I think there are some tools, um, that are available now that weren't in, in those years but I think from your perspective, what do you see as, as those things that are missing those holes, if you will?
[00:33:44] Kevin: Hmm. Um, a lot of the stuff that, that, um, we felt like we had to solve ourselves and that therefore was not necessarily the focus of the community was large code-based stuff. Multiple code-based stuff. Um, I mean, I'll give you an exa an example of the, of, um, a, a sort of. Almost a monorepo pattern, but not exactly.
[00:34:14] Uh, one of call tramps largest front end code bases is where we started using Elm, and it was before we started breaking up our code bases into separate repositories owned by separate teams. Originally, we had a monolith as many small growing companies do, and in that monolith we had different front end apps and we wanted to use Elm to. Multiple front-end apps without having to recompile all of our Elm at once or upgrade all of our Elm to a new dependency at the same time. So in that one repository, at its peak, we had something like 28 different Elm maps. We had 28 directories containing an Elm JSON file that was the root of an Elm map.
[00:35:00] And some of those Elm maps would, uh, would have, would share source directories. So we would have a shared component directory that three different Elm maps that needed the same component would all, um, include that same source directory and that same component. But a lot of these, this code was separate as well.
[00:35:20] And this was one of the things that we discovered early on. No, and this was one of the things that we ran into was the, the Visual Studio Code Elm support package. Uh, was confused by multiple Elm J s O files in a single workspace. It had baked into it an assumption that an Elm project or an that an Elm project contained a single Elm J S O N file and that every Elm file in a directory tree was part of the same build.
[00:35:55] This was an invalid sub. In our case, we had 28 different Elm maps, uh, and. I had, I ended up tracing the, the weird, uh, tooling issues that we were seeing in the editor to this assumption in the source code of colia lamp's, um, marvelous Elm language server. But at the time that Elm language server, I think Colia had just started, uh, like just taking it over from a previous owner.
[00:36:24] He was just starting to work on it. Uh, but I dove into that very, very heady, no js, um, code base and ultimately found the root cause of that, that those issues, we were having that one assumption and did a pretty significant refactor to the Elm language survey in order to support multiple, uh, Elm roots as it were.
[00:36:47] That sort of thing that, uh, it was like a signal to me, not just that I had to fix it, and I resented that I didn't get that work for free from the community. It wasn't that it was the fact that. Everyone else in the Elm community seemed to be happily using the Elm language server and wasn't running into this problem, which told me that our code base looked very different from a typical Elm code base.
[00:37:13] We were doing very different things and increasingly the tools were breaking in ways that were unique to us. Uh, it was a warning sign to me that we were heading off into a space where we were not just part of a small community, but we were increasingly at risk of becoming a community of one. And I think it is one thing to say we are, we are choosing to adopt a niche code.
[00:37:39] We are choosing to adopt a niche programming language or a niche ecosystem because it has some exciting benefits. It's quite another to decide we are going to. Go into a tiny corner and do things in a way that no other company is doing, and any problem that we encounter, we are likely to have to solve it entirely ourselves.
[00:38:02] That felt like a, a poor direction to go in. So to answer your question, could in an alternate universe, Elm, make itself a better tool for companies like Culture Amp? I would say yeah. The things you would need to focus on would be large code bases where multiple teams are working independently of each other and sharing code with each other.
[00:38:25] What are the problems that we can solve in that space? What are, what is the equivalent of compiler driven development and the beautiful error messages that Elm gives us? What are the equivalent to those things that would help teams talk to each other and share code with each other? Um, and, uh, I know things like server side rendering, were often like kind of in the mix as a possible future direction for Elm.
[00:38:54] I, I would say we've had a lot of companies our size tell us, we see what you're doing with Elm, but we could never adopt it until it did server side rendering for this reason or for that reason. Um, fortunately, culture Amp never has needed server side red wing rendering. We're probably going to get it anyway just cuz the React ecosystem is moving to a space where that is table stakes and our tools are gonna give it to us whether we need it or not.
[00:39:22] Um, but I, I certainly heard from a lot of other companies in at Culture Apps scale, in the product space that they felt like they needed their views to be able to render on the server, not just on the client. That would be the other big.
[00:39:36] We had one of, uh, we had one of our engineers, um, most passionate about Elm engineers laid in this process that I was describing of deciding to Sunset Elm. His name's Louie Quin. I quoted him on my blog post about all of this, and he said one of the insights he had is that Elm is very much designed to be your entire front end stack.
[00:39:59] It's the batteries included philosophy and if, if Elm can do everything that you need. Then you're gonna have a good time. But as soon as you are integrating Elm with a bunch of other tools, be that a web pack build that is also building type script and react and, and doing, doing stuff in the CSS side, uh, or whatever else it might be, um, that Elm starts to become an uncomfortable fit because those, that outer layer of Elm is not designed with a lot of integration points.
[00:40:35] It's got port. Uh, to, to integrate with other things at runtime, but ports are, are, um, deliberately limited in order to preserve the guarantees that Elm gives you within your nice bubble of Elm. Uh, and similarly, the tooling around Elm. It, it is simple. It is designed to be a nice experience for a developer, but it does not provide a lot of like APIs or, or integration points for other build tools and other technologies.
[00:41:08] Um, and so according to Louie, like the, the, the reason Elm wasn't working for us is that Elm is designed to work best when it is all you use, uh, and culture app from, from the beginning was that blended environment. Uh, and so I. Uh, something else Elm could be doing if it wanted to serve product companies like CultureAmp rather than what it is choosing to focus on.
[00:41:37] I would say like investigate how it can integrate more into a blended technology, uh, landscape.
[00:41:44] Jared: Right.
[00:41:45] Kevin: But it's a big ask and I'm not sure the stuff that Elma is doing, it's doing great and it would have to take its eye off of those things in order to serve these, uh, goals. And I'm not sure I would advocate for that.
[00:42:00] Jared: Yeah. Yeah, that makes sense. But I mean, again, having these conversations, talking about trade offs and, and where things work and where they, you know, might have rough edges and, and, and working through these things, I think is an important conversation to have. I wanted to ask you, because you mentioned earlier about how Elm has affected tools like React and type script. Has Elm changed the way that the teams at Culture Amp work in programming or in.
[00:42:32] Kevin: Certainly the engineers who got to have the experience of working in Elm carried forward those good habits into React Land Culture Amp has grown a lot, uh, since then, and I'd say more than half the engineers at Culture Amp barely know what Elm is, let alone have touched a line of, of code. I would say, for example, like the teams that now own and, and are responsible for those apps that were built in Elm and are still in Elm, largely the engineers and those teams look at those code bases and as a technical curiosity, they're like, wow. Uh, if ever I need to do something in that code, uh, I'm gonna have to learn a lot that day.
[00:43:14] Uh, because they've, it is completely a foreign language to them. Uh, but certainly for me and for the 25, some engineers, um, many of whom, uh, have moved on to the next thing in their careers, but many of whom are still at Culture Amp, I would say to this day, I will be sitting in front of a piece of type script or react code and going, I know how to solve this because Elm forced me to solve it, uh, this way.
[00:43:40] And I'm glad, I'm glad Elm forced me to learn this way of doing it because it's better than what I would be doing otherwise. Um, Yeah, let's keep this, let's keep this data immutable. Let's keep this function pure. Let's, uh, let's not be afraid to pass data in arguments rather than have it magically come in from the side as a side effect.
[00:44:04] Uh, let's make this code base less magical and more understandable. All of that I owe to Elm. The other thing I owe a lot to Elm is having met, uh, a bunch of engineers who would've never given CultureAmp a second look if we weren't doing something just a little bit weird. Um, this is some advice that I believe Richard Feldman gave to me off air when he came and, uh, recorded an episode of Elm Town with me.
[00:44:31] He, he, he said, um, Elm is a great secret, uh, weapon for recruitment. Because if you're, if you're like every other React JavaScript shop out there, you're gonna have a hard time standing out. The only reason people will come and work for you is if the product you're building is uniquely exciting in some way.
[00:44:54] Uh, it's really hard to stand out as a, as a React JavaScript company, whereas if you are the only game in town for writing functional programming on the front end, that is gonna make you stand out. And for a small company, it will make you stand out enough to keep you, to keep a steady stream of, of good engineers coming your way and, and wanting to work for you.
[00:45:24] And that was definitely true at CultureAmp. Um, many of those engineers are still with us today, even though we are no longer actively choosing Elm for new things. And I owe that to, to Elm, I think without Elm. We might have had a much harder couple of years in, in the recruitment stakes and it's not, I don't want to take for granted that we did so well on recruitment and on growing the team, uh, because I think Elm is behind.
[00:45:53] That may be above everything it did for our code bases and our technology. I think that might have been the biggest gift that Elm gave us was the ability to grow the team quickly because we were doing something interesting with our
[00:46:05] Jared: Yeah, and I think the combination of being. Vocal in the community is an important aspect of that because I, I think you can, you can be using Elm, but if you're not out there talking about using Elm, how will people discover you? Right. Um, posting your job on a standard, you know, website that may not care, you know, what technology you're using, it may not get filtered and found very easily.
[00:46:38] But if you are active in the Elma community, which again, I think this is a, a silver lining for me, is that, uh, I'm able to be more vocal in the community, um, because of this change.
[00:46:50] What is this song lyric? Every new beginning comes from some other beginnings end. Uh,
[00:46:55] Kevin: Yeah,
[00:46:57] Jared: yeah, so I think that's, uh, that's really nice. And of course, um, like I mentioned, the this is a, a great learning opportunity, um, in general, you know, in how to communicate changes and, and picking technologies.
[00:47:09] But, uh, specifically for us in the Elm community to talk about tooling and, and, uh, you know, our approaches and how we communicate. And if you are a big company and you're using Elm or a growing scale and how you use Elm, um, you know, come talk to me. I, uh, would love to be able to understand how you are using Elm and, um, to share that with the community.
[00:47:35] Kevin: Yeah, do come and talk to Jared because it will give me new episodes of Elm Town to listen to. Now, that's one of the nice things about Stepping Down as host is now I can go back to being a fan of the show.
[00:47:46] Jared: Yeah, I love it. Um, and so, yeah, was there anything else that you wanted to talk about?
[00:47:56] Kevin: Um, I think. You were talking about e early on, about, uh, the, the many, why don't you just that, that people in the audience might have and one of the. One of the possibilities we explore that I think people might be wondering about is why don't we just use web components as a, uh, compatibility layer between Elm and the rest of our front end ecosystem?
[00:48:27] Could, for example, our design system components not be written as these two-headed, uh, hydras that have, uh, Elm component and a react component that need to be maintained, uh, in, in, in lockstep, um, by teams that aren't familiar with both of those technologies. Could we instead build a design system with a technology that is designed for that?
[00:48:50] A, a technology like web components that, uh, uh, like the, the sticker on the box is build framework agnostic, uh, UI components that you can use in React and you can use in Elm. And we definitely sort of, as this stuff was coming to its head and I was like, okay. Generally, the teams that are getting to build React are having a good time with React.
[00:49:14] The teams that are building with Elm are having a good time with Elm. The only team that's not having a good time is the team that's stuck in the middle, the design system team. And what if we could, um, solve that with technology? It's, it, the, the hype around web components is that it would solve that problem for you.
[00:49:33] And so we've spent a good six months exploring that as a, as an option. The, the long version of this story is on my blog@kevinyank.com if you wanna read it. The shorter version of this story is that web components is a very low level technology. Um, if you are going to build a component library out of it, you're going to need a framework of some kind around it.
[00:49:57] Um, and we explored a couple of frameworks. We explored a nice one called Stencil that had a, uh, an ex. Uh, expandable, um, output target plugin architecture so we could extend stencil to output Elm wrappers for our web components to provide type safety around their APIs. We did all of that work. We ambitiously attempted to port our most complex design system component, the one that everyone uses our title block that goes at the top of every page.
[00:50:31] We reported it to a web component in Stencil and tried to prove to ourselves that we could consume it in React and in Elm. It barely worked, but it did work. But no one was particularly happy with the API that resulted and crucially stencil and all of the tooling around it was going to add a third.
[00:50:53] Front end stack to the mix. So in a world where we were feeling the pain of having two and that felt like one too many, the solution was gonna be worse than the problem in that it would add yet a third, uh, tool chain and front end stack to a company that was already, you know, struggling to support two of them.
[00:51:12] So that's why we backed away slowly from web components. I do look at them again every six months and go, has it gotten better? Has it gotten simpler? Has it gotten lighter? And I still don't think it's there yet. If I were at a company that already had four front end frameworks and Elm was one of them, and none of them were gonna go away, we were a giant multinational and there were teams in different continents and they each had their own stack that they were never gonna let go of.
[00:51:40] And I had to build a design system for that. I would definitely use web components for that and. It would be painful. Yes, it would be a new tech stack, but there would be no other way to solve that problem. CultureAmp was not quite at that scale. We had two and the choice was go, do we go to from two to three or from two to one.
[00:52:03] And, uh, both were painful changes to make, but one would leave us with a single stack that we, we could all invest in together. And, and that's what broke the tie.
[00:52:12] Jared: Yeah, that makes sense. You could either make it more complex or make it simpler. Hmm.
[00:52:19] Kevin: Yeah,
[00:52:20] Jared: Which of those would I prefer? Probably simpler.
[00:52:23] Kevin: much as I would've nerded out on, you know, not everyone gets to use web components. I'm a fan of using the platform when it comes to the web and, and web components is a great set, like exciting set of technologies that has baked into all our browsers. Now, it would be fun to have an excuse to use it, but, uh, it, it was just not quite the right, right size of solution for us.
[00:52:46] Jared: The way that we've used, uh, custom elements in, in Elm at Logistically is by, uh, using them when we needed something that maybe already had an off the shelf. Solution where we could just kind of pull that in and use it for this one thing. Uh, the case that I'm, that comes to mind is a slippery map, um, where, you know, we needed to incorporate that into the app and, um, this one case it made sense.
[00:53:17] But yeah, if you're trying to, uh, maintain a component library, in that, and then also support its integration with two different frameworks, I think that's a, a completely different story.
[00:53:30] Kevin: I think design systems happen at at least three scales. There's the small scale where you're a small enough company that you can't justify having a dedicated design system team at all. And so a design system happens as a collective col, like a collaboration between the teams that you have. Um, And then there's the medium scale where you're now big enough that you can have a design system team, but it's gotta stay small.
[00:53:56] And, uh, if, if, uh, you find yourself putting as much effort into your design system as your product, you're probably on the wrong track. And that's where Culture Amp was. Um, there's the larger scale of like the, the multinational scenario where like, uh, your design system justifies a business
[00:54:15] Jared: Yeah.
[00:54:16] Kevin: And, and in that world, I think, yeah, definitely taking on the complexity of that, that layer of, of custom, uh, element API around any component and, and accepting that none of your product teams are going to be able to material materially contribute to or maintain your design system, they will be pure consumers of it.
[00:54:37] Um, that, that can make sense at that scale. When it comes to a slippery map, the team that knows the slippery map can accept that for that one component that's really special. We understand that, you know, we're the only ones who are gonna understand that shell of that custom element and how it works, and we're taking that on for the company.
[00:55:00] No problem. Doing that for every component in a design system at that scale is hard to justify.
[00:55:05] Jared: Yeah. Makes sense. Well, I think lessons learned here, for me, again, the, the learning opportunity, the holes, you know, the debug. Tutus in, uh, in Elm, if you will, um, for, for places where, um, we can improve. Um, I think, uh, choosing where you, uh, where you decide to go when you have multiple frameworks, um, you know, is, is a, is a decision that has to be made at some point as you scale.
[00:55:42] And, and thinking about that and thinking about where you're going. Um, ultimately, you know, there can be things outside of your control, right? Like acquiring another company that, um, that, that may make that decision, um, easier for you, but also may not be the, the decision that you thought you were going to go in, right?
[00:56:03] Um, yeah. What other conclusions do you have? If.
[00:56:09] Kevin: Um, I would say that uh, just because you choose to move away from a technology does not mean it was a failure for you. Uh, I would say the parting thought in my blog post is that this is what success can look like, is that, um, I think if we had never adopted Elm CultureAmp, we would probably be in a worse position today.
[00:56:38] We would've had a harder time attracting engineers at a critical phase in our growth. That product that we built from scratch with Elm, the Culture Amp effectiveness, um, it would've shipped with more bugs. It would've taken more maintenance effort over the years as it would've had to stay on the treadmill of, of React and NPM package upgrades that we just have not had to do with, uh, Elm when that product matured and stabilized and we were happy with its feature set.
[00:57:10] It has happily sat on the shelf for three, four years with extremely little maintenance. Um, and that you, you don't get that from, uh, react apps even at their best today. Um, so Elm got us where we needed to go better than anything else could have. I feel at the time that we adopted it and Elm got us to the place where the right thing to do is to move away from Elm.
[00:57:41] Without Elm, we might not have gotten here. We certainly wouldn't have gotten here as quickly or as successfully. Uh, so I look back on Elm and I feel grateful for what it did for us. And I feel like Elm does not need to solve everyone's problem at every scale to be valuable. Um, the lesson I would. Hope that people take from this is not avoid Elm if you're a product company or avoid Elm if you're a growing product company.
[00:58:13] It would be adopt Elm if it serves your purposes today. But know that it might not always, and that's true of any technology. Um, be ready for the moment where the technology and your needs are starting to diverge and be ready to have real conversations with the engineers and your teams about it. Um, the other great piece of, uh, advice that Richard Feldman gave me off air was look out for engineers who only wanna work with you because Elm, uh, because those are the ones.
[00:58:51] If the day comes when you shouldn't be doing Elm anymore, they, they might leave or they might fight you on it. Uh, and what you want is engineers who are excited because you're interested in using something like Elm. You're interested in being a little weird. You're, you're interested in considering options that are not necessarily the mainstream.
[00:59:14] Um, but those engineers are ready to move on to the next thing with you when the right, when the right moment comes along. And if you're a product company, obviously you need engineers who are excited about your product and it's mission. And we always checked for that in, in interviews. It was like, um, I'm so glad you're here.
[00:59:32] I'm glad we met you at that, that Elm meetup, but um, have you heard of our product and do you care about it was always the next question. And that was just as important as, are you excited about writing, uh, fp on the front end?
[00:59:45] Jared: Yeah, I think that's a, a good point. And, uh, I thought of something that comes from a tweet that . Evan Czaplicki wrote, uh, a while back, it was about these Elm principles, a, a draft, and one of them was, uh, take responsibility for user experiences. And I think that, you know, again, if you are trying to build something, you need to pick a tool that will allow you to build what you're trying to build.
[01:00:16] And if it doesn't work, adapt.
[01:00:20] Kevin: Absolutely.
[01:00:22] Jared: So Kevin, I think that's a good place to, uh, move on to the outro. Um, I thought if you wanted to, if you had some ideas of your favorite Elm Town episodes, I would love to kind of reminisce on that. Um,
[01:00:40] Kevin: I'm getting Misty now already. I'm, I'm, it's, it's getting real. It's almost over. Uh, yeah, I, I did pick a few. It is hard to pick favorites. Uh, looking back, there were 20 episodes that, uh, that I got to record and, um, and they were all excellent. Uh, each one was a glimpse into a completely different world and in some cases, like people with completely different priorities to, to mine.
[01:01:09] And it's, uh, that's what I'm wishing for you, Jared, as you continue on this adventure, is that you get to get to talk to some people that for whom programming feels a completely different. Uh, space in their life than the one it does for you. Um, so for example, I thought right away of my chat with Martin Stewart in Elm Town 48, where he talked about making games, uh, as presence for his family members.
[01:01:37] And the idea that that one would build a video game for your sister just to make you let her know that you, you love her, and that that feels like, um, a, a good birthday present for them. Th that is something that like, I would love to feel like I had the time to do that for my family members. And maybe it says something about me that I don't, maybe it says something about my family that I don't, but I really admire that.
[01:02:07] Um, and, and to get to spend an hour with someone who was approaching programming as a gift for others was delightful. Um, Elm Town, number 51. Uh, with, uh, Joseph Knee, also known as more Drx was kind of the opposite side of the coin. He was very much someone I fe I feel like, like me. He was at a product company in Australia.
[01:02:34] Um, uh, the big difference for him is he had inherited a large amount of Elm code, and it was, it, the, the compiler was struggling with it because it was largely generated Elm code with some, some, like, uh, compiler hostile patterns in it, shall we say. But, uh, he also was building a video game with Elm, uh, and, uh, I got to play it live during the episode.
[01:02:59] So as he was talking, I was like playing through this dungeon crawler, uh, in, um, uh, implemented in Elm. And he was, uh, he was trash talking to me about the choices I was making, telling me that going down the well was the ch the cheat way of, of playing the game. So, uh, that was, that was a lot of fun. And then finally the episode 37 with, uh, Luke Westby and Richard Feldman about upgrading to Elm 19.
[01:03:28] Um, the, the thing I enjoyed most about that was the feeling of solving the practical challenges of a migration from Elm 18 to Elm 19. There were some breaking changes and if you had a large code base, you needed some kind of strategy to roll out the necessary changes, uh, gradually and keep your product running through the course of it.
[01:03:58] It was something that, um, I felt like that was not a charted path until. Richard and Luke shared what they were doing at No Red Ink on the podcast. And, uh, it took it from me from a place of, I'm afraid we're not going to be able to do this. I can't see the path to, oh, you just laid it out. That is a migration strategy that can work here too.
[01:04:21] Uh, and it felt like a valuable service to the community. So I was, I was really glad to, to discover that myself, but to share it on with others in the process.
[01:04:29] Jared: Yeah, those are great picks. And actually one of them on my list is episode 48 with Martin Stewart talking about making little games like presents. Maybe we'll have to try to get Martin back on. ,
[01:04:42] Kevin: Yeah.
[01:04:43] Jared: that I really enjoyed was the Risk of Elm with, with Dru. Dang. Episode 36. It had really clear, explanations of, of, you know, why the choice was made for Elm and, and some good advice.
[01:04:57] And, and again, just a different perspective than what I had where it was. It's always been I've, um, brought Elm into or inherited Elm from an Angular j. Code base. Um, and so we've been moving, you know, from Angular JS legacy to Elm. All the spotlight on episodes, so of course one of them was Spotlight on Kevin Yank. That one, uh, was great with you. Um, but there were several and I think that that really kind of set the format of the show where it's really talking about people and I think that. By focusing on that, that's, that's the approach that I'm trying to take as well.
[01:05:41] You understand the struggles, the challenges, um, and, and ultimately the stories of, of these people, you get to understand how they're different from you and what their motivations for using Elmar or in this case, you know, for choosing not to use Elm at this moment. Um, and so yeah, those are, those are all great.
[01:06:01] Check those out.
[01:06:02] Kevin: We have to thank Murphy Randall for that spotlight on format. That was, that was all him. And uh, yeah, I agree that it was a great way
[01:06:10] Jared: Yeah, and I think though that, that, that series really created the trajectory that I think, uh, seemed to follow. I don't know if you thought about it in those terms, but, uh, you know, all the episodes really seemed to focus on, you know, the people and understanding them and, and, and what they were doing, and.
[01:06:28] Not directly on the tools and techniques. Um, there is now an Elm podcast that does focus on those things. So I think that for me, it really makes sense, um, to still have a place to talk about, you know, the people and their motivations and their stories. As well as, you know, keeping not being a contender with Elm Radio, where, uh, Dillon Kearns and, uh, Jeroen Engels are, are doing a, an excellent job on those.
[01:06:59] Kevin: Yeah, I'm, I'm, it makes me happy that, uh, That was the original conception of Elm Town. That's why it's called Elm Town. It's a place where people live and we get to meet those people on the streets of Elm Town. Um, so it is gratifying to me that, that all this time later, that approach that Murphy started for the show is still an inspiration for you, Jared, and it's where the show's going to go next.
[01:07:28] Jared: Yeah. Yeah. And also, uh, Murphy did a series with Evan Czaplicki, the history of episodes, and I thought those are, are really helpful to understand, um, reasons about why certain decisions were made,
[01:07:42] Kevin: I'm a real sucker for a behind the scenes story or a making up story. I'm one of the people who's almost more excited about watching the, uh, commentary track of a movie than the movie itself, because the making of the thing is more interesting to me than the thing often. Uh, so yeah, I agree. Um, the, the story of was great.
[01:08:03] I, I'd love to get some more stories of
[01:08:05] Jared: Yeah. Yeah, that's a, a good idea. Um, yeah, and I, I definitely wanna thank, uh, Murphy Randle for hosting. You both had editors, you had Xavier Ho, and, um, the, the editor when Murphy, uh, was hosting was
[01:08:23] Kevin: Fergus, I
[01:08:24] Jared: Meiklejohn. Yeah, that's right. Yep. and so thank you to all of you and, and to, uh, the sponsors, uh, your company, uh, who sponsored Culture Amp and, and of course, uh, to Murphy's Company and the, the other companies and, and people who were, um, sponsors in the past.
[01:08:41] Uh, and of course to the listeners. So without, without them, There would be no reason to continue recording these episodes. So hopefully, uh, this continues to be interesting. Um, and thanks Kevin for hosting the many talks, being open and brave about sharing your decision. Uh, this is a new beginning for Elm Town, I think.
[01:09:02] And, uh, look for more new episodes hosted by me coming soon. Aloha.
[01:09:07] Kevin: Aloha.
[01:09:09]