Em Campbell-Pretty on Scaling Culture and Greg Koeberger on Building a Culture You Want to Work in

00:16 Introducing Em Campbell-Pretty

00:16 Shane: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. I'm at Agile 2019 in Washington, DC. And I'm sitting down with Em Campbell-Pretty.

00:33 Shane: Em, Welcome. Thanks for taking the time to talk to us today.

00:35 Em: Thanks for having me Shane.

00:36 Shane: Now, you and I have known each other for a decade or so, I suppose.

00:40 Em: Yeah, about that. I think we met at one of these events; somebody's rooms, maybe drinking something ,anyway possible.

00:48 Shane: It's distinctly possible, but I suspect that a fair number of our audience haven't come across you before. So, would you mind a brief background and introduction?

00:58 Em: I primarily work with Scaled Agile Framework, that’s probably what I'm best known for. I'm a SAFe fellow. Apparently, there's only 16 of us. So that's only two women. Someone told me a SAFe fellowess. So that kind of means I've been doing this SAFe thing a long time. And my claim to fame and my introduction to that world was launching Australia's first implementation of  SAFe, which was at Telstra in early 2012, before it was called the Scaled Agile Framework. So, what we had done at the time was read a couple of books by Dean Leffingwell and decided that was going to solve our scaling woes and launched an agile release train. And it did solve our scaling woes. Had a lot of fun with that, and we had a lot of fun transforming our culture. So off the back of that, I went on to start my own business, which I named after my blog, which is prettyagile.  I've been writing and launching trains and having fun and changing cultures ever since.

01:56 Writing - you've got one book. Tell us about that one.

01:59 Book – Tribal Unity

01:59 Em: Okay, my book is Tribal Unity. It was released on the 27th of October, 2016, isn't it funny how you remember those things, in Denver, Colorado. My book is really about cultural change. One of the things I've found over the years is if you change the culture, the rest will come. So, I had the great fortune, or misfortune as it may be, to work with an organization where we had about 150 people who didn't know each other's names, but they'd been working together for about five years. When we went to agile first, that was still the case, they were kind of all independent agile project teams and then started playing with the agile release train. And we started working on how we create team of teams culture. So, I think most agileists, we know team: seven plus-or-minus two, give them a name, take them out to lunch every week, do some bonding. How do we do that to 10 teams that all need to be one team?

02:58 Scaling culture beyond single teams

02:58 Em: So that is the premise of the book. So sometimes think of it as scaling culture, because we're so good at that team level culture, and how do we scale that team of teams? Just based on a whole heap of patterns that I've used over the years. It's interesting, people are really quick to go well, that's a technology thing and I said, actually, you should probably have a look at that book. Because I'm pretty sure there's one mention of technology, which says, if you're going to do software development, you should use XP, that's good advice. Everything else and all the patterns in that book will apply to any type of organization doing any type of activity. So, I even just had a chat with someone earlier today at the conference who said exactly that thing to me. Yeah, that'll work for software, but what about legal and HR? And I said, guess what - it all works for legal and HR too. If we can form solid teams, create connections among those teams, right leadership behaviours, right leadership mindset, we can make a difference. So possibly it's because I come from a different world, I see it a little bit differently. So unlike most folks, I don't come from a technology background, I come from a business background. So I think what people often they hear me talk and they go, Oh, that's what we do with technical agile. And I go, well, that's nice, I don't come from that world and that's what I do too.

04:14 Shane: So at the conference, you given a couple of talks: learning from the books, you said you read,  ooh, embarrassing - how many of these books are on our bookshelves that we haven't actually read yet?

04:25 Learning from books you said you read

04:25 Em: We took a poll at the beginning of the talk. We established that we had a room full of people with guilty consciences who had come to work out how to solve for we go to conferences, we collect names of books, we can now buy them instantly online with our Kindles, but, you know, do we actually read them? And if we read them, do we do anything with that reading? I had a bit of a premise over the years, in fact, I started telling you about it just before, when I started doing Scaled Agile, I'd read a couple of books because there was no ScaledAgileFramework.com. There was no Leading SAFe, Implementing SAFe and whatever other classes. There were just these books. We slowed the conversation right down and we ran book clubs, where we took a chapter a week, read the chapter, discuss the chapter. We liked this idea; do we implement it? Do we like this idea, do we need to change it and implement it, or do we not like this idea?  So very, very deliberate about learning. Very, very action oriented in our learning. And it became part of the culture that we have at Pretty Agile. We read books and then we run experiments based on the ideas that we liked. So we thought that might be interesting to people. Part of my premise was when I read a book and don't take action, I know I've read it, but I can't remember it, when I read a book and do something with it and that something can be, use it to teach, I use it to run a workshop, I do whatever it says ,then I remember it. So if I want to retain my learning, I've got to have a bias to action about how I read. That was the journey that we took that group on yesterday afternoon. I shared with them some books that we'd read, most of which they hadn't read, so they got a few extras out of that as well. That got them thinking about what they were going to do after this conference in terms of not just writing down the names of books or buying the books, but actually reading the books and then taking action based on that.

06:18 Shane: And your other talk, is there a place for individuals in enterprise agility?

06:13 Em: I hope so, maybe

06:28 Shane: There's something about individuals and interactions in a manifesto somewhere. Is there a place for individuals in enterprise agility?

06:32 Em: I think for me, the space of enterprise agile and scaling agile seems to be a space of frameworks. There's this framework, there's that framework, this person's method, and then there's a build your own framework, and then there are the various big consulting shops with their various approaches. And I'm not sure any of that's actually helping us. The other observation is the bigger the enterprise the more we seem to lose focus on the individual and the individual connection. The conversation we were having earlier today with that group was really about one that says, can we have agility without respect for people, and what does respect for people look like? A lot of the conversation was about the economic benefit of respect for people. So what enterprises like is economic benefits, so while I think we know a lot of things around, it's important to communicate and it's important to train people and it's important to have cadences and collaboration and all these things, but why is that good or how does that help our enterprise? Well, they all have economic benefits. That was the little thread we were trying to draw through for people earlier today. Respect for people, it's a leadership choice and it's a good economic choice.

07:56 What does respect for people look like in an enterprise context?

07:56 Shane: But what does respect for people look like in an enterprise context?

08:00 Em: We actually started by talking about what it doesn't look like. Aren't we good at talking about what things don't look like as opposed to what they do look like? So Brene Brown's session in Melbourne on Friday, she starts with, we asked people what vulnerability it looks like, and they tell us what it doesn't look like. So, of course, that's now what I'm going to do. So, it doesn't look like people working on five six, seven, eight projects or five, six, seven, eight teams. It doesn't look like you will go and do this method and you don't need any training cause we can't afford that. And it doesn't look like we have an offshore team, but you know, they're the offshore team, so we don't really worry about including them in things.  It doesn't look like a two-class society. What organizations do differently is they create a culture where there is no second class citizens, that if you do have a distributed organization, that there is a compromise on both sides, some people come in early, some people stay up late. We deliberately make time for connection. We prioritize making time for connection over getting the next amazing product out the door, because just a little bit of time, just an hour, a week, a sprint, a month creates some human connection between people. Organizations run on networks. We want to go faster. We want to increase the speed to market. We don't have a social network. If we don't have the social fabric, we can't do that. So we invest in learning. We invest in innovation. We invest in people. We create the right environment.

09:36 Shane: Sounds good.

09:38 Em: Not sold?

09:39 Shane: Well, maybe I'm sold, do the shareholders like it?

09:43 Em: I didn't ask the shareholders. I think for me, it's, I don't like to say leap of faith stuff, but I don't know that I have a better word for it. One of the things that we do is we suggest organizations use innovation time. So carve 10% out of every sprint across every team and give it back to the team and say, you can use that time any way you want, as long as you're using it to get better as a team or as a broader enterprise. So you can work on technical debt, you can go and learn something new. You can start a book club, you can go to the gemba and see how your customers are using your product. You can do anything that will make you better. And absolutely people ask me, but how do I pay for that? Well, you build it into your operating model because the payback is so significant. How do you prove that before you do it? I don't know, but you can always run an experiment. So it's not that you have to say as of tomorrow, my entire enterprise is going to take 10% of their time and put it in improvement. We can pick a group, we can pick a department, we can say, we're going to do this for a month, we're going to do this for a quarter and then we can try it. I've never had anybody try it and not say it has benefit. And it's as simple as anything you do to get better is going to start to improve your throughput. You shorten your lead time. It's a win, win, and people like to work in environments where they have that freedom, so we're now starting to get to employee retention, places people like to work, attracting talent. So it's quite a compelling economic story, in my view.

11:27 Shane: Cycling back around. You're a SAFe fellow - one could do all sorts of puns with that. Safe is the framework, everybody in the agile industry loves to hate. Safe is the framework, everybody in the agile industry loves to hate.

11:41 Em: It is, isn't it? It certainly is. I have such strong memories of being at this conference in 2013. And that was the year that Ken Schwaber isn't here, but tweets into the Alliance Tweet stream unsafe at any speed and then David Anderson, who is also not here, is tweeting into the tweet, stream his blogs. And it's interesting for me because I didn't grow up in software and I didn't grow up in agile, and I'm going, isn't this a people centric movement, isn't this about respect for people and individuals and interactions and what is going on here?  So, yes, it certainly does seem to be the framework that people love to hate.

12:20 Shane: Why is that?

12:21 Em: I don't really know and maybe I'm naive, I grew up in enterprise agile, right, I didn't grow up in team-level agile.  I grew up in an enterprise agile. From day one I was playing with agile at scale. I was looking for answers, I found some books, I had a lot of success and it's been a repeated pattern and I never went and looked for anything else. So, I kind of live in that bubble.  I think it's got an interesting business model sitting behind it. I think people don't necessarily appreciate that business model. I don't know that it would necessarily be my choice, but it's not my business model. I think, you know, if you compare to Scrum is created it's free and then there was the way that scrum was monetized, as I understand it, is 200 odd people are allowed to train scrum masters. SAFe took a very different tack, it created a train the trainer program out of the gate, and anyone who takes that class and passes an exam can teach a class. I think there's gotta be at least part of this that says there's an economic model for a group of people on one side that another group of people are threatening. And I can certainly understand how uncomfortable that would be, so I think that's gotta be part of it. I think there's a lot of misunderstanding out there. Almost anytime I get into a conversation with someone about why they dislike SAFe, they almost always tell me something that isn't true. Why is that so? I dunno. I think probably the existence of the big picture is SAFe, scaledagileframework.com and the big diagram, I think is its strength and its weakness. It's an incredibly comprehensive body of knowledge, a set of proven patterns that are being used, that are free and accessible, and it's an extremely large body of knowledge that people find it difficult to consume and can easily misinterpret if they're not actually going to take the time to dig in. So, I think it's an interesting challenge.  As I said,  for me, I had a lot of success, I've continued to have a lot of success with it, and I've very much taken to heart the part of safe that says our values are LEAN so:   respect for people, relentless improvement, foundation is leadership, focus on flow, focus on innovation and the goals of delivery of value. If that's my core value set, I don't know how wrong I can go. Does everyone hear that message? I don't know, but that's certainly for me, I can look at SAFe, I can look at that very cool lean value set and go, that's all right with me. I can certainly help people using that.

14:56 I've heard SAFe compared to the RUP.  It's RUP reborn and yet I also happen to know Philippe Kruchten quite well, and others of the RUP authors and Felipe in a conversation made it very clear to me, and explained exactly how, the  RUP itself was designed to be a framework that you removed stuff from and distilled it down to the minimum that you need.  But nobody got that message and the consultants sold the whole thing and didn't pare it down. Is SAFe, suffering from the same thing, the same misinterpretation?

