 Before RailsConf, show of hands, who knew what Tuft & Needle was? Anybody? Nice, okay. For those that don't know, Tuft & Needle is a mattress company. We have a presence here in Phoenix at RailsConf this year because our office is here. And Tuft & Needle has some interesting elements about it. And one of it is our culture of learning, and that's kind of what we wanted to talk to you about today. So what does it mean to cultivate learning, and why is it important? It's sort of easy to say that growth and learning are important tenants, but what does that actually mean? How do you actually carry that out in your business? And how do you take that to your team as an investment in them and their sort of collective and individual brain trusts? And why do it, right? So like, when we were thinking about this and thinking about the kind of culture we wanted to create at our own business, three things sort of came to mind. It gives people purpose. It allows them autonomy, and it provides them with growth. And all of that kind of leads back to happiness, right? And happiness is kind of hard to quantify, but we sort of think of it in ways like this. If you're working on a problem and you get stuck, that's a bad feeling, right? And you want to feel like you have a place to go to get unstuck. We feel like underscoring this culture of learning helps people to realize that it's okay to ask for help, you know, as a software developer, as a designer, you can't know everything, right? And that's okay. If you're here, if you're working with us, we already have confidence in you. Like, we've already assessed that you have the skills that you need to work with us. So from there, it's really about empowering you to know more and to share more with the people that you work with. So as I said, we're David and Dennis. We're from Tuffton Needle. A little bit about me. This is my newest daughter, Rory. She's nine months. I have four kids. Y'all pray for me. I've been actually working with Rails for around 10 years. I found it sort of right at the beginning. And my story with Rails and at the programmer, as I thought about it, is kind of relevant to this, actually very relevant to this talk. I was on my own for a long time. I had done some work with the military. And then I was kind of, I was basically doing a freelance consulting. And I wasn't really looking for a job. And I stumbled upon some guys at this company called Hashrocket at a coffee shop that I would go to to work. And I think at the time, I felt like I was doing okay, but I didn't really know that I needed something more, right? Like, I was a Python developer. I was doing some Ruby stuff. Things were fine. And I had this chance encounter and they invite me down to the office through a sort of other weird situation that involved guitar lessons of all things. But anyway, and to be honest, I don't think I was really qualified to work there at the time. You know, I had some Rails experience and I knew Ruby and all that, but I think that Hashrocket was sort of the first place where I encountered this culture. And it was, they took a chance on me, right? Like, they saw something in me that they thought that they could cultivate and they took a chance on me and did that. So, you know, ten years later, I'm still working with Rails full-time Tuft the Needle and leading the team there now. So like Dave said, my name is Dennis. I know that picture is incredibly Asian, but like, I have a relatively similar kind of experience with Dave. I actually met Dave at Hashrocket. As a designer, it's a little weird that I more relate to people in the technology field than the traditional, like, band posters and CDs and all that type of design, but it's always been an interesting culture to kind of be a part of. I've been designing for a little over 16 years. I kind of started off like a lot of people, like, self-taught. And one of the reasons that, like, creating culture learning and, like, trying to, you know, make that a core part of our culture is important to me is that a lot of you, like, for a lot of us, the pathway to where we are right now is not very straight or clear, right? There's probably a lot of you that had a history degree or something or an English degree or something completely off you taught yourself or you went to school for something completely different. But without those straight and clear paths, it's much more important to have people along the way that will kind of either guide you, give you a break, and just kind of take you other than a wing, whether it's for one project for a day or years. Those people are pretty crucial, and they've helped me get to the point where I am in my career. And so part of why I like doing this is kind of giving back and giving other people opportunities to grow and hopefully, you know, surpass and go much farther than me. So one of the ways that we kind of handle, like, growth at our company is we use, like, two different methods which are mastery programs and then apprenticeships. So I'll let Dave kind of talk a little bit about the apprenticeships. Yeah, so apprenticeships, I mean, I don't think that word is hopefully something that's new to a lot of people in our community. You know, it's something that we pull obviously from other industries. But I think what's important for us is that it sort of starts with the language, right? So across the board, whether you are a software developer or you work in our customer service area or, you know, at the retail store or whatever, we use this language. So it's not, you know, you're a junior developer, you're a senior developer, like, we don't put people in those buckets. It's, you know, you're apprentice, you're a journeyman, you're a master, that kind of stuff. Side note, and this is a personal pet peeve. I don't think you can call yourself a master. I think that's kind of something that somebody says about you. And I know, like, for me, that's, you know, it speaks to like, you know, the life lived instead of the life attained. And that helps me think about, like, you know, continuous growth and learning and how to prioritize myself instead of, like, thinking about how I get to the next level and, you know, how I get to the next compensation bracket and that kind of stuff, you know. It helps me focus on learning and growth and personal growth and that affects my happiness, right? Because if I'm not worried about getting to that next ladder and, you know, that next step on the ladder, you know, it's just one less thing to worry about, right? So, finding talent is hard. I read a statistic recently that last year there were over 223,000 vacant jobs in our industry. And there are not enough people coming out of computer science programs to fill those spaces, right? So, hiring is always a problem. You see it here at RailsConf every year. That's why, like, people are, you know, sponsoring and, you know, trying to get your attention and trying to get you to come work with them. But I think there's other ways. And one of them is to be on the lookout for people that are right in front of you, right? People that you're already in your organization. They already have the values that you have. Maybe they don't have that exact skill set, but I think if you pay attention and you listen, you'll find people that you can cultivate and bring into other departments, right? Bring into software development, bring into design. So, like I said, you know, this is something that... I don't know how widespread it is, but it's something like we really care about. You know, I think going back to previous jobs that I've been in, I wish there were people that were sort of paying attention to that. Like, I'm just starting out, you know, maybe I'm just doing this thing over here. And, you know, if there was somebody there that, like, could just see that, you know, it could be a spark for somebody, right? So, guidelines. How do we actually do it? How do we approach our apprenticeship programs? So, this is something that's, like, constantly changing and something we're thinking about and working on every time and iterating on, because that's, you know, kind of what we do as software developers, and it's also what we do at Tuthenedo with our products. We meet quarterly, usually, and talk about their strengths and weaknesses. We set milestones. We think that goals are really important, especially at the beginning, to get people on the right track. We set the right expectations from the beginning, which I think you really need to consider, because if you set unrealistic expectations, it can really throw the whole thing off. People can get nervous and they want to quit, and, you know, there's all that stuff. And then, we actually compensate people based on this. So, when they meet their goals and they meet their milestones, we pay them more, right? And we think that that makes sense, because, you know, the more you learn, the more value, you know, you can add, and we want to recognize that. So, this is Tommy. We have a large customer experience group at Tuthenedo. We have something around 150 employees. We have about 10 developers, you know, some designers, and then a lot of the people are in this group, customer experience, right? And that's where Tommy was. Tommy has a cool background. He was a schoolteacher before he came to Tuthenedo, middle school, which I imagine is, like, crazy stressful and hard. He's shaking his head, no, right now. And he was kind of interested in technology. And, you know, after a couple of years of being a teacher, he decided that it just wasn't for him. He needed to do something else. And so, he was kind of exploring HTML and things like that. And then he got a job at Tuthenedo in the customer experience department, you know, when he was hanging out in retail stores and helping customers and, you know, helping people, you know, with an email and all that kind of stuff that they do. And he was working on this, you know, this stuff, learning, you know, launch school stuff, that kind of thing, on his own, and he, you know, kind of just started asking us questions. And he came to RailsConf with us last year. And at some point, it was like, okay, like, this is happening. Like, we need to take this guy under our wing. We need to develop him. Like, he's obviously got the aptitude for it. Super smart, already knows the business. Let's, you know, let's make him part of the development team. So, that's what we did. We actually have one of the guys that writes a course for launch school, the JavaScript course. His name is Shane Riley, and he works at Tuthenedo. And we are super lucky to have him. I think he's like top tier front-end developer, crazy good. But, you know, Tommy had access to Shane, and we have his material to use. So I think that's, it's awesome for Tommy, obviously it's awesome for us, but I think, you know, those kinds of formal learning experiences are good, and you should encourage your employees and your coworkers to use them and pay for them. And, you know, take care of that so that people can have that training. Like I said, this is sort of a constant thing that we are trying to iterate on and we're making mistakes and failures with. Some of the lessons that we're learning are, you know, it's really important to get people and apprenticeships onto real-world projects as soon as possible. We think it helps build confidence. It gives them ways to apply what they're learning in real ways. You know, we've all taken those tutorials and, you know, you get to the end. It's like you've made this thing, but how do you actually translate that into something real in the world? It stretches them and it creates the structure and, you know, helps them transition. So, yeah, Tommy is part of the front-end team and he's like a full-fledged member now, and it's awesome. And he built a project. He released it just last week, is that right? First big project, it's awesome. He did a great job, and I know he feels like super accomplished. Cool, so I'm going to talk from the design side of things, and Rachel actually came from a very similar experience too. She was part of our customer experience team. She actually didn't have any formal training in design. She knew of, like, the programs and could kind of do stuff, but like she didn't go to school for, you know, for graphic design or anything kind of like similar to that. I think it was design history was her degree. Like, one of the big things that we kind of learned with her is that, like, a lot of students who are self-taught tend to do, like, tutorials or do things where it's like, you know, you use this one, you learn one technique, and that technique allows you to do one thing, right? And then that's all you really kind of know. And then, you know, you don't really understand a lot of the fundamentals where it's like typography or grid or pacing or rhythm or all that stuff is kind of like left alone, and hopefully you get it on your own or, you know, maybe you don't. It's kind of like akin to, I don't know if it's a perfect metaphor, it's like if someone just knew how to use rails alone, but couldn't write any Ruby from scratch at all. So that's basically the kind of situation that she was in. She had a couple teachers that were helping her out, but not on a consistent level, and a lot of them were like high level, like, hey, get this flyer done versus like, hey, I'm going to help you like learn how to lay out a grid and how that's like helpful for future projects. So a lot of the, and we didn't get it just like with, you know, Tommy, I don't think we really got it perfect the first get go. I think we tried to kind of like load her with a bunch of work and tried to just kind of have this pretty brutal routine where we like set up a curriculum, and every week she would basically meet with me and go over stuff. But I think it's kind of the sign of a poor teacher if you blame your student for like, for them not really getting to where they needed to go. So kind of took a second to reassess the situation, pared down the curriculum to a point where it was more concentrating on fundamentals and like the basics of visual design before like, so she was trying to learn like front encoding and design and then stuff about web and so it was just like too many things at once. So I think one of the biggest lessons learned is just kind of setting realistic and clear goals so that you're not just throwing someone in water and hoping that they kind of like make it work. And then setting expectations and timelines is also a big deal to you like for her. I think there was a lot of looseness around, you know, you're working on this project but never saying, hey, this is, you know, you need to finish this by like two weeks from now. Like whether it's done or not like come to a point where you kind of get there because projects before they were given to her often like just open timelines like they weren't very important so they would last for like four to five months or something and like there would be no clear endpoint. And the thing about design and I'm sure the same thing with development is that you can pretty much tinker on anything forever until someone gives you like a stopping point. So it's really important to kind of get that idea to younger designers to make sure that they understand that you need to, you know, done is better than perfect if you will. So the next slide kind of shows like the progress that she kind of made to designers. This was a big deal because typography is like a very big tell of like how mature you are as a designer and from where she started to now although albeit these be very simple pieces her ability to lay out stuff and like do it on her own without much guidance is dramatically improved and like she's become a very, you know, a very important member of a design team to kind of help us accomplish all the things that we need to do. So like I said there's two parts to kind of what we do a tough needle for the culture of learning and the second part is mastery programs. I'll let kind of Dave go from here. So back to happiness, you know, continuous growth we think it's key to increasing happiness and, you know, it works for everybody. It works for the person that's learning. It works for the person that's teaching. You know, if you've ever tried to teach anything you realize quickly that you don't know anything and it's just a really great way to sort of solidify your thoughts and knowledge about a subject. So we have this thing called mastery programs at Tough to Needle and it's, again, it's across the board. It's not just in software development and design. We use it in every aspect of the business. And basically how it works is it's a little different from team to team but there's sort of some guidelines across the board. You know, again we meet with everybody every quarter and we sort of try to figure out what their individual learning path looks like. But we also try to do things as a group. So we've tried a few different things but sort of what we're doing right now is carving out a specific day and time during the week that we can, you know, structure as learning time. And I think this is really important. You have to be intentional about it. If it's always ad hoc and just kind of whenever you're in Lucy Goosey, you're never going to get to it. So we block out that part of the calendar every single week and we use it, you know, to learn and to grow. Design team does it on Wednesdays. We do it Thursdays, usually around lunch. But we kind of talk every week about whether or not that's still working, you know, we're open to change it if we need to. Mob programming. Anybody done this? Anybody? The mob mind. This is really fun for us. I mean, I love it personally. So what we do is we're mostly remote team so we get together, you know, on a hangout and we use, we've done a couple of things. We mostly use them mostly. So we try to get on teammate or something like that, pull up a terminal and we work on a problem together and we all participate and we, you know, even if we try to make it kind of interdisciplinary so that, like, you know, folks that are writing JavaScript all day can spend time with folks that are, you know, writing Ruby all day. You know, we can work on problems together and it leads to some really interesting things. Like I think when you're working individually, you don't, you know, you don't see all the perspectives of the team and I think when you get together and work on something, it really enriches yourself and it enriches the team because you're passing little tidbits. I mean, even little things like, what was that Vim command you just pressed? How did you do that? You know, that can be a really valuable time saver for somebody. Another thing we do is Book Club. You know, this is something that I've done at other jobs. I like it. I always want to read but kind of never make time to do it at home because I have four kids. But at work, you know, we set aside time to get together and talk about a book that we choose and, you know, it helps us to sharpen our technical skills. Sometimes we get kind of tired of that and we do a soft skill, kind of a book, break it up. Yeah, it's fun. So similar to those things, the design team does stuff that's kind of like a parallel to that. One of the things that we do is do critiques. So it's kind of borrowed a little bit from design school where, I don't know how familiar some of you guys are from it, like so there was usually like 20 students in class and you basically work all night and day on a project for about two weeks and then you present it in front of all these people and then they basically criticize you for about 20 minutes and it's about, it's painful and terrifying as you imagine a lot of people were assholes in college. So it, but we try to do something similar without the other aspect of just like people's egos kind of getting away and a lot of it is geared towards some kind of comment or feedback that drives your design one step further, right? So constructive comments, something like, have you tried this? This isn't as clear as I think you're making out to be or like are you achieving like the goal that you're trying to do with this layout or this interaction? All those things hopefully give them ideas on where to go from there because the worst thing that would happen for a designer and for anybody really is to be like, I don't know what to do next. I'm stuck. It feels like it's wrong. I don't know how to fix it. So having the entire team kind of share that, share that experience, present their own work, help other people, not only makes our designs better but also makes us better designers because we're sharing knowledge. So like the technique that I suggested someone go check out to help with this particular, you know, site might help someone on another site in the future. So all those things are really, really important for shared learning because like you don't, like the group needs to get better as a group or you're just going to have a lot of issues where only one person can do the task versus like everybody can kind of jump in and chip in wherever is needed. One other kind of program that is kind of related to the like some of the things we spoke to before is the quarterly skill plans. We actually treat these like first-class citizens like projects. So there is a very easy tendency to be like, all right, you know, someone write in a notebook and then like, good luck, we'll talk a little bit later but what we try and do is basically like track these things and we use a program called Asana, some people love it, some people hate it but we basically put milestones, we say deadlines of when you're going to basically accomplish these specific goals and then the biggest thing is setting realistic goals. So like an example of a bad goal would be like, I want to get a better JavaScript. Like, cool, everybody does, like that's great. But like saying like, I want to write an API note or something, so that's much more tangible and it's much more attainable and it's much more realistic to say that versus like I'm going to master an entire aspect of something. So treating those like and having them like show up alongside like get this project out with I need to learn this this week has been like really important to make sure that it's baked into everybody's everyday life and it's made a huge difference I think for me compared to other environments where we try to do the same thing but didn't have that level of, that level of like checks and balances if you will. So again the one thing we want to talk about and like another way to really kind of make this much more much more ingrained in the culture and not like it's just like one group that's kind of like doing it is all of our skills are tied to compensation structure. So like if you put together a skill plan in a quarter and then you reach that plan we basically will give you a raise based on how many of those things you've accomplished. Sorry, did you have a question? Yeah, so I'll use one of mine for example like well actually no let me use another one. One was a designer who was like I really want to get better like writing, right? Like because like I don't know how many times you know but like writing is design is user interface like that is a very core skill that you need. So they set out a project where like alright I'm gonna write I'm gonna write specific like ads or like copy for a page and then like I'm gonna do the specific like a project where I help generate like the layout which in the like the labels and elements and stuff like that. So we would go through and then say it and then like they would basically put a deadline like alright this project will be completed by the first month maybe two weeks after that and then whatever and then by the time I meet with them again I'll be like alright how did it go? How much of this stuff worked? And then we'd be like alright you know since you did this you accomplish your goal you'll get like a 2% raise this quarter and then the good news about the way that we do the structure of the raises is that we don't wait till the end of the year to give you like a raise because you're you're already like contributing more because you've learned that skill. Yes. Yes. It's more like to-do list not necessarily like how many hours we're not like doing it to that level but just like kind of judging the success of the project and what they learned. Yeah for that skill or for that person. Well that's an interesting point too like at first we did things where people were like I'm gonna learn four skills this quarter and like it just was not tenable like we really focused it down to like hey you need to concentrate on just like one thing. Both. Yeah. Most of the time people would only hit one or two like and then like management wise it's hard to like if you have our team has started to grow and you're trying to manage like that many aspects of people's growth it's it's kind of tough so I mean there has to be somewhat of a business case it can't be like I really like you know bedazzling stuff like that's not like that's not like very useful to the business probably but like like so for instance I mean a more practical and like I really like I was into like learning more about VR stuff and I want to do like we couldn't really justify that like hey like let me go buy this two thousand dollar rig and get better at this to the company because of what our goals are but you know like I focused on in my personal case was like learning more JavaScript which is much more prayer but copywriting is a little bit more tangential design too and some of the guys have gotten better at like woodworking which is good for some of our product design members and other stuff so there is a certain level judgment of like it's not just kind of targeted towards your job oh no not necessarily not necessarily we don't think it has to be like the deliverable could be a made up project that I think it depends I think it depends on the goal I think also to you know we're talking a lot about software and design but the other parts of our business do this so like a real-world example for one of those is if you work in customer experience and you want to understand more about the operations so we have you know different shipping situations dark store FedEx you know all this other stuff we might say that that leader might set a goal for that person to learn about those things and then deliver them you know some write up about what they learn you know that kind of thing so for instance like some of our customer experience people would learn how to use SQL or write SQL to write queries to use to track things so they could build like their own dashboards to to kind of monitor some aspects of of their particular daily life so it definitely to your point it it doesn't always like be that direct and like it's a real-life project that like the business needs but sometimes like imagine not imaginary ones but like ones that are just like a little bit more fun stretch the person a little bit more so it's kind of like a value call on both the person and like one of us to kind of like say hey like which one do you think is going to grow you more or like basically get you farther along that path yeah that's a good transition I mean you know that's it that's the whole thing like we think it's an important investment we think it's great for the business it's great for the people yeah and I think sorry so the last bit is like one of the like one of our founders is a developer and that's where a lot of this stuff kind of like comes from like it was imbued in the culture from the beginning and it was very important for him to try and create an environment where often times a lot of us shift from job to job right we go every year it's a new job or something that's the only way you can kind of grow and we're kind of used to but I think his vision and a lot of us and why we're attracted to this company is that if you can provide an environment where people are constantly growing and you know obviously hit all the other marks of like you know their needs whether it's compensation or other stuff but hopefully they stay there for a long time 10 years 15 years I mean the idea is like you would be here for a lifetime that you we would be able to provide you with the opportunities and maybe that's slightly naive or like slightly optimistic but we would prefer to move with that intention and that vision versus like the pessimistic version where we just basically don't invest in our people and basically we figure they're going to leave whenever and just kind of like make it sort of a not you know just like a bad place to work yeah I think if you think about it job hopping is one of the symptoms of it one of the reasons why you do it is because you're bored you know if we can create a if we can create environment where people don't really get bored they always feel challenged and you know we have a better chance of wanting to stick around I know that's true for me we can open up to questions too thank you everybody thank you everybody