 John Arnold some of my teams running in late it's great thank you for coming to hear me talk today I want to thank RailsConf first of all for the opportunity to be here this is my first RailsConf it's been awesome it's great to be back in Kansas City I was actually born and raised here anybody else go Royals etc all the stuff yeah I'm from Kansas I'm not a huge sports guy sorry I'm from Kansas City I live in Nashville I was great to come home for a visit I got to see my mom because you know Mother's Day is this week so that's important go moms this is a good definition of how my my week has been thus far constant meat sweats from the barbecue but what we're really here to talk about today is growing pains in a small company that's what my talk is called or thinking big when you're small nobody knows growing pains growing pains okay all right fine okay so thinking big is fun but in a small company a small team we need to organize our thoughts our work and our team to be effective today startup culture has put a really bad habit into a lot of us especially those of us who aren't technical we start to frame out this idea of what a great trajectory of a startup will be we want to hire some code ninjas some Jedi some rock stars to come in really just some nerds at the end of the day to help us slam out an MVP we'll just slap a little business on it and before you know it will be in the unicorn club sipping our side cars and planning our second Mars base by the way doesn't Elon Musk just look like a supervillain right here you're coming to Mars kid alright so in reality though the teams that we build don't look like that and people have talked a lot about hiring already about how silly it is to call people that there's great articles out there about how what we're really looking to hire actually scientists and librarians ghostbusters no nobody's seen ghostbusters in this crowd okay fine all right scientists and librarians alright thanks we don't really have this rocket-like trajectory we have this startup curve that's been around for a while you know companies like ours were small we're like 15 people we're somewhere in this trough of sorrow we have some false hope wiggles that like give us excitement we hire people then we get big we do all the crazy stuff and there's these crashes all these things that start to happen you know Jeremy mentioned this in the keynote yesterday but what we're actually building is not actually startups at the end of the day we're building small businesses we're building companies and the latter half of this curve is not to get sold like I hate whoever wrote that that it's a buyer for me it's not really to get sold it's a build something it's going to be a sustainable team and a sustainable company that does not mean that we hustle no hustle no side hustles no weekend crushing blah blah blah blah no I don't want you to hero dev mic our CTO no more hero dev no overnight nothing like that I want you to be a cultivator I want you to garden I want you to lay out standards and defend them and be boring with the standards lay them out and stick to them so anyway about our company a little bit we're a multi-tenant SaaS company we're built on rails we sell our product to global insurance companies so big gigantic multinational companies that are implemented all over the world have terrible infrastructures terrible technology everything else and yeah it's great I love our clients yeah hi so we have a behavioral economics model that we use to incentivize insurance policyholders to change their life it's life I owe and we've we've done some things differently the biggest of which being like I said we're about 15 people but we're implemented with these massive massive companies all around the world our dev team is not that 15 by the way our dev team is like five people yeah so we're a really small team pushing out work that touches hundreds of thousands of people even larger as we're continuing to scale and we've learned that the product that we've built is really just the software part is really just a portion of the overall product the team and the promises that we make both to each other and to our clients is actually what matters with limited resources and constraints companies just like ours we have to bloom where we're planted and seek opportunities where they come in order to maximize wins we can't just go out and try to find something close it we have to make it work where we're at so we've we've been around for about four years and have come from a very small app to a little bit bigger app a little bit bigger team lots of things happening so I'm gonna talk a little bit about the tactics and the philosophies that we've used to get us those four years the first and most important tactic is to steal I am a certified stealing shit that works practitioner that badge indicates that that is a real thing you can get that on the internet it's great so we use frameworks that help us instill clarity vision focus value these are all things that Jeremy mentioned in the keynote yesterday we've stolen a ton of frameworks we've thrown a bunch out so these are just some that work well for us today jobs to be done we took this from thought bot and intercom like this week released a book on this to basically the question is what job is the user hiring the product to do what are we replacing in their life or making better by using software technology instead of something like paper what what motivation is happening for the user today it's a really simple question to ask we write about four or five of these for our users and about two or three for our clients what do they hear for what do they actually want they're very simple words they're very simple sentences they're not these huge long stories or press releases or whatever just like what are they here for we also use this great framework called six six six I call the devil's framework not really it was a devil yeah speak of the devil hey all right so really what this means this is a roadmap process this means six weeks six months and six years sales hates this six years no client will ever buy six years we got to buy tomorrow what's it gonna be tomorrow we can't do six years what does that mean so six years though is really in six years is really this six weeks what are our current team actions what are the things we're doing today six months what are the priorities that we have that are directionalizing us and then six years what is the world view like what is what is it that we believe unwaveringly that is that is really defining the product when you when you mix this framework with user interviews feedback team workshops other people have talked about that already this week it defines the opinions and it sharpens that worldview now what's cool is when you mix that with that jobs framework you man you get something like this six weeks we change with the user's ability then we start to change their behavior and then six years is really a question of how have we changed the user's life as a result of using our products and that right there especially those latter two things are what we can actually sell to a big client they get excited about this how do we actually fit into this picture and what does this look like how do we come along for the ride and the other result of this to is every feature that we build has a roadmap like this every big piece we know where it's going it exists in the platform for a reason and it has something that is an opinionated worldview at the end of the day that we have to define and defend otherwise we won't build it we don't we don't have time to build it all right so another thing we've stolen is a concept called fun day I think this was a ruby comp flesh here basically it's maintaining a list of nice to have items technical debt even though it's not always really that fun and things that we know we need to do but maybe don't have time to do right now what happens a lot in our team is we'll start down a new road we'll start planning some requirements we'll start building out something and we'll hit a block we're small we have to pause we have to get design which is contract right now we don't have full-time design to come in and help us with these things and so while those pieces are being built those blocks are being cleared our team dips back into these items for a day or two does something that they've enjoyed that they want to get back into and that balances new feature development that balances client deliverables with technical debt everything we've talked about right now is important because fundamentally I believe that every company needs a secret at its center as you can see here in this diagram Uber and Airbnb are canonical examples of this they have taken a secret that they they found in the world that individuals have unused assets cars and houses empty rooms and found that they can make money on them they built upon that secret and actually built software that sat upon that and made something great we have a secret I'll tell you we have a secret I think everybody needs a secret like that that informs and defines their worldview all of that fits into a list of the priorities that we keep so when it comes to actually choosing what to build what to market what to deliver we talk about these five things what do we believe in unwaveringly that we will never back down from what are improvements you can talk about 10x and all that kind of stuff where small improvements big improvements we can make on things we've just put out prioritize user research and feedback find things that are on vision from that feedback to put into the cycle and then scaling growth quality and stability those five things are how we prioritize our roadmap things we believe in sometimes involves things our clients believe in if they're paying us to do that it depends but the things that we unwaveringly believe in really really ultimately guide our priorities so a small company like ours we also have to sell a lot for us when we're talking about selling to clients it's really more like consulting someone who wants to buy your products and recent Howard said it's harder to get a law pass in Congress than to sign a big software client and I think that's absolutely true you have corporate layers and approvals and legal technology infrastructure procurement you have all these people that you need to get on board you have to pass their bars you have to go through all the different pieces to actually build something for them but like I said it's really at the end of the day more about consulting it's what are your objectives let's define those together we do client facing workshops where we meet with prospects and actually plan out what their objectives are for using software like ours and then after we know those objectives we've kind of coax them out of them a lot of times they don't know we coax those out of them and then show how we can use our software to help them we use frameworks like strategic alignment and design thinking and all sorts of things to really understand what their problem is and then show them how they fit into our plot to our our solution for the future back to the whole like six week month year thing we show them from that how they fit into the six month and the six year vision and how they can have their own version of that too for moving forward we also have to sell to our team we need to sell that vision and remind them that what they're working on fits into the product it's you know if it's a part of the marketing the overall experience the engagement the vision that we we want to talk that we keep communicating it gets the point of it being annoying to our team we talk about it so much it's like I know I understand I know we have to do that because it's very easy to get focused on one thing get a different vision of it and start to veer off course so reminding of how that one little feature that one enhancement that one fix is going to put another brick into the road for the future that's always how we have to sell sell new work to our team another thing we do all the time is we be as we're wrong I'm wrong all the time I have to talk to these guys I've talked to all sorts of people state my opinions state my research findings state whatever it may be and be wrong so in in terms of being wrong it is incredibly important to choose your losses and there's a very simple framework for this to follow to it's it's easy to choose losses with a client when they're gonna pay you for the for the change whether something you disagree with that's very easy to change your mind it's it's harder when it's when it's dealing with things the team's recommending when it's talking about you know directions we should take with partners integrations all sorts of things like that so how do you know what to be okay with losing it the way I think about it is in terms of micro and macro I've talked a little bit about vision or probably a lot about vision so far the grand story arc of your products this kind of macro arc that's six-year arc of where are we gonna be when this thing's all sudden done that is a place that you you don't want to lose that but in the micro and the day-to-day transactions in those smaller pieces there's things in there that can be undefined there's things in there that can change and that you can you can lose that in the micro those are places that you can experiment and fail and it's actually really great to make lots of mistakes here you can fix those mistakes quickly you can learn from them quickly and they don't actually impact much even though they might feel huge in that moment however when it comes to that large arc those unwavering things that you believe in those are things that you have to be resolute at and you have to be right at those so that comes from again user research client research all those learning pieces but your own unwavering belief in what you're doing and where that vision is gonna be you have to be right on that even if you give up on those small things another thing we do a lot of say no we say no to our sales team a lot we say no to our executives to clients to users to the team you have to say no more than you say yes Jeremy mentioned this in the keynote yesterday you need to build a mobile app we had that same thing investors want us to build a mobile app and our clients aren't paying for it yet and our users that'd be nice but they're probably not gonna need it for a little while we have to say no to that even though it's probably gonna get us more investment money it's gonna divert so many resources from us and take us off our focus that that short-term money is not worth that diversion other reasons to say no we have so many good ideas every startup does there's a zillion good ideas there's things to put into the product the team is really smart good ideas come out all the time we see competitors doing things clients are asking for things but you have to pick and choose and the way you pick and choose at this size is what's being paid for what are you being asked to do that's actually gonna keep the lights on and there's two kinds of payment that I'm talking about here yes clients and users who are paying us to use the software that's part of it but we also have to go where the users time is that is a form of paying to time and attention so what's preventing a user from onboarding what's pretty preventing them from coming back what's preventing them from loving the product those are the things that you should think of as being paid for because it's it's a user spending time with you and those are things you should be focused on again what supports the vision you have to prioritize ideas and work only on those that fit those grand future visions that you have and think in terms of systems so in order to get to this big feature these other pieces have to sit in first we have to put these next bricks in place first each of those steps you know X to Y to Z needs to fit into that macro story arc and needs to have a place when you write out that story we say no we also say yes we say yes a little less frequently than we say no but there are many things inside of those that we can enthusiastically say yes to these are the same list we just looked at just looking at it from a different perspective first there's so many good ideas our team is so smart and they're right all the time and they're really thoughtful and considered and they come up with really great things to do that will help us achieve the goal yes yes yes to that again what's being paid for even if the if it's something that we've disagreed with and the client's willing to pay for it something that we want to add on later new functionality that we have to change or do something else if they said if we said no to it a bunch of times and they still want it make them pay for it then do it then say yes it's easy and then again what supports the vision thinking about systems is incredibly important for the progression of features in a system is incredibly important for what you're going to be building and sometimes especially to leadership people who aren't in the team day in and day out those little steps seem like detours they seem like forks in the road that we shouldn't be going that way we should clearly be going this way but every one of those features gets to get to be expressed as because we have this now we can go build that and that's kind of the path we have to take another thing we do a lot as we change often we change processes all the time there's a couple of frameworks that we use here for this a couple of mantras that I have that we really hold on to here the first of which is happily dissatisfied this is something to keep in hand when we think about the work was I happy with our last release yeah I was pretty happy with it went pretty well was I satisfied with it no in no way was I satisfied was I satisfied was I happy with that last client interaction yeah that went pretty well but was I satisfied no that is a great place to keep yourself to go yeah we did well but we can always do better and better is really the mantra word underneath everything there's always something we can improve there's always a system or a process that we can we can use to make things better and we'll talk about how to pick and choose those how to fit those in with everything that will else we have going on a couple of easy process things style guides to me are actually the product that we're building our team needs to focus on repeatable styles that's you know on the rail side the front end the design the content style guides these minimize team frustration cut out guesswork and you know we learn that the hard way we're still learning it the nice thing though is you can pull out sample style guides on the content side Slack has a style guide for how they talk to their users in the app take that use it tweak it to fit your own voice but you can start with that it's a complete thought it's done other other style guides like that exist all over the place that you can you can take and modify to your own purposes so the style guides like I said those really are the product and the software that we build that users and clients interact with is really just the expression of that product so focus on style guides they're gonna be way more repeatable way more extensible than just one off request what are ways you can make things repeatable and and find ways to build features and build functionality inside of those style guides for the future Rebecca talked about this before she did a great job about this defining processes when you fail when you're small this is the main opportunity that you have to build a process you know we're we're a small team like I said we don't do in terms of our like product development process we don't do story points and we don't do estimates we don't even do structured sprints we tried because I came in and was like oh it's tight let's do all the stuff and put on the tie and make it all fancy and it wasn't needed and it took so much time from our team that it was less focus on the actual work it's what we call the work of the work as opposed to the actual work so working on the work and doing the work are two different things and at this stage we have to focus as much on the actual work as we possibly can so put in in place only the processes that you need to prevent failure and extending on dry don't repeat your mistakes when you have a mistake stop and talk about an institute a process there's a zillion processes out there for those things but you have to step in the trap before you you institute the process otherwise you're just waste time so Rebecca talked about this but I want to talk about this to postmortems it's it's a great yeah it's a it's a great place to to talk with your team when things go wrong or when they go well and this is probably the most structured thing that we do is a retrospective with postmortems running a good postmortem takes two things objective facts so Rebecca said some great stuff about this I won't go too much into that but basically objective facts about the failure or the success statements that explain the story it should be a really boring story listed out as a series of sentences the client asked us to do X we responded with this document then this happened then this happened it shouldn't be there shouldn't be adjectives there shouldn't be lots of names it should just be these facts and events happen and then the team people who are involved with the failure or the learning do what's called a plus delta exercise and all this really says is for each of those objective statements plus what went well about this what are we gonna do again about this and delta what needs to change for the future how should we build something differently for this and this right here is where our processes come to life we find those things that we need to add so that the mistakes don't happen again this process takes maybe half an hour and we make few enough big mistakes that we can handle one of these every few weeks and it's no big deal but it sets in motion a lot of good processes and best practices things to add to our style guide to our implementation process to our deployment process that we make sure that are gonna happen for the future sound good feeling good okay okay all right other things we grow slowly slowly grow slowly it's very easy to get money and go we need to hire a bunch of people we're gonna be awesome we have this crate we want to make a Mars base here we go it's time to make our Mars base no you have to grow slowly and you you might be able to extend or add to or augment your team and the work that you get done but you shouldn't think now we can turn this turn this thing on and start churning I I'm saying this to myself a lot too because I want to grow fast and we have to be reminded to grow slowly seriously more slowly than you want to there's been some great talks about hiring Eric and Joe I think gave some great talks about this this week but a couple things that we've kind of stumbled into and found worked really well hiring generalists or people who have switched careers is great as you start to grow people who can do multiple things in the organization and people with history and other areas that are applicable to your team we have a developer here who was an editor that's really helpful for our content side of things developer who was in the health care world we have kind of a health slant or app so getting people who can help out when there's other things that need to happen because our team small we don't have people who are focused on those things sorry I'm making you nervous and talking about you too okay alright so this is another thought-bought thing that I stole but t-shaped people t-shaped people are people with a high level of specialty or experience in several areas that would be applicable to the work that we're doing and one deep specialty obsession passion fascination curiosity that goes deep in one area I want to come in and I'm really interested in wearable devices I really want to focus in on that but I was I did some project management I did some this I did some this in my few in my past that is a person that you want to look for who's gonna take the team further as you continue to grow more about growth I always say it's better done okay I don't always say this it's better done okay than done great by somebody you have to lay off later grow slowly don't over hire focus on the roles that your team needs not people people are expensive and you hurt them and they stay with you until they run out of things to do roles can be played by by multiple people you can have multiple hats today okay and yes it might be a little bumpy but using the failures and shortcomings of those roles will define the job description for the person that you need for the future does that make sense so fail to build the thing for the future okay last big thing this is a great concept there's a company called infusion soft they're based out of Phoenix I think they use PHP which you know whatever they are awesome they're a small business CRM they have a gazillion clients and they started in couple dudes garage like classic startup story and they have this great wall it's actually some doors in their office and they call this their Everest mission basically what this this the doors where maybe you see is it went mission vision their core values what their purpose is as a company and then there were there were summits each year that showed where they wanted to be as a company the size the number of clients the things they wanted to do the different milestones that they want to hit along the way first off awesome that it's that visible this is the main doors to their conference room like their big all hands conference room everybody sees this at least once a week everybody's reminded of this it is physically printed in the room so that people can see it but second on either side of this thing are huge boring spreadsheets they printed off that have a list of key objectives key results people's names and timelines for every single thing that was on that on the bottom parts of the door and what's amazing they printed this like four years ago and they hit those numbers like dead on every single year I can't say on the finance side of the business side about all those things but in terms of achieving the growth goals and the team goals that they wanted to meet me they use an OKR process Intel I think started this but Google made this really famous objectives a company provided goals so those six months future views the months like what are our current priorities and then key results the way we implement this is we assemble teams within our company we're small teams there's not that many to begin with but a few groups of people to focus in on one of those objectives and that group writes the key results we don't force it down their throats we don't say this is the stuff you got to do or you're fired they come up with how to achieve the goal and all we do is check in and make sure that that's working and make sure that we're hitting it so what that does is it gives the team ownership it gives them those clear objectives and it shows how they fit into the big picture it lets them find their place and blossom inside of where we're blossoming and it gives freedom to fail to these are not like performance review we're going to look at these once a quarter or annually or whatever these are things that weekly we are checking in on and measuring against and making sure that they're moving us in the direction that we want to be so remember pursue your vision relentlessly be annoying and talking about your vision your clients should know it your team should know it your pets should know it everyone should know it and everything you do should be part of your talking points be systematic and completing it what are the pieces that lead to the next step now that we've done that we can do this once that's done we'll be here and then you rattle out the vision again always there choose your battles don't be afraid to lose you can lose now losing is a learning opportunity to growth opportunity losing in the short term might mean that the client sees you as flexible and willing to work well with them and wants to continue the partnership that's worked with us we did concede a lot to grow a lot speaking of growth change often but grow slowly let your team define its own path based upon those key visions and hopefully it all fall into place questions