15:36 Em: Could well be, yeah, so it can grow up in technology, I didn't grow up with RUP either, I know of it. Certainly the message in  SAFe, probably stronger in the early days in some ways, they used to talk about "scale up", so add what you need and the messaging in the how the framework was taught was scale up. The language they use now is they talk a lot about Essential SAFe and Essential SAFe is the agile release train, the team of agile teams and at its heart, that's all SAFe is.  A team of agile teams work together to solve a problem. I think that the more recent releases of SAFe have tried to clarify that this is the core piece and add what you need. I do think that there's a lot of things on that framework, and I do think it's easy for people to over engineer it. I feel like it's trending away from that, but I've certainly at a point in time going back a couple of years, I felt like everyone was trying to over engineer their organization and taking really tiny organizations that were a single agile release train, and trying to apply a whole heap of concepts that just don't make sense, or are necessary, in that size of organization. I'm seeing less of that now than I was two years ago, and I think SAFe's done a good job in the last couple of years of trying to illustrate configurability in a better way. But you know, of course that's last couple of years and we're talking about a framework that's been around since 2012 and grown over that time. It started smaller and it got bigger.

17:01 Shane: The diagram is imposing

17:04 Em: It is rather large, isn't it?  We call it the big picture.

17:10 Shane: So what's good about SAFe?

17:13 The opportunity to create better work cultures

17:13 Em: For me, it's been an opportunity to create better working cultures, to create environments that people want to be a part of. So everywhere I've managed to work with SAFe, we've managed to completely change how people feel about where they work and it's kind of awesome. Right? Take a hundred people, a couple of hundred people, 500 paper or a thousand people and change their lives, cause we spend so much time at work. That's certainly what drives me, that's certainly been my experience with SAFe. I can't talk for everybody else, but it was awesome. They're getting better throughput, happier people, where they're working with software, they're getting better quality code. They're getting results. Is it all answers to all things for all people? Probably not. Has it helped organizations that I've seen struggling perform better? Yes, and often in ways quite surprise me. I find organizations and go, you're kinda small, are you sure you need this? Then you spend time with them and you see that communication and alignments a problem, code quality's a problem. All these things that we can actually address because we have this very comprehensive set of tools that play together. So I think it helps. Is it magic? No. Is it for everybody? Maybe not, but have I had success with it? Yes. Have my clients had success with it? Yes, and you know, I'm all for anything that works.

18:49 Shane: Thanks very much for taking the time to talk to us. It's been really good and good to hear the alternative view.

18:57 Em: Two sides to every story.

18:59 Shane: So if people want to continue the conversation, where do they find you?

19:03 Em: Prettyagile.com is probably the best way to find me

19:09 Shane: Thanks so much.

19:12 Introducing Greg Koberger

19:12 Shane: I'm sitting down with Greg Koberger. Greg is the founder of ReadMe, Greg, welcome. Thanks for taking the time to talk to us today.

19:20 Greg: Thank you so much for having me on.

19:23 Shane: So ReadMe - there are lots and lots of files that I've seen that have had that word in it, but I suspect you don't quite mean the same as what Microsoft does with their installation of whatever software. So tell me a bit about ReadMe and about yourself, please.

19:38 Greg: So I think most of our audience is probably familiar with, readme files. So my friends from high school know what I do, they know the name of my company, but that's about all they know and they were watching Mr. Robot a few months ago and I got a bunch of texts from them and they're like, I can't believe your company was on Mr Robot. And I was like, cause I saw like, you know, on the command line, you know, he was editing a readme file and they're like, I can't believe he was using your company on the show. And I was like, Oh, not quite. So, yes. We were inspired by the readme files, which come with pretty much every software package, whether it be, you know, a Microsoft something or an open source tool and all that, we were looking for name and readme.io was available so we nabbed that and kind of went with it. Well, yeah, we do much like readme-files we do technical documentation. Our niche recently has been APIs, specifically, but we're kind of a home for any sort of technical documentation.  We tend to live at like developer dot whatever.com. So, you know, developer.info.com, and we would take care of documentation, support forums, all that fun stuff.

