 I thought it was gonna be terrible being on this stage, but it's actually almost nice that I can't really see you guys, because I'm super nervous, because it's the first time I've talked outside of Illinois. So thank you for keeping the lights up as high as human possibility. So it's actually kind of neat to go directly after somebody who's working with a bootcamp, because I'm almost sitting on the opposite side of that equation. I work with a consumer finance company, we're a billion dollar company, we're IPO, we've got over a hundred engineers, and what I'm working with is not folks who are brand new to the field, or at least not exclusively that. And what I'm working with is trying to get people over the course of their careers with us, which two, three, hopefully four years, they need to keep getting better at the things they're doing. So it's really interesting, just listening to that last talk, the fact that they start learning the algorithm certainly really early on, and hopefully in computer science school, however you come to the field, my job is to continue and hopefully get to the point where you are a better craftsman year after year. So my company, it's a consumer finance company, which I put at the bottom actually, because I think that's the least relevant part of this. It almost doesn't matter what industry we're in. My suspicion is that people in really every other industry, and I've worked startups and other companies have exactly the same issues that we do. We are fast paced, which is sometimes euphemistic for going at a breakneck pace. I think that that's true, but I also think that there are also a lot of positive qualities to what we do. As a competitive company, we have to ship or we shut down. And so all the things that we're trying to do, the attempts at getting better at what we do are in the context of a company which is regulated, which has to ship. And so there's really no compromising on that point. So we have Rails code bases starting at 1.2. We actually started at 0.7. And because we're a startup at the time, we wrote lots of terrible code, and we're massively financially successful. And so we couldn't get rid of the code because it was making a lot of money. And so that code base has been pushed up over the years and managed to find itself locked at Rails 1.2. And so we did what any normal person would do. We attempted to rewrite it from scratch because that's totally an intelligent thing to do. And so now we have two large code bases, one of which is on modern Rails, thankfully. And so we're coming from a pretty wide technical platform here, so all the way between Ruby 187 and Rubinius, we actually, Brian Shirai is a member of the team, so we have the Rubinius guy. So it's a really interesting technical platform. And then we hire a ton of green developers. So for historical background on where I'm coming from in my position, and I'll actually even hop to the next slide, I took this position at Innova maybe about a year ago, and in the time that I've been in it, we've grown from 80 people to about 120 people in the engineering department, which with attrition is actually about 50 people being hired, which is what I normally will categorize for people as a bad idea. It is just not intelligent to hire that many people that quickly. But we were IPO-ing and we felt the need to expand. And so I, from my background, so I've been developing for a dozen years of work, public sector, private sector consulting and all this, worked at this company for four and a half years, so three and a half of the time. And we decided that we should probably teach those 50 new people the stack. We should probably teach those 50 new people about our culture, about all the things that we wanted them to know. And so I stepped into this position as the manager of internal learning. I don't expect that you'll do this, but I do think that there is value in understanding the path that we took and how it shaped our culture as a company, because I think that the lessons from that are really applicable to, again, a really wide swath of companies. That was an interesting pop. And just a note on that, so I am not a teacher. I think that that's okay. I've been trying to learn from books because I'm an engineer. I think I can reinvent other people's professions by reading a book. But in all seriousness, it's okay to be not an expert at this. So when I started on this, really no history in education, thankfully a lot of history in development, but a lot of this stuff can be picked up as you go along. A lot of this stuff will either really obviously work or really obviously not, so don't fret not being a teacher with any of this. So how many people here kind of, how many people here, first of all, ship on day one? This is my favorite, like, everybody's job posting. Yeah? Whose job posting says they ship on day one, but they don't actually? Okay. There's an idea that comes hand in hand with that, and it's kind of learning on the job. I think that most people, when they haven't really developed a formal training program, what they have is that you come to work the first day, they issue you a laptop, and then hopefully there's an automated build system, and you kind of hop in, get a first bug. This is an appealing system for a lot of reasons. You don't feel like you've wasted any time, you feel like you're really only learning the things you need to learn, but my contention, which is backed up by history here, is that it's really not the best way to learn. What I've found with folks as they do this is, A, they mimic the bad patterns that you might have on your Rails 1.2 code base. They don't tend to learn a wide swath of things, and so what you get, for instance, is maybe UI developers are loading a whole bunch of active record objects, and so they don't really realize the way that they're querying, and you run into these kind of really obvious problems if you understand that n plus one problem is a thing, you could Google this, but in the ad hoc learning method, it's not something that you really run into, and so I'm gonna argue that that's not really the right way to do it, and this is of personal importance to me because I, of course, then needed to justify that my job existed because if I could put people into a team and then they would just sort of learn everything, then I actually shouldn't exist, which doesn't mean that I should make something up, it means that my job shouldn't exist, and so for me, I wanted to get the reasons right on why it is we should have formal learning, and why it is that we should spend our time and spend our money and take away from aggressive deadlines in order to learn more Ruby, because it's not good enough that we like it, it's not good enough that it seems like something we should do, we should really start to justify this with real reasons, and so the reasons that I've got here, the first one is really just attracting amazing engineers. The biggest thing that I've seen in my time building this culture is that the people who I really want to work with on a day-to-day basis who do a fantastic job shipping want this as a part of their job. Does anyone not want to learn as part of their job, right? So those of you who are really good at your job, I would like to work with you, and so hopefully you'll go towards places where that's the case, and so there's a culture thing here which, coming from a company, I want to hire people, I don't want you to be able to hire them, so I want to have a better learning program than you do. Reduce attrition. Senior folks, it's really interesting. When you get into a job, and I found this actually being four years at a company, when you get into year three, it's really, really common to kind of run up into this wall of learning new things. So on the first day, there's all these libraries and all these things you never used, even if you're on the same stack, it's a whole new set of gems and a new architecture in that. Three years in, brick wall. What we want to be able to do is move the organization forward. A, we want to be able to change the platform, but B, we also want to give you the opportunity to be looking at things that are beyond where you're at right now. So we can alleviate that, and with that, we can retain employees, which is another fantastic thing. Bus factor. Does everyone know bus factor? Cool, so for anybody who doesn't know it, the idea is how many people on your team would need to be hit by a bus before you're poached? Hopefully it's a large number. In a lot of cases, it's a very, very small number, and so we want to increase that bus factor and make sure that there are at least a handful of people that know any given system. There's another point away from the ad hoc system because what often happens is that if I'm the expert on the payment system, then I get all the payment system bugs. I learn so much about the payment system, and then when I get smacked by a bus, they're like, oh man, nobody has any idea what was going on, and so we can offset that. Bring fresh ideas into the organization. Again, the platform should shift. We should not feel like we're locked in. Ruby of five years ago was not in the place where it is today, and not taking advantage of that is a shame. And then reducing wasted effort, which is hopefully self-evident. This is kind of the play to the business is we're gonna be faster than we were before. So a non-exhaustive thing, a list of things that don't work, so I have tried in the past to get more training time. I have talked to a lot of people who feel really strongly that they would like to spend more time on this, but I find that we are often very ineffective, and so I wanted to get out of the way very quickly some of the things that aren't gonna work very well. Me a while back, we really just need to make this a priority. So this is shifting the blame off onto somebody else who is not me to say, if you would tell me to learn, then I would learn and I would be really good at my job. This doesn't work. The CTO and the CEO have other things they're worrying about. These people that you're appealing to probably don't really understand the issue in the same way that you do, and by shifting that responsibility off onto them, it's not gonna be successful. I haven't seen this model really work. Somebody can come tell me how great their CTO is, but in general, I don't think that you can shift it onto somebody else. We could pause our current deadlines for a couple weeks. Again, we are in an aggressive shipping schedule. This is just a non-starter. There's no way to do this. We're dedicated to investing our people who are in a crunch right now. Has anyone ever heard this one? Like, we really love you guys. Once we're done with our crunch, we'll get into this. The crunch never ends. You ever notice that? So this is another thing where if you wait until the right time, there's never gonna be a right time. So what I'd like to propose to you guys is how to build a culture in three phases. And these are based on the things that I saw as an engineer at Innova. And the caveat to that is that my people are not your people. My company culture is not your company culture. Take everything that I say here with a grain of salt. We tried, of all the things that I list here, we probably tried three times as many. I'd like to try a lot of things. So keep in mind the spirit of what we're trying to accomplish. Keep in mind the types of constraints you're under, but your approach has to be different. And there is no precise answer to exactly what's gonna happen. So the first phase is building credibility. So this looks like is that in most companies, especially once they're a little bit more established, people have gotten a bit comfortable. There's resistance to actual learning. It's this idea, well, I had to learn it by jumping into the pool, then you should have to do the same thing. People are mostly learning in a kind of ad hoc manner. This is a pretty common phenomenon. If there is training, which usually there isn't, it's probably a wiki page. Or in my case, it was a 800 line shell script that didn't quite work. About 90% of the instructions were correct, and I was hoped to intuit where the rest of them went wrong. And so it's pretty disorganized, but hopefully there's some help getting people on board. There are the last bullet on here. There are probably a couple people in any organization who really care pretty passionately about learning. And this is a really fundamental thing, is that in the beginning, there are probably only a few people who are willing to step outside of their normal roles and their time and take the risk to actually get this stuff happening. So this will work for us. Like I mentioned before, do not pass this off on someone else. If you care, you are responsible for it. If you care and it doesn't happen and you didn't try, you are responsible for it. And so you have to sort of take the reins and decide to do something with this. Think opportunistically. So early on, since you have no credibility, we need desperately to have victories. So think about the things that are really easy wins. So say there's one library that if people actually knew was in the system, they would do a better job of programming. Teach them that one. It's easy to see the output of that thing. It's low effort. It's low risk. So those are the things we need to do. Low time and effort investment, like I said, we can't afford to spend more time or everyone's gonna tell us no. And then focus on improving people in their primary roles. This just goes back to the idea of being able to demonstrate really quickly that you are having an effect on people. And what you need early on is to be able to say, look, Tom isn't writing terrible tests anymore because we told him how to use our spec. And that's the kind of thing we're looking for early on. So what we did there was we did a lot of meetups. We actually ended up running some of those meetups but open book policy, I'm not actually gonna read over every one of these things. If you take a look at them, it's all stuff that is, again, really low cost and it's stuff that a couple people can opt into. I don't need the entire department to opt into any one of these things. I can have maybe five or 10 people do the job and it works. I just wanna highlight a couple of those really quickly. The open book buying policy, this is, if you take away anything else from this talk, this is like the most dead, stupid, easy investment you can make in people. So our policy that we came up with is if you're willing to ask me to buy the books, I'll buy multiple copies of the book. If you wanna buy Sandy Metz's book, I'll get five copies and I'll put them on the shelf. And if those copies disappear because I'm not asking people to bring them back, I'll buy five more copies. Over the course of last year, we bought about three books per engineer. It's 360 books, it's about 10 grand. That is the easiest, dumbest investment you could possibly come up with. And I can't pick the books because I don't know everything about what needs to happen. And so when people come to me and they say they need the angular book, I can make that happen and I can spread that knowledge to the rest of the organization. So copies are already waiting for you. Not particularly expensive, like it really just is not expensive enough to matter. I will say people don't read all the books they ask for. Suck it up. There's really no way around that from what I can tell. I am a fan of paper books. In this case, a lot of people tell me you should have bought all ebooks. What I've noticed is that they don't read about 95% of the ebooks that you buy. So I'd rather take the slightly higher hit rate and just buy them used and feel a little bit better about that. New hire buddies. So you may or may not do this informally. It's great when a new hire comes in and they have some relationship in the company. Maybe they know somebody that's already there. If we can't have that happen organically, let's cheat. Let's just assign everybody a buddy in the organization whose job it is to tell them the bathroom code and tell them who to talk to and tell them where to go for lunch and keep them involved. Again, very little expenditure does not mean that everybody has to buy in. We just have to find a couple role models who we can put in that position. And it's a really fast way to get people up to speed. This starts to solve this problem of not knowing which libraries are out there to solve this. They can say, oh, I'm trying to solve this problem. And you can say, oh, we've solved that three times before. This is how we already did that thing. And so that's a really nice and easy one to do it. Also as a pressure relief valve, I think that case is like some people like me are really neurotic. And so if you get really neurotic in a new job, it can be nice to have somebody to talk to. So that's a really nice side effect. So the dangers of this is that inertia. Inertia is bad. And it's really hard once your organization has been around for a while to get people to the idea that they should be learning these things. And related to that, people feel like they're gonna look dumb. The vulnerability of being a learner is a really important thing. And if you don't have a culture that encourages learning, it feels really tough to ask questions or to speak up and say, I don't understand this thing. Help me learn this thing. And so we need to try to lower the risk of speaking up. And that's something we have to work with really early on. And then low credibility, if you do stuff that fails really early on, everyone will remember that. And then they'll try really hard not to remember the things you succeeded at, which is why we focus on high success rate when we don't really have that culture built up yet. Which brings us to phase two. Let's say we've done that for a while. We've had a lot of these hopefully high impact, cheap things. Hopefully at this point, our new hires are learning a lot. They have buddies, they have books, they have maybe slightly better onboarding and they blog about their onboarding so that they can tell other people what they've learned. People wanna take control. This is a big one. We really had a nerve when we started doing this stuff. What I started to get was folks coming to be saying, I'd really like to do more of this learning in my team. But the rest of my team is really recalcitrant. And so I don't know how to do it. And so in the same position I was before, they don't know how to take control of that situation. Some teams maybe start to learn as a group. We had maybe 12 teams. I think two of them had some kind of structured time as a group to learn things. That was fantastic because that's something that we can use to effectively just shame the other teams into doing the same thing. Small, somewhat organized onboarding. At this point, we had some documentation. We had a little bit better list of the kind of things that you would wanna know. But we didn't really have a completely formal system. And then instead of having one or two people, you've probably got one or two people that are still driving the big part of the change. But you've got a larger core of folks than the rest of the department who are really interested and so they're willing to do the legwork. So what we'll look for us now is to broaden our scope. So look ahead and start to anticipate need. This is the next awesome parlor trick is when my boss says to me, I need everyone to or this group of people to know Ember and I say, well, I already got the book and I already started training with them. Makes you look really smart, makes you look really credible. So that's a really good trick. Opportunities that take a while to pay off. So remember in phase one, we can't do things that are riskier that take six months to pay off. In phase two, we can start to look at stuff that takes a little bit longer. One of the big things that you can do is cross training for various roles. So in my company, we separate UI, database, backend dev and test engineer. So I just cross train as many people as possible on these things so that if you are a database developer, the Postgres community is quite frankly just not all that great at testing relative to the Rails community. So if I can teach my database developers the philosophy of test engineering, I get a freebie there where they get better at testing at the database level. So roping in more internal collaborators, like I said, find the people who have the will to do this but don't know exactly how to get started and figure out how to get them started and then seed good role models. This is a really important one. People tend to absorb the characteristics of the people next to them. And so if you have a group that really is not living up to this, find the person who is just like fanatically, like trollishly into learning all the time, put them in that group. And even if they have a lot of static to start out, they will move towards each other in a way that will be totally helpful to the entire group. So like I said, we ended up hosting meetups, which is fantastic. Speaking at them, which is actually why I do this so that I can tell people when they tell me that public speaking is hard but they're full of it. Internal workshops, we started doing, so in the first phase you could do something like a lunch workshop. One hour, low investment, pretty easy. Half day workshop, way better. A little bit tougher because again we have to be able to demonstrate that output but now we have a little bit of credibility under our belt. Dedicated onboarding process is a big one. But let me skip ahead to a couple that I actually want to look at. So juniors as teachers. So if you remember from the first photo with the buddies, that was actually our group of interns. We assigned to them some folks who were maybe like a year and a half out of college. And what we did when we got a concentrated onboarding program is we took these same interns who looked to be about 12 to me. And we took the super senior engineers of 20 years and we had the interns review their code, which is really, really hard on your ego because they did it to me too. And so the interesting thing is when you started learning you get these younger folks who actually are really up to date on specific things and it's a really good way to help them grow because when they're right, they're right and that helps their confidence and when they're wrong hopefully the more senior person teaches them why it's better do it the other way. But this has actually been a really successful approach for us is to take folks who learned something recently and then force them to teach it by way of code reviews. It's a little bit tough on the way of organizational knowledge because sometimes there are really good organizational reasons not to have done something, but overall it's been a huge victory. Their pain tolerance is low. It's my favorite way to think about this. If you think about it when you've been in an organization again for say two, three years you don't remember what hurts, right? You've been doing it for so long you spend 40 minutes doing something that should take 10. You're like, yep, okay, gonna go get coffee, no big deal. And so when you have people who still have low pain tolerance, use that low pain tolerance. Cause your young people pain, quote that on Twitter. And use that lack of pain tolerance to have them point out to you the things that you can fix because you don't see them anymore. Does that make sense? And then weekly tech talks. This is my favorite part of my job actually. Every week there's a standing appointment. You can't see it in this picture. There's usually about, there's about 100 people that attend and you get 15 minutes to talk about whatever you want. It's a great way to introduce people to the idea of teaching others. More importantly, it gets four new ideas into the organization every week. That's fantastic. And an hour again is not all that much time to spend. So the only danger here is we have to curate this thing, right? Like as somebody who's helping run this, I have to find people, convince them that it's not super scary to talk in front of 100 people, which it is. And then get them to actually prepare a presentation. And so there's, you have to hold onto that credibility but as long as you can, when you have interesting stuff we have people talking about, you know, programming arduinos to drive robots with Wiimotes. We have people talking about wearable fashion. We have one guy whose entire plan is to put a plant on every single desk in the entire department. That's his only goal in life is to have each person have one plan. It was one of the best talks I've seen in a really long time, because he really, really loved the subject. So this is just a really great, again, not very expensive way to get this, to get new ideas moving around in the department. So dangers. Like I said, there's still a couple of people who are really forming the core of this initiative at this point. Losing those people really hurts. And if you do lose those people there's a lot of danger in people kind of like blowing it off and taking a step back and you lose that momentum. That's really tough at this point. The perception of wasting too much time. This too much time thing is not, it's not the actual rejection. They're not actually telling you you're wasting too much time or if they think they are, they're wrong. What they're actually saying is that they don't see the value for the time you're spending. And so now that we've started looking at things that might take a little bit of time to actually return that reward we have to go back and justify it. And at this point you're gonna have to basically look at the output, start looking at some kind of quantifiable way to say this is how much we're getting out of this thing. So that you can push back on that perception because we're not wasting time, we're investing time. And we have to convince people of that. And if you don't, then you get clamped down. That's no good. And then the old guard in this case may be too comfortable. So the old guard being the folks who've been there, there's always like those five people who've been there way longer than you have. They're pretty sure that the way that we're doing it right now is the perfect way to do it because they've been doing it for six years and they probably get really good options. And so the old guard are really, really comfortable in this case and that's again something that I've seen in every place. And so a lot of this change ends up driving from folks who are newer or less experienced because again, they have lower pain tolerance because they can see the way that things are no good. So phase three, you've been doing this for a while. You've got weekly tech talks, you are hosting meetups like you were rocking it. At this point, what we wanna do is to start to cement that culture. I've got this cool, the roots are actually a parable for what we're talking about. And what that looks like is people start to see learning as a normal part of their job. This is the secret judo of learning culture is when people forget that there was ever a time when they didn't learn as part of their job. When people start to understand learning as a requirement for what they do at work. At this point, you no longer have to be the one or two people who are driving it. At this point, everybody's driving it because everyone expects it to be part of what they do. So momentum and reputation, that's a huge thing. And then so dedicated training for new and existing is an important thing. You remember before I said new people are the driver early on. Later in the game, you have to really open your existing people because over time most of your people are existing employees, not new employees if you're doing it right. And so they need to continue learning as well because we're not done because there are new libraries all the time. You might be doing it on ERB, maybe you need to learn Hamel and Slim. And that's something that you can't just wait until you get enough new employees to bring Hamel and Slim into the organization. And then it's an act of chaos of new ideas. Chaos is a good word for this. It is a double-edged sword. It is fantastic to have so many good ideas floating around for how to solve problems. It is a problem when people implement it four or five different ways. This is the problem I would like to have. I am perfectly willing to cope with this problem, but you have to be aware going in that it's not as streamlined as being dictated in your direction. People take this in whatever direction they want and that is a good thing, but you need to manage that process actively as a team. So make them forget that learning was never not part of the job. It feels like demunigation. It's, that really is the key to the whole thing. Make it part of people's job requirements, honestly. Everybody gets involved. At this point again, it's just a passive part of your gig. Whether that's just code reviewing different groups, whatever it is. It's always part of what you do. Try riskier things without destroying momentum. This is my favorite part, because I think that there's really cool stuff we can do once we have momentum and credibility. Once we can actually expend resources, I think there's really interesting stuff that we can do that fundamentally makes our jobs way better. That this sort of ad hoc, maybe I learned on the weekend stuff, just never gets to. And so that's the stuff that really is the payoff for me. So dedicated training, open source contribution. A lot of you probably did that earlier on. My company was not huge and contributing back. So for us, this was a big move to being out in the community. Apprenticeships, I'm not gonna talk a lot about code spikes, but what I mean by that, we don't do 20% time per se, but we do take time now to write code explicitly that is not particularly productive, that we may just toss out. And that's something that now we can't even say, like, oh, well this library's gonna be great at the end of six months. We have to say, well, the library's trash, but I learned a lot of things about it. And that, again, is a very strong assertion and something that hopefully we get to be able to make. So dedicated training program. This was the biggest thing that I did. We ended up creating a framework and open sourcing it. It's called Level Up Rails, and it is a comprehensive way for all our new and existing employees to be up to date on all the things we expect them to know, which means that if they've been working on Rails 1.2 and would hopefully like to get out of that situation, we have the ability to teach them to do all the modern stuff. We have the ability to teach them the philosophy of test engineering. It lets people cross different jobs, get different job titles. It makes it faster and easier to get people inside of the organization. It is a huge time commitment. They do not deliver productively for six weeks when they join the company. I'm still like, I would love to find a way to ship on day one and maintain this, but if I have to pick between them, I will take people who instead of inflicting bad code on the code base on day one, come to it knowing all of the right things to do on day six weeks in one. So the last thing on the bottom here is another really interesting one that I've heard from a lot of our candidates. If you aren't aware, most of the people in this room have imposter syndrome, and most of the people in this room are not actually imposters, it's interesting. But when people look at applying to jobs, I think there are a lot of folks who say, who probably will never apply to Google, not because they don't qualify, but because they feel like really smart people work at Google and then they'll figure out that you're not actually one of them, right? And a lot of those people are really smart and so I'd like them to apply for me because they think that they don't, they can't work at Google. And when they come and they see that we're willing to train you, that we're willing to bring you up, it is okay to not feel that you're gonna come into this job 100%. We've actually got a ton of really good candidates who have said to us like, I was worried because I come from not Rails, I come from Python or I come from whatever else. And that's been a massive benefit for us. And then my favorite, favorite, favorite part, our apprenticeship program. We realized that by learning to teach people, by learning to take somebody from not knowing the platform and have them know the platform, it actually opens us up for an entire extra set of candidates because these people who are juniors, sure I can teach them, but it also means that I could take a half step over here and take people who aren't even really at the space of being juniors. So we took two apprentices. They, to be blunt, they failed our technical interview because they were not up to our level of juniors. And we created a new job for them. And their job for six months was to learn our stack. And these are people who, we don't just take whoever fails a regular interview and put them in the apprenticeship. We took people who were twice the culture fit of everyone else. People who, when they get into their own, when they really do flourish as developers, are gonna be a massive impact on our department. And we hadn't been able to address that market before, and now we can. Because we can take the time to have these people and have all their mentors, they have two buddies, they have like three managers, they sit and they pair with everybody. And this is a just fantastic win on top of just being the right thing to do. And so this was the really big payoff for me in turning us into having the right culture. Every time I walk, I get static, which I think is why it's... So the danger, long-term payoffs are hard to measure, but the costs are immediately evident. You will always have to work to justify what you do. We started our apprenticeship program very, very slowly so that we could keep the costs low while we prove that it could be a thing. I would love to have ramped it up faster, but that's something we just have to pay attention to so that people don't question our credibility on the front. Nobody feels personally responsible anymore to push on the culture, which means the big danger at this point for it going away is just fading away. So that's something that we still have to pay attention to. The chaos, like I said, could be really painful and then losing the habit. So we are highly regulated. We had a situation at one point where literally half of our engineering staff were working on the same project and it was a half step above sleep and a half step below food, right? And so that's really tough to hold onto that habit. So I'm gonna give you a quick anecdote. I actually, between the time that I was accepted to this talk now, I quit Innova. And there's a reason, don't worry. This pays off, don't fret. So I did that because I wanted to go teach this kind of stuff to other organizations and because I was really confident in the culture. And on the day that I left, people actually came in and took over every single one of the things that I've been doing as a manager of internal learning. I'm not sure whether that position will continue to exist or not because at this point, even people who have only been in the field for four months feel empowered to take control and push out on the culture of the company. And that's something really powerful. And that's something that really says to me that we're doing the right thing. So my parting request to you, please do something. If you are interested in learning more at work, don't push it off to the CTO. Don't wait for somebody else to step into that thing. Just like pick something. Pick, go have coffee and a book club. Like pick something, just do it. That's it.