 All right, we're gonna go ahead and get started Never our talk is sustainably awesome how to build a team so when I started at hash rocket I came from a place of great pain it was government work doing net and just got to the point where I realized that Spending 40 hours a week which is more time than I spend awake with my wife and I don't like the people that I'm working with so much anymore So I sought out a different opportunity John Larkowski just moved to hash rocket and Find out that they had an opening and went over there with him Hi Hello Hi, I'm less hill. I was introduced to Ruby and rails in the fall of 2007 My friend and fellow rocketeer West Gibbs had been using rails for a while and he convinced me to go to the inaugural Ruby Jacks meeting That was my introduction to the unique and vibrant community. That's grown up around Ruby We also met the people who would go on to start hash rocket nearly 2008 obi desi lark and tiger They exemplified the spirit of Ruby and rails getting it done fast getting it done right having fun while you're doing so This started my adventures with Ruby and rails by March of 2008. I'd built three web apps. I'd contributed a little bit to Hamel and obi At that Ruby Jacks meeting announced the hash rocket. We're hiring one week later. I was the seventh rocketeer So when we started hash rocket We had the idea that we could build some awesome products and get rich doing it I think most of us have that that dream But after a few launches that were successful and a few payrolls We realized that we had to pay the bills and therefore we've said let's do some consulting to get by and ultimately Practically, it's got shelved during that time Became apparent that with consulting we could do 40 hours a week. We could do a sustainable pace and have the The boat trips on Friday Idea so basically we took the easy way out Let's see if this works. Does this work? Yes, great We learned some lessons about building a successful software cultural along the way We're here to share some of the lessons that we've learned So that you too can build a sustainably awesome team So hiring the right people is critical to building your awesome team Openness and transparency are essential to keeping the trust and focus for your organization to keep your awesome team going That's how many awesomes in a row a lot of awesome All right, so participation and giving back to the community give your team perspective and an opportunity to grow Agility it takes practice and discipline. I think we heard about that from Glenn this morning But when done well makes for an awesome development team and a comfortable productive environment is crucial to nurturing an awesome team So let's start with some of the things that we don't do Developers have authority and responsibility to get work done. It's on their shoulders We don't penny pinch. We have a budget and we stick to it data point we have about We have a weekly grocery bill runs about $400, but the well-stocked kitchen. I think keeps us from leaving the office and keeps us energized Sustainable pace is not just a phrase. We pair it So we have no meetings at hash rocket well Except the daily stand-up the daily project stand-up and monthly machine control and the hashtag away and book club book club so we have meetings But realistically your day-to-day Working environment is one that you're not stuck in meetings all day long You have a daily stand-up with everybody that typically last five to ten minutes You have your daily stand-up with your client She can last anywhere from five minutes to you know, 15 or whatever depending on what they want to talk about We remain as flat as possible to this day, or I think we're about 40 people now and we're still Basically as flat as we were on day one So no future-proofing Future-proofing Well, if you fireproof you keep the fire out if you weatherproof you keep the weather out So if you future proof you keep the future out We love the future. We're excited about the future But you know kind of taking a lesson from software development you are not going to need it so we don't future-proof So this is a picture that we took recently and it is not the entire team In fact, there's some visitors in there as well with people from Sweden Wow, that's really hard to see people from Sweden people from Germany We have you know a lack of people from the Chicago office and the Chile office But as we started preparing the talk it was a really a good picture of you know the team at the moment and We'll talk more about this picture as we go along So this is a picture of hash rocket. It's a picture of our culture This picture is in fact a cultural artifact cultural artifact a cultural artifact is how we know about cultures both past and present But they are not themselves the culture Remember Israel's maturity model See like the entire hash rocket table and nobody else So the idea behind RMM was that it was designed to capture best practices and that best Designed to capture practices in the rails community and the best practices would emerge RMM is dead No, it's not doesn't think it is it's mostly dead if you go to the RMM site You will find it. Thanks to heroku Let's take a quick digression on cargo cults I think everyone's familiar with the term cargo cult programming that is programming with little to no understanding how the code you're working with works This term is most well known because of the John from cult This is a religion that arose in the 1930s in the South Pacific nation of Vanuatu paradise basically The movement was heavily influenced by existing religious practice This was the worship of ka rap Ramune a god associated with Mount Tukos Mara During the Second World War some 300,000 American troops arrived on the islands of Vanuatu And they brought with them a lot large and just endless amounts of supplies or cargo After the war the followers of this John from cult which predated the Americans arriving in an attempt to attract further Deliveries of good would engage in ritualistic practices such as building crude imitation landing strips the aircraft You see here radio equipment and then they would sit there and mimic the actions that they had seen the Military personnel take in an attempt to get the cargo to come back So looking back on our them What it turned out to be was a collection of cultural artifacts It was designed to capture practices and that's what it did it didn't capture the context of Why or how these were making us successful or making other people successful? They were easy to pair it, but they lacked the rationale and context to make people adopting them successful So given the time constraints we're gonna cover empowering developers trusting your team and what's important about methodology and how to hire So early on John Larkowski, and I were actually working on a a bash script and We were cleaning up some old files or whatever some images that were temporary images and what wound up happening is we accidentally forgot to CD up the directory and So we ran the script and it ran for about two two and a half minutes and then we're like Can you guys hear that? Anyway Yeah, basically we had started at root and started removing everything and Because we didn't you know have any need to you know confirm the temporary images that we're deleting we at RF and So what would your organization do when they're faced with this? The Institute of policy where the developers don't have access to the access to your boxes Would they say just don't do that? Or would they Is that not going I think you've got a range problem. Yeah, I'd range Develop a backup solution. Basically, would they know that this is going to happen in the future? Protect you from yourselves to some degree and just make it easier to get back up and running And basically the moral of the story is don't come to your developers There's an awesome quote by Clay Shurkey Which says process an embedded reaction to prior stability and That job that I was talking about earlier the government job. That's 9 to 5 that was an embedded process because people before me were stupid and I was stupid So trusting your team here's another story One of our clients came to us after having spent about six months and two development firms to get What was basically a very detailed requirements document tons and tons of high fidelity mock-ups Lots of diagrams, you know event diagrams all sorts of UML diagrams And some software that didn't work And on top of this The good news that there was this spectacular looming deadline that about six weeks that they needed to do a demo They were meeting with Facebook to show them this awesome app that they've been working on for the past six or seven months And it would literally make or break the company company. So in desperation they came to us and said, you know What can we do? So how did we do this? How did we help our client? Well, we called everybody together and said everyone listen up This is an emergency. We're not going to pair and we're not going to write tests Of course, we didn't that's not what we do Forced heroics are going to destroy the trust and confidence of your team and they're actually going to lead to poor results We know this So instead we listen to the client we help them craft a minimum viable viable product This minimum viable product was not in their mock-ups six months, and they were building the wrong thing We worked at a sustainable pace This picture although it looks like it it's at night is from that effort and we are Working in a room with low light, but it is actually the middle of the day We did iterative design and development. We did outside-in testing. We delivered working software We kept to our process the process that we know works has worked for us in the past continues to work for us today We met the deadline that company is now one of nine Global Facebook partners for their ads API, which is kind of a private API that only certain people are allowed access to and The lesson here is stick to what you know is right even when you're facing significant pressure Whether it's money or deadlines or what have you in addition to reinforcing the trust and confidence that you need to have An awesome team it lets the team focus on what they need to be doing which is delivering software So another story in the early days of hash rocket. It was pretty obvious that everything was sort of up in the up in the air We didn't have other than some some basic, you know, we wrote story cards Everything was sort of exploratory and we were able to you know try different things and make sure that We were getting the best solution that we that worked for us Early on our story cards are written on three by five cards. I'm sure a lot of you have done this Basically when a story was picked up to be worked, we'd go to the board We'd pick it up off the board. We'd move it to the other swim lane and then we'd be working on the board This worked very well for us Of course until there's one person that's no longer in the office In this case you can see Barely that desi is remoted in from Chile So the idea that somebody is working on those same cards, but doesn't have access to that wall It was a new requirement for us so With these new requirements, we had to evaluate situation and adjust So in early 2008 we started using Pivotal Tracker. Who use Pivotal Tracker? Cool And that's so we started using Pivotal Tracker and Pivotal Tracker is awesome. So therefore that's the end of our story Of course not Once we came comfortable tracker. We started evolving our story formatting process. We started just addressing everything and We began to understand tracker differently So when we had when we started we had this blank slate everything was sort of up in the air and We had some experience to draw from it to pick the to evaluate things and pick the best things that worked for us So what's changed since then? Nothing We still challenge what we're doing on a daily basis. We do what works. We try new things We we try new things if they work we keep them if they don't we throw them out save me less hiring So talk about hiring Hiring decisions need to be made with hard measurable criteria if you're hiring someone because you like them you're doing it wrong Passion accents excellence do not come cheaply they take hard work and diligence Someone who's phoning it in someone who's coming in and and not really doing the work It takes that awesome and passionate team turns the dynamic around The slackers thinking they're lucky stars that they have a job and the people who actually make the environment What it is are looking to make their next jump So everyone should know who this guy is this is Joel Spolsky of Vod Creek software He also writes the Joel on software blog and one of his most popular posts is entitled the gorilla guide to interviewing If you are hiring people and you have not read it, you should do so His advice is to look for people who are smart and get things done. These people are passionate They love to communicate. They love to explain what they're doing both to other members of the team and to anyone who will listen They often take leadership roles in what they're doing They have a history of getting things done. They ship software. They solve problems. They contribute to OSS We think everyone should hire people who are smart and get things done But there's one more thing They need to be a great cultural fit There are many creative innovative passionate people out there But not all of them will fit with your culture We've actually I mean we've had this at hash rocket where we brought in people and they just weren't a fit You know, so they were not good just Didn't gel. Yeah, exactly. So you spend 40 hours a week like I said earlier Make sure that you have similar values make sure that you get along and it'll make work a lot more enjoyable so we put a lot of thought into how we hire and We spent a lot of time with the candidate before we make our decision and that gives us confidence to Make sure that we're making the right decision Sure To start we distribute the potential candidate's work to multiple reviewers for those candidates that we are interested in we continue up with the Phone screen and dive in deeper on a couple of points that we might have found there And if they're still interest on both sides Then we're gonna ask the candidate to come in for a week-long interview on site with us pairing and participating in the culture of hash rocket So Examining the work a candidate has produced is obviously more effective than reading a resume I think this is self-explanatory, but I'm gonna tell you some of the things that we're looking for So for our candidates, we're looking for a mastery of Ruby and API's We're looking for their testing. Are they writing good tests? Are they writing bad tests? Why are they writing bad tests? Maybe we can kind of see what their thinking is in the code We look for common idioms. We look for known anti patterns, right self everywhere is one that I love Clean and simple code that is easy to read well factored code In fact, we like to look at code and kind of walk it back through the commits github is great for this We love github. We look at the commit hygiene. We look at the tools and libraries being used Can you describe githi gene? The commit hygiene so when you do a commit what are your messages? Are they oh my god? I don't know what this is doing or they actually clear concise Documenting commit messages, right? And that's what we want out of the software that we write so when we look at other people's software That's what we're looking for So we also take a look at their online presence Twitter github blog whatever For a sense of what they think is important cool and interesting in software at this point What we need is a passing grade And at least one person to be excited about bringing the person in Once they get past that review one or two of us will do that phone screen and there's not a whole lot of structure to that we just get on the phone and Make sure that they have an idea what's going on Well, it's possible to see We just want to We want to what we want to do is get some open discussion and honest reactions To what we found interesting when reviewing that person's work We're also getting a peek at the communication skills, which for us is terribly important because all of our developers are Consultants so you will be dealing with clients Finally we do have the week-long interview This is a one-week gig we provide accommodation and we expect that you are here to participate So there's generally an after-hours component just about every evening whether it's happy hour or perhaps Improv if that happens to be on while you're there Something like this absolutely and you know we we have happy hour. No, not everyone drinks. That's cool During the week's candidate pairs with one to two people every day The pair is expected to have something interesting to work on so we don't want to pair you up with somebody to learn How they work and then have you doing tedious, you know CSV changes or whatever Or setting up a slice on engineer would have you the so the candidate is expected to do a fair amount of the driving And at this point we're presuming they're smart or evaluating if they get things done and if they're a cultural fit So the things that we're looking for we're looking for coding ability. We're looking for design sense. We're looking for refactoring skills We want to see your work style. We want to see the attention to detail We want to see the openness to different ideas in different way of doing things because chances are you're not doing it the way we are we also look for Adaptability to pairing to outside in testing to them if anybody was in the VIM talk earlier Tracker and stories to the environment, you know We're these people are gonna be working with the clients. Are they gonna be able to do that? And we want to see their problem-solving style Even people who are not pairing with the candidate are expected to seek out the candidate and get to know them a little bit There are gonna be plenty of opportunities during the week to make that happen everything from You know going out to lunch or the happy hours and going to dinner going to dinner So how do we decide who to hire? We asked the team and we asked the team are they smart do they get things done and are they a great cultural fit? If someone says hell yeah to all three of these questions, they own that decision They are excited and invested in making that person succeed This is gonna be especially important at hash rocket and a lot of other software development cultures because we don't write Things down knowledge is conveyed through conversation observation and participation. We learn from each pairing opportunity Each pairing opportunity some new technique is now brought into the fold and over time We'll get spread throughout the entire company. This is how you build your awesome team one hell yeah at a time So how do you build that awesome team what we just told you but now we're gonna tell you what we just told So by hiring people who are smart good things done in a great cultural fit for your culture By having open communications that are going to foster trust and organizational focus Participating in the community and giving back get gets developers energized and motivated and they feel connected Being disciplined deliberately practicing and continually evaluating your software process Investing in your equipment. I don't know if you guys know, but we actually had a couple of robberies this spring and In the span of two weeks we lost eight nine IMAX something like that and The what we did was we went out and we bought new IMAX because it's that important to our culture Right, so that does that mean that you know if you guys don't have IMAX that you need to run out and buy them No, but that's one thing that we value right So creativity and imagination make the culture of your team foster these and you will be successful any questions We use work beast calm We use Typically we we actually use We just put out an ad in GitHub when they when they launched jobs We put out an ad and we put a posting up on workbeast A lot of times we'll just tweet and we'll get people coming in that way We've got a number of developers following us and some people might have itching to move so Yes I Don't think it's Vim either and I think that's a great point This is actually why we brought up the point about cargo culting and The issue is that it's not any particular practice. It's not using them. It's not using pivotal tracker This isn't what makes you successful. It's the kind of the meta around that right so practicing diligently right being disciplined Sharing the values in other words if you have a pair where one person thinks that test first is awesome And the best thing ever and the other person is saying I hate writing tests Where's the productivity in that pair? I'm telling you it's in the toilet, right? So having those same values even if they are we all love Vim Those add up and they multiply together to give you that awesomely Successful and sustainable team. That's really the message that we're trying to get a cast Maybe we need to work on that because it only came up at the end But I definitely hope that that's the message that you guys are getting which is don't copy exactly what we do But kind of take the meta idea of you've got to really think about what you're doing Think about your culture Understand the reasons that you're doing these things and kind of be deliberate about it. Do you have something to add? Absolutely in fact it was probably less than two hours ago that we took out the firing slide I could bring it up if we wanted but the basically the point is even after we go through that interview if After a time somebody turns out it doesn't that they don't fit, you know, they're not bad people They just you know for whatever reason they don't fit whether it's culture or you know, what have you It starts to become apparent to everybody involved and you know, it's not productive to It's not productive to leave that situation faster and So I would recommend firing fast, you know once you realize that there's a problem and Do I talk about the remote office and we've got some time so What we shrunk down our talk we had More stories to tell one of them That's kind of a net all of the stories that we told were kind of positive stories We did have a negative story to tell which is still in in play. We haven't resolved it, right? Everybody may know or certainly I'm going to tell you now that hashocket has three offices We have our main office in Jacksonville Beach, Florida. We have an office in Santiago, Chile. We have an office in Chicago those two other offices are new offices and They're staffed by I think two people currently in Chile had been for And then four people in Chicago Three had been for three had been for and in fact It's it's creating a little bit of a problem for us at the moment because the way that we share this culture is through that daily interaction through observation of you know, what other people are doing and We haven't got a great solution yet to being able to Communicate being able to observe what people are doing in the remote offices and vice versa, right? We have a real dichotomy between the people who are in Jacksonville Beach and what they think is good and what's Important and the people in the remote offices and how they're working and it may actually only be perceived in other words We feel that the folks in Santiago and Chile are producing great work but at the end of the day We don't have a solution yet that kind of gives us that confidence that the Culture from the original hash rocket has transplanted successfully to the remote offices That's a great question and I think ultimately you know, we've got some people that have gone to each office from Jacksonville and The the culture is going to be different in Chicago because Chicago is different. You know, there's not a big beach culture and whatnot So it's going to be different. We're not saying are they exactly the same? But do they interact well together? You know if somebody goes from Jacksonville to Chicago Are they able to just go in and work and and be you know be successful on a day-to-day basis and you know can we converse and and Get along right so like one of the things that we haven't mentioned But that's kind of a bonus at the Jacksonville offices because we work in open war rooms Oftentimes someone will just kind of kick back from their workstation with their parents a hey I got a question to just kind of address it to the room And then the folks who are interested in the question can pipe up and say oh, yeah, you should do X or no You should do wide maybe in fact a whole Disagreement and argument may occur but eventually there's an answer going to come out You cannot do that with the remote office and then of course that answer is local and until that answer kind of percolates out Right, that's going to take some time. This is the kind of stuff that we're That kind of gives us the grief, you know where our angst is around these road offices Yes as much as possible in fact I recently went to the Chicago office and It was striking to me how different Stand-ups were how different they felt because when you're in Jacksonville everything started live-action and in Chicago you watch it through your monitor screen and We actually we have a microphone that we pass around and It's you can hear exactly the person talking you don't get to cross chat So they do participate they absolutely get less out of it, you know, and that's that's terrible But it's a situation that we're trying to solve Any other questions? Yeah Sure and Again, this is what we do because it works for us So, you know, take take the practice. Maybe you can only get people to come for a couple days or whatever But and maybe they don't come to you at all, you know, do what works for you But spend that time with the person however you can You know when we started we were doing three to ones and we had guest stars So we had people like thought bot Shopify Hampton came in and the og consulting guys came in for a week And that's really where that came from is spending a time with those people We really got to know them actually boosted our skills a ton So any chance that we got to co-work, you know, we got to know them and we knew whether or not we could work with them You know a longer project or what so? Who were we though as a you know, four-person consultancy to say hey take some time off work Come down and work with us. There was a financial incentive for sure. We paid them But that's about all that we offered Yeah, I think it was because we valued it right we felt that that was the right way to hire someone is to make sure that you Are a fit or as much of a fit as you can possibly be before you actually hire them You add it to them to the person that you're hiring you owe it to yourself to do that I think another thing that we do that's kind of in the same vein as we have an open-door policy And this may be something that might be Solution for you guys which is have an open-door policy Let the people who are interested in you come to you get to know them that way and then if you have openings you can say hey You know John You were here six months ago. We've got an opening. We'd love to have you come back. Are you interested right? I mean it gives you in that opportunity to get to know them first, right? And I'm just thinking you know just right now, but In fact, we have an open-door policy if anybody's in the Jacksonville area Chicago area Actually, you know come on by and as long as the room as long as there is room You're more than welcome to come in and work with us. There'll probably be an NDA. You have to sign or whatever No, it's it's we have as flat as possible really the only delineation we have is we have Developers front-end developers because that guy doesn't want to be called a designer and designers But it's as flat as possible. Yeah, and also our practice is test first. So We are effectively our own QA department Yep I'm saying good question. All right For us it's been we haven't really had much of a problem with it You know people that are taking the initiative to come work with you typically, you know, they want to spend time with you You know if we have Developers that are doing open-source work leave and pair of them You know, we've I guess I'm struggling to come up with an answer for you because it's not something that we've seen a lot of problems with Yeah, I think it's a matter of setting expectations correctly, right? Which is have the person expecting to come in to work whether they're going to come in to work on their own Stuff and just be in the environment or whether they're going to come in and pair with somebody on open source Right, that's something we really didn't touch on but you know hash rocket supports open source And we get time to work on open source. So folks would you know There'd be an opportunity for that when someone's coming in and we can work with them, right? So if you give us a week's notice and we know you're coming in then maybe someone can say hey You know what I want to do that new release of my gem. I'll work on it with this guy when he's coming in Thank you