20:31 Shane: And what brought you to where you are today, what's your background?

20:35 Greg: So my background is, computer science was my major. I've always been into programming even before that, but I kind of took a turn where I got really into design as well, specifically kind of around usability and all that. And I just fell in love with usability and design for developers. I thought it was kind of a really unique space.

20:54 Developers need different kinds of usability

20:54 Greg: It's developers need different kinds of usability. They're very technical. So you can assume a lot of things, but you can't assume too many things and all that. And I just kind of like love that. And then over the past few years, I've gotten really lucky that the space has expanded. So when I started readme, but even like 10 years before that, kinda when I started programming, developers are kind of their own thing. But now I've seen a change where like, especially with APIs, the people using APIs , building on them creating APIs, obviously a lot of developers, but there's tons of other types of people. Support, marketing, product managers who are technical or semi-technical, but not programmers and  I kind of love this expansion of the space where, you know, not everyone has a CS degree in order to build something cool these days. Some of the coolest stuff's coming out of people who just toiled around in GeoCities and know enough JavaScript to be dangerous and kind of start putting stuff together. So I've kind of liked that over the past few years, the shift in the type of people using technical documentation,

21:45 Shane: You started this company, one of the reasons we're on the InfoQ culture podcast, as you put it, you want to work with people you want to work with. How do you build a culture that invites the people you want to work with?

21:58 Building a culture that invites the people you want to work with

21:58 Greg: I think that culture is a really tough word. You talk a lot about culture and the problem with culture is a lot of times, culture can be exclusive as much as it is inclusive and you want to make sure you're not just hiring the same people over and over again. You want to make sure that, you know, your culture is very receptive towards expansion and changing and growing as time goes on. But I still think you need some kind of core values, some core things that everyone from the get go agrees on and you know, the kind of people I like working with, it's kind of a self selecting crowd to a certain extent. And there's a few things, you know, early on that I like to do to kind of end up working with the people that I want to work with.

22:33 The interview process

22:33 For the interview process, we put a lot of thought into how we want to interview, and this is mostly for technical interviews, but for any type of interview, actually, I ask two questions, but one of the questions is what's the coolest thing you've ever built or done? For a lot of people we'll talk about like something tney did it work a side project, they worked on, some people will talk about like weird stuff that I'd never would have thought would be things that they would like talk about.  I just like people who get excited about something, it doesn't have to be about my company per se, I really enjoy working with people who are passionate and curious, like good at figuring things out. So that's kind of the one question I ask and I kind of can get a pretty good ideas on if I think they're a good fit or not based on that. There's no right answer. The only way wrong answer is, you know, not really having anything at all that you're kind of excited or passionate about. Some people just say things like they built a table, or something like that, like a woodworking type thing, I've had, I've had people talk about programming stuff, but I just like to see that  a passion with people. I think, you know, I like people who are creative, who like being self-starters who are passionate about something, does it have to be API documentation, and that's going to people, I try to attract the most part.

23:34 Shane: And how do you prevent it becoming, as you mentioned, a monoculture, just a carbon copy of you?

23:41 Greg: That's tough because sometimes I do want things to be a copy of me because, you know, I have qualities that I like and I want everyone to have, but a lot of times I want people to push back and have a different perspective and bring different things to the table. I think it's tough. I think it involves a lot of like taking step back and all that. I think we do some nice things that let people kind of express things in their own way, which is nice. So like we have a mascot, that's an owl and it's kind of bizarre, I wasn't planning on this, I didn't think anything of it when we started using Albert as our mascot, but it's kind of given a lot of different people, a lot of different twists in ways to, you know, express themselves with making t-shirts or, you know, painting ,someone did a painting for us here, and it just kind of is in a nice way where our culture isn't based around like drinking or based around, you know, any certain, one thing, you know, kind of just owls been taken so many different ways. Someone took us to the zoo one time; we did that as a team. Like it kind of gives people like culturally, internally a way to kind of express themselves. Different ways attract different people, but it's tough, you know, having an owl mascot's and not the only way to like build a good culture. It's a balance, and so far we've been lucky that we have a lot of really great people who are great in very different ways.

