Mandy MooreRelicans host, Aisha Blake talks to Startup Founder and Ethical Hacker, Ivy Evans about building and growing remote teams, the decisions that she makes as a technical founder, as well as what she delegates to members of her organization as she’s building something new.
Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.
Do you have ideas about how we can make our show better? Or would you like to be a guest on an upcoming episode? Reach out to our #devrel team at devrel@newrelic.com. We would LOVE to hear from you with any questions, curiosities, and/or feedback you have in hopes of making this the best show possible!
Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.
Aisha Blake: Hello and welcome to Polyglot. Today I am here with Ivy Evans, who is coming to us as multi-founder, multi-time founder.
Ivy Evans: [laughs] I like that description.
Aisha: [laughs] I like it too. I'm going to roll with it. And just an expert in a ton of all the parts it feels like (That's my impression.) of building an application. And also here to talk to us today about building teams. I'm really excited to learn from your experience. I really appreciate you joining me today.
Y'all, my name is Aisha Blake, and I am a Lead Developer Relations Engineer at New Relic. Today I will be your host. And I'm excited to hear more from Ivy. Ivy, if you would talk to us a little bit about your experience up to this point, what brought us here, and we'll dive into it.
Ivy: So, my name is Ivy Evans. I've been working in tech since...I think I was 15 when I started working in startups.
Aisha: Oh my gosh.
Ivy: I founded my first company in 2011, and I spent the last ten years as a founder and the last seven building and growing remote teams. I think that is one of those things that has gotten really super relevant of both, like, how do you iterate rapidly on products while scaling small teams? And how do you do all of that as a remote company? [laughs]
Aisha: Yeah, absolutely. In my experience, at least, I feel like we tend to focus on “how do we iterate on the products more and earlier?” than “We often focus on how do we build and iterate on our teams?”; “How do we form sustainable practices so that we can continue to iterate on the product?”
And so I have a lot of questions about how you try to do that sustainably and also the trade-offs that you make, the thought processes you go through, the decisions that you make as a technical founder, as well as what you then delegate to your organization as you're building something new.
Ivy: People are a really important part of the entire process. You can't really build a company and especially weather the storms that a small startup goes through, if your team and everyone you surround yourself with isn't feeling rewarded, appreciated, valued. There are a lot of factors to motivation and the ways that you show up for your team that especially as a founder, you're always setting the right example, at least we try. [laughs]
But yeah, it's about managing those trade-offs and things because everybody sort of has something that they want when they join a team, whether that's personal growth, or a particular equity, or maybe they want to have that cross-functional interaction across the board where maybe you're an engineer trying to move into product, or you work in product, and you're trying to be an engineer.
And so startups kind of have lots of opportunities and things like that. And so people who are really driven who are okay with some of the uncertainties and the challenges that come with finding product-market fit and getting your first customers and things like that can be extremely rewarding and extremely stressful. And so there are lots of things that people can do to prepare themselves for that kind of environment.
Aisha: What are some of those things that either have worked for you or that you've seen work well over the years?
Ivy: Routine is a really important thing, especially for people who have a lot of responsibility as founders. It's really important that you find the things that ground you. And I think more so that's prepared me as I've switched from those early-stage startups into more mature companies is having a routine that sets me up for the day. It really helps me do my best work.
And for me, that's every morning I get up, and I get my coffee, and I go for a walk, somewhere pretty, somewhere in nature. So this is a place that is really beautiful, just like a 10-minute drive away. So I just go walk around, jog, whatever, whatever I'm feeling. But the core of it is it's sort of a time to think and set myself emotionally so that I can handle whatever gets thrown at me that day. [laughs]
Aisha: That could be such a huge range of issues in terms of the topic, the actual type of issue, and urgency is important as well. Even as an IC in an early-stage startup, that is true. I can only imagine when you're responsible for an entire organization how important that centering would become.
Ivy: You sort of have to balance that too because it's very easy as a founder to take on so much that you feel like you've got the weight of the world on your shoulders. But I found that just a simple act of making time for vacations and things like that...If I can leave my company for a week and come back to not everything being on fire, I think it's a testament to how well you are doing as a founder at delegating those responsibilities. If the company can't operate without you, then you're doing something wrong.
And I think it affects the rest of the team so much, so much more than people expect that if you aren't taking those breaks, if you aren't valuing that time that you spend recharging your creativity and resetting yourself so that you can come back with fresh eyes, you're doing your team a disservice.
Aisha: Yeah, absolutely. That touches on so many important points. The first for me is the point about really modeling the behavior that you want your team to feel safe engaging in. When we're talking about taking time for yourself and really focusing on sustainable work practices in general, it matters when your team can see leadership walking the walk and, at the same time, being able to delegate work.
As an IC, you see that there is a level of trust, a level of value in the expertise of the people that you've hired to help you build this thing. And that's reassuring, and it helps people to have a sense of ownership of their work.
Ivy: Yeah, that's a really important factor, that sense of ownership. And I think that if you as a leader are inspiring people to do their best work, if you are rewarding them for their efforts in whatever way...Startups are bootstrapped generally, or they don't have a ton of capital and a ton of resources, especially in those early days.
So I think that is something that is incredibly important is to really understand the motivations of your team and what is it that's most rewarding, and definitely, trust is a core part of that. I wouldn't personally feel motivated if my manager didn't trust me to do my job, which they hired me for.
Aisha: Absolutely. I want to back up a little bit. How did you get to a point where you felt comfortable starting a company, specifically in terms of the technical aspects of the product you're building?
Ivy: I think you go through ups and downs of imposter syndrome. And I think that is just always a part of anyone who's really pushing hard at that personal and professional growth. It's kind of terrifying, and you're always putting yourself in uncomfortable situations. In my case, I got started really early, really young programming. And so, I was able to build up a lot of skills and foundations, and understanding at a young age.
And I'd say to start a company, that isn't necessarily something that you absolutely need. You definitely need some skill to be able to pull off a company, and one of those is also your interpersonal skills. You're rallying a team. You're bringing on that talent. You're inspiring them to want to ride through the storm with you. And you have to go and convince investors if you're going that venture capital route, or you have to put your own money into it.
And so there are lots of people who don't have any of those skills but have capital and are [laughs] likable enough that they can be incredibly successful building a team without any of that knowledge with zero product or software experience. But that requirement does come that you need to be investing your effort and time, at least if you want to have any success with it, into learning.
But people come from all kinds of backgrounds. Anybody can be a founder; anybody can make a successful product. It's more of how fast and how much are you on your toes to be able to respond to those feedback loops? Is what I'm doing today working? Did what I did yesterday work better? And what are my other options? And there's a lot of experimenting, especially in those early startups. I think you have to expect that you're going to fail unless you have already invested all of your time and effort into all of those things. [laughs]
Aisha: Yeah, I feel that. And am I correct in thinking that Room Champ was your first company that you started?
Ivy: Yeah, you know, Counterless was the one before that, a mobile ordering app. And I wasn't necessarily there when we first started at a hackathon. I was a month late. [laughter] The heavy lifting and the work that I did there with folks that I met and worked with, I would say that feels like my first company.
Aisha: Just having been there basically from the foundation.
Ivy: Yeah, exactly. But yeah, Room Champ was the first company that I quote, unquote, "founded.”
Aisha: Awesome. And this could be specifically a Room Champ question, or we can expand. But I'm interested to know how much your hands were in the product itself, how much you were actually building Room Champ the product versus Room Champ the team, the company. And has that changed, or did that change over time as you built other companies? Would your advice on that balance change based on the kind of product you're building or the kind of experience that you have? What are some of the trade-offs there?
Ivy: Seeing that it was my first startup, I would say that there were a lot of things that I did wrong, from just building a product aspect to selling. We sort of wear all those hats as a founder, especially as somebody who's working with just one other co-founder. We built a product at a hackathon. My co-founder, Dan, Dan Ebel, had a lot of experience working in hotels and things like that.
And so, Room Champ was a hotel booking engine for conference organizers. They could basically set up a page and sell hotel rooms without going through the costly and risky negotiation of reserving a block of rooms in that traditional way. So they normally would partner with a hotel, sell a block of rooms, and then be on the hook for filling all of them.
Aisha: Oh, yes.
Ivy: So what we did instead was offered the ability to basically get an affiliate commission on rooms through Expedia. And so all these small event organizers could basically offer the same branded experience as, say, a large conference would.
I didn't have domain experience in hotels. So that wasn't something that I could really be a heavy lifter in. But what I did know was products from just the work that I did working in agencies and dev shops and things like that and working with clients up to that point.
So I did a lot to make this customizable interface, and we threw a bunch of them together and got a bunch of pages going with friends. And some unrelated events that were happening nearby South by Southwest was where we were piloting. And we had good success. There was a demand, and there was interest in the platform.
But ultimately, it was a case of motivation. You have to find a startup that you are interested in 100% to watch it ride through and push at it no matter what. In the case of me and my co-founder working on that company, it wasn't the right fit for us. And it took us about maybe a year to recognize that.
Aisha: Yeah, that makes a lot of sense. I'm wondering if there are other kinds of signs that either you've experienced or that you've seen trip people up or really just helped them to realize that maybe this isn't the right thing for me.
Ivy: When people ask me for advice about starting companies and starting ventures and things like that, I always ask them, "What is it that you most want to get out of this?" And in my case, I sometimes worry that I'm the world's worst employee and that I'm just so opinionated that the only way this is going to work out for me is [laughter] somewhere where that's valued, obviously. And so startups are really great for that. But it can be anything as much as wanting to be in control of your fate, so to say.
One founder I talked to described it as companies and startups, and things like that are the ultimate freedom vehicle that you can go wherever you want, especially if you've figured out the business model and the business is working. I think it's important to frame what your needs are and things like that. And so it helps to frame that so that you don't spend all your time working on a venture capital startup if what you really wanted was a side hustle. And so understanding those priorities and recognizing or knowing enough about what is the investment and the time cost trade-off and things like that.
Fundraising is hard. It's stressful to not just find and get a yes from investors who will invest in your product, in your business, and invest in you, but there's an entire cycle of that constant iteration, and every second counts. Versus say a side project or something bootstrapped where you are focused mostly on getting obviously early launch, getting lots of feedback, iterating. But your growth is more something that's sustainable. You can take those vacations and breaks and things like that. You can have multiple focuses.
Versus startups are sort of like an all-or-nothing kind of situation at least if you want to have success with it. And that can be really challenging because you're foregoing a salary. You're putting all of your time and effort into one basket, and there could be a payoff. But there might not be; most likely, there won't be. [laughs] Have I convinced you not to do this?
[laughter]
Aisha: I'm sitting here, and I'm like, yeah, that sounds terrifying. [laughter] And at the same time, when you do find that idea or mission or whatever it is, that takes hold of you, being able to just commit yourself to that and try and bring it to life, that's exciting. One of the things that keeps me in tech [laughs] in general is the ability to create in that way.
Ivy: Yeah, and especially with software products, I really love the instant gratification. I think it's gotten harder with the complexity that we've gotten in the web development space between frontend and backend and all of these layers and deployments of we've got our GraphQL backend on top of our microservices backend with complex queueing systems and a single-page application on the front end. [laughs]
And it's gotten significantly more complicated. And it's a good thing in the long run, especially for large companies, because obviously, things have gotten a lot more robust. And people are able to be more productive in their specialized areas.
But I've always had a soft spot for Rails just for the sheer productivity. Rails Rumble back when that Hackathon was going on, the Ruby group out in Vegas had a long going...like every year, we would all get together in a hackerspace or some co-working space area. And we would just stay up for the 48 hours or whatever, counting energy drinks and trying to get as much done as possible.
And the stuff that was built was insane, especially when you look at the winners and other contestants. The fact that you're able to get a server up with a backend, a database, and have actual complex user interactions with that little time. [laughs]
Aisha: Yeah, absolutely.
Ivy: And it's so hard to do that now.
Aisha: Yeah, to spin something up. If you were to start fresh, let's say your end-user is going to interact with whatever you're building via a web app; if there are any, what are your go-to steps? What do you reach for first? And what are the architecture decisions that you maybe leave off until you have a better understanding of how the product's going to work?
Ivy: I'm a big fan of the boring technology, so to say, and I try to stick with the things that are tried and true. I've been bitten in the past trying to adopt the thing that is sort of extremely trendy. And what I find is that those things, like those new projects that come from Google and Facebook and things like that, while they're really amazing and new ways of tackling these problems, they tend to not be a good fit for budding software products and things like that. They're usually solving very specific organizational challenges.
When you look at microservices, the way that I look at them is microservices are entirely a way of breaking up applications into discrete bits that teams can work on. And so, the structure and architecture of your software product is going to reflect the organizational structure. And so, if you're a one-man show or if you're just getting off the ground, it makes sense.
And I always recommend number one is use a language that you know and stick to the biggest, most robust framework that you can. Don't experiment with things like the architecture. Don't spend all of your time integrating all of these different components together the way that some projects I've worked on where...not to knock Node or anything because there are some really great frameworks for it.
But when you find yourself working with a microframework, and then you find yourself, oh, we need a job server or some backend to process these cues. And then you start pulling that in, and you start gluing all these things together. And it's really challenging, and those are the things that you shouldn't be spending your time on. You should spend all of your time building the product and pulling things off the shelf.
And that's why I go for Rails myself. You can just pull in a gem for authentication. You can pull in a gem for pagination when you find you want to split things up into multiple pages. There are form builders. There's everything. It's one of the most amazing things about the Ruby and Rails ecosystem is just the sheer amount of work putting all those things together and just how it all slots into place.
Aisha: I like your point about the boring technologies. I think there is absolutely value in trying and pushing new technologies as they emerge. But if you're limited in time, and your focus is in building sustainably, it makes a lot of sense to me to say, "You know what? I know that this will work," and going from there.
And then maybe you truly are just at the cutting edge, and you are innovating in whatever it is that you're building. And you find eventually that whatever you had started with is just not well suited to whatever you're trying to build. Then, cool, maybe that means you go off and either you add, or you change the way that you're thinking about how you're building whatever you're building.
It makes a lot of sense to me to say, "You know what? There's a community around this." That's another part of it for me, at least. There's a community around Rails. There is just so much material to figure out the parts of it that you aren't familiar with yourself.
Ivy: Yeah, all those conventions, everything's kind of figured out. The documentation is there. There are tons of books and reading material versus having to go code spelunking into all of your dependencies of these off-the-shelf components and things like that that you're trying to work into your architecture. It can be kind of frustrating. I find that some of the younger engineers who are earlier in their career that's obviously not exciting. They want to work on the new stuff.
And I think that there's something to be said about not getting stuck in your ways and saying that there are no good ideas, like, all this has been done before and to just be extremely cynical. There's a healthy dose of that. But yeah, I try to get them excited about the things that are most important at that stage of a company which is the product, figuring out the business, learning, and figuring out the business requirements.
And working with challenges as you scale all of those can be extremely rewarding, and people who are going to feel proud of having built something from the ground up. There are so many things that are points of growth than just learning the new thing and using it.
Aisha: For sure. Talking about providing that guidance, how do you go about communicating either your vision for the product? Hopefully, that's at least informed by some amount of research. How do you guide folks towards building a usable, accessible product that fits your user's needs?
Ivy: You know, one of the harder challenges, and maybe this is a separate topic, but how do you say start with...when you have a blank canvas, and you've got multiple engineers, that can be pretty challenging just right off the bat to make sure that it's even in a workable state where people can collaborate on it.
Sort of in those early days on a project, you'll find that there are just so many really core things that need to be figured out that there are just, you'd say, too many mouths to feed from the work side of things. A lot of things are blocked, and things are a little sequential when you first are setting things up, but after that, things kind of open up.
I find that whiteboarding is a really excellent way to get people on the same page; just for starters of, how do you communicate the vision? How do you communicate the architecture and things like that? And then start getting things as minimal as possible. Think, like, you figure out the data model, and you start scaffolding things out. And then you split up and start working on those individual features and functionality.
It depends on what scale or what stage or what kind of product you're building. But not everybody needs a full-time designer unless they're working on a consumer product that is going to be very geared towards lots and lots of visual interactions and things like that. But for the most part, it's like, find a front-end framework and work with a designer to come up with a consistent UI and components and things like that.
But for the most part, focus on wireframing at a core part of that to get your UI and figure out your interactions and how these features are going to all work, just kind of prototype it. Start small. Focus on one feature at a time. And I've probably gone way off track here. [laughter]
Aisha: No, I love it. I think really breaking that down is going to be helpful for a lot of people. I've certainly felt this myself. There's a varier or fog or haze, if you will.
Ivy: Yeah, the fog of war.
[laughter]
Aisha: It's like the fog of war where you don't know what you don't know. And it's almost like the blank page syndrome or whatever you'd like to call it when you're writing. There is a certain amount of well; I have some idea of where I would like to go. But how do I actually break down the steps to get there? And I think what you're describing is really a very common-sense approach to building a product.
Ivy: Yeah, it's definitely when you have the vision. Yeah, the exploration is the other thing, huh. [laughs]
Aisha: There's the exploration. And there's also when you've not been there from the beginning, when you've only ever maybe maintained a product, there's a question of well, how do I even begin?
Ivy: Yeah. You mean like how do you begin on a new project?
Aisha: Yeah.
Ivy: You know, I think people are also generally geared towards individual axis. And I think that some folks are extremely effective at working through the uncertainty that they make really good scouts. They can do that exploration whether that's coming up with like, well, what's the problem in this space and in this market?
When you talk about product development and things like that, that's one aspect of it is what is going to serve this user or this customer? What problems are they facing? And how can we help? And that's where that creativity comes in. But let's say that work is figured out as far as we have a hunch of if we build this thing, we're going to solve this problem.
And how to get started, I think that's a good question. It makes me just want to say, "Well, just start." [laughter] But I can understand that fear or uncertainty that might come from working on a project if you come from a background of mostly working on things that have already been established. You build a vision and look for examples in your industry or in your space of how others have done it.
When I was working on that company, that mobile ordering app, Counterless, I looked a lot at codebases like Spree, the Spree Commerce codebase. And that's how I learned a lot about how do you model an order with line items and things like that? I saw some amazing things that helped me develop an understanding and save a ton of time by looking at oh, they have a state machine. What are the ways that an order transitions through all these different states as it gets processed and charged? And how do you track all of those things?
And a lot of answers are kind of like all around us. And so I say when you're starting out, try to look for role models. And so that's either like an open-source project, or it's a company, or a person. And try to collect as much as possible, collect and then organize, and then collect and organize some more. And you start to see the patterns, and you start to remember.
Like, when I run into a problem now, it's like, oh, where have I seen this solved? I'm like, oh, I'm working with money. The RubyMoney library has some great resources and things like that that will help you understand all those best practices. Oh, I'm working with this challenge. It's like, just spend a lot of time reading code.
Aisha: I love that. Thank you. I know we're getting a little short on time, and we're sort of ending at the beginning. [laughter] I really appreciate you coming and speaking with me.
Ivy: Likewise. Thanks for inviting me on.
Aisha: Absolutely, absolutely. Is there anything that you would like to plug? Anywhere that folks should look out for you?
Ivy: Yeah, I'm on Twitter @ivyevanslv, L-V like Las Vegas. I'm in SF now, but you know. [laughs]
Aisha: But we remember.
Ivy: That's where I do most of my conversation. I love talking to people, especially helping other folks, because I got a lot of help getting to where I am in my career. And anything that I can do to give back, I'm always looking out for those opportunities.
Aisha: Fantastic. I really appreciate it. Y'all, thank you so much for listening. Be sure to check out our other podcasts, Launchies, which is a podcast for devs early on in their career, as well as Observy McObservface.
Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.