24:49 Shane: You've mentioned a couple of team-building things. One of the things that I know about is you're really interested in escape rooms, to the point of actually building one.

24:59 Greg: Yeah. That was a little side project. So we, as a team kind of gone to escape rooms a few years ago, we do offsites all the time, and we bring people to different places. We've gone as far as Thailand and Hawaii, far from us - we're in San Francisco, and as close as you know, just different cities nearby here, we've gone to the East coast, the West coast all over. And we always, you know, make or get drinks or something like that, but I wanted something that was good for people to kind of like interact and talk without having to it , just be a bar all the time. And we kinda got into escape rooms and the team kind of really likes it because you spend an hour working together uncontrived, of course, but working together and getting to know each other,  you work with people you normally would and work with on the team. So we've done a bunch of escape rooms. And about two years ago, I got a little burnt out at work and I wanted to take a week off. I had to do something different and I rented an art gallery in San Francisco and built an escape room, like a bunch of puzzles.  There's like 50 puzzles in it and its startup themed and you have an hour to launch your startup and that's been great for other teams. We've had about a thousand other companies come to us for team bonding events. I don't run it from day to day or anything. I just kind of built it and I hired someone to run it. That has nothing to with readme - that was just like a little side project I worked on. And yeah, I think escape rooms has been really great for us to kind of get people, just really get excited about stuff.

26:11 Shane: And we'll put the link into the show notes so that people can find your escape room in San Francisco.   Another thing that you mentioned was the importance of the physical layout, the office design. Putting in the time and effort to come up with the ideal office design

26:05 Greg: Yeah. So I think a lot of people who listen to you probably have done something similar to this, but we did a 360 thing where we had someone come in and administer it and like, you know, asked us a hundred questions or so, and they were like really dumb questions or they felt dumb at the time. It was like, you know, two adjectives and you would pick which one you're more about and it got a little strenuous.  By the end, you're just like, Oh, I don't really know anymore. So I got all done and then you get a packet that describes you and all that, and one of the sections was about your office, your ideal office and I read through it, I was like, this is really weird. Like, it's almost like they're messing with me.Like it described our actual office that I had designed, like perfectly like brick walls, like wooden floors, you know, on the walls, like colorful posters with like values on, but like, it was like, So specific. My point in all that is I think that the reverse is true as well, I think that, you know, the office does a really great job of kind of helping people understand the company, it bleeds out into the product, it bleeds out into like who you hire, when people come in, if they feel attracted to it or not. And I think office layout is incredibly important. Obviously, some algorithms somewhere could like describe my office to me. I think that the opposite is true, where just being in the office kind of helps set the tone and culture and all that. So we put a lot of money and time and effort into having an office that feels very like what we want it to feel like very homey, but also very like, you know, creative and clean and, and colorful.

27:39 Shane: What does that mean in terms of one of the common situations we find today and like you and I are right now, a lot of remote work. Keeping remote team members engaged

27:49 Greg: Yep. So we're about 20% remote give or take. We have an office in Columbus, so there's about five people in Columbus and then we have a bunch of other remote people in different cities and you're right. I don't think that you need an office. I think that remote work is getting bigger and bigger and there's a lot of really great things about it. And the office doesn't really help that much for those people because you know, they're not there. But I think, you know, we still do a lot of things, hopefully, to kind of make people feel included. We have on-sites all the time. When people come here, we go to off sites, we travel to different people's cities all the time. We send out a bunch of like owl swag and stuff to people so that their offices can look like their stuff. But also they want to have a little Albert here or there they can. But I agree. I don't know if it's a huge deal, cause I like to work from home too a lot, even though we have an office and all that, I think it's just nice to have like the headquarters, like the base kind of, you know, feel very readme,-esq.

28:36 Shane: And you use a thing called challenge coins, what are they?

28:41 Greg: Are you familiar with these at all?

28:43 Shane: I've come across kudos cards.

28:45 Challenge Coins

28:45 Greg: What a Challenge Coin is, it started in the military, in the US military. I'm sure it's been used otherwise, and the whole point was they would give you these coins that would say like the battalion you're on or whatever. So if you're ever at a bar and you're like, I was in the 37th infantry, and someone's like, no, you weren't, that's the challenge. And then you like have proof that you were in this particular battalion and things like that. And the whole thing is like, if someone challenges you on it and you pull it out, then they have to buy you a drink, and there's other little things around it. Like, you know, you can also like, take your challenge coin out and like slam it on it table, and if you do that, then everyone who has one has to do the same thing. And if everyone has it, you have to buy a round for everyone and if someone doesn't have it, they have to buy a drink for you. There's like some like games around it and everything, and it started as a military thing. I got it from listening to a podcast with a guy named John Fabro. He's directed a bunch of movies. Like the new lion King movie was his most recent one, but for all his movies, he'll make challenge coins and give a challenge coin to everyone who was involved in the production of the movie from, you know, the cast and  the, you know, really important stars all the way down to like the craft service table. And I just really liked that mentality of it doesn't matter what you do or how involved or not involved, like everyone who was involved in this gets a challenge coin. So we started giving those out to everyone who worked at the company and who was instrumental to its success. So like investors, early people who gave  like really amazing advice, friends who went above and beyond in being supportive, and, you know, as we've gotten bigger, the bar has going a little bit higher to who we give it to. Obviously employees, but since it's like really fun thing that we do for everyone, and we put everyone on the website, if you go to  readme.com/credits, much like a movie credits, you can see everyone who's worked on the site. Cause I think there's, you know, I get a lot of credit cause it's my company, but you know, I'm dwarfed by the just number of people who help out and work on it and work really hard and I want a nice place for people to kind of like, you know, no one’s gonna really go through it and look through it just like movie credits. But I want to acknowledge like all these awesome people that helped me and the company get where we are today. So between the challenge coins, the credits, we try to like copy movies a little bit in that sense.

30:38 Shane: So, where else do you draw inspiration from?

30:40 Greg: So everyone who starts at the company, I give them the same book. Are you familiar with Getting Real or Rework they're from 37 Signals, which is now called Base Camp. They also started like Ruby on rails and they write a few books, they've got like five books now. They've one on remote work. They have one called It Doesn't have to be Crazy, which you can kind of see what that means. And I give everyone that book and I write them a note in the beginning. I give them Rework and write a note and I think it tries to set the tone for how I look at building a product and company and culture. Now, one of their big things is not raising money. They're very anti-VC. We've always had some VCs in the past. We raised a big round very recently. So we're, we're a little bit different than them, but I still love the way they think about it. Just things like you don't have to work crazy hours, you don't have to have tons of meetings. You know, the product should be driven by feeling as opposed to like customer driven, things like that. I think that's a good way to start everything off. I drew a bunch of inspiration from it, which is why you have in the book, because it's kind of a way to kind of understand how I want to think about building a company. It's an easy read, so anyone out there should definitely read it. It's just a collection of blog posts, honestly. So you can like skip around and all that. So it's pretty easy to read.

31:43 Shane: And again, we'll include the links in the show notes.

31:46 Greg: Sound good.

31:47 Shane: Greg, so if people want to continue the conversation, where do they find you?

31:51 Twitter is a great place. @Readme is the company account and mine is @gkoberger. If you have any questions, I'm also, gkoberger@gmail, pretty much every site, not a lot other gkobergers out there. So I've got the social media handle everywhere,

32:05 Shane: Greg,  thanks very much for taking the time to talk to us today.

32:08 Greg: Awesome. Thanks for having me.