Episode 92: Ellen Chisa on Product Management and Productivity

Brain Dawson: Hello, welcome back to another episode of DevOps Radio. Happy 2021. We're kicking off our first interview of the year with Ellen Chisa, cofounder and CEO of Dark. And I'd almost say just simply the title cofounder and CEO of Dark misses some of the key interesting parts of Ellen's story, but we'll get into that during the episode. Ellen, hello, welcome.

Ellen Chisa: Hello. It's good to be here. I must admit I am no longer CEO of Dark, but I hear cofounder is forever.

Brain Dawson: Yeah, you can't take that away from somebody, huh?

Ellen Chisa: You can't.

Brain Dawson: Well, I'm curious. What is your role at Dark now that you're not longer CEO? Are you still with Dark?

Ellen Chisa: I am not. About midway through last year I moved on. I'm in the process of figuring out what to build next.

Brain Dawson: Okay, okay, okay. Well, I want to learn what your process for figuring out what to build next is, and I think that's a good segue – I'll pull us back into that – but a good segue into can you introduce yourself since I kind of botched it, by the way? If you could introduce yourself and give our listeners an overview of what your background is. Would love to hear kind of in your last mission at Dark how you ended up there and then maybe you can sprinkle in what you're thinking about next.

Ellen Chisa: Sure. So I guess I always go back to I feel I started as an engineer. I went to, at the time, a brand new, unaccredited, fully based, project-based engineering school called Olin out in Massachusetts. And while I was there – it's a little bit meta, but I figured out that I loved building things that help people build things. So I spent time at Microsoft working Office productivity. I was early in product at Kickstarter working on how to get funding for people who want to build interesting things. I've done some angel investing. I had a brief stint working in travel and then most recently, like you said, I started Dark, a new programming language.

Brain Dawson: And for the listeners who don't know what I said, that is a not your typical string of events, right? Program manager, founder, angel investor, founded a programming language. Why don't we start with – and I've gotta control myself because my mind wants to get into everything. But to start off, can you first tell me a bit about your last venture, Dark, but more so than the venture itself or the product, the language? So what brought about developing or bringing forth a new programming language and how does that relate to the entity Dark?

Ellen Chisa: For sure. So I think one thing that doesn't come up in the background when you think about going to engineering school and my degree was electrical and computer but a simile for CS is the things you learn in school and the things you start doing when you first start programming aren't necessarily what our day-to-day jobs is. Engineers who are working at DevOps aren't alike at all. So there were parts of that I loved. I loved solving problems. I loved solving puzzles. I loved trying to figure out what to do, but then when I figured out how much of my time would be spent on writing boilerplate or doing infrastructure over and over again, that was a big thing that pushed me to product.

Brain Dawson: Gotcha.

Ellen Chisa: So when we started Dark, one of the things I was super excited about with it was it solves a lot of the things that pushed me further away from software by letting developers focus on logic they were writing rather than just having to think about doing the same stuff over and over again.

Brain Dawson: So a bit of – it's funny. It's kind of made it into mainstream lexicon as of recent sort of driven by Accelerate, DORA, and those teams but the hyper focus on reducing cognitive load so it can be spent on more meaningful and impactful things than the rote tedium that often becomes part of being effective as an engineer. Does that properly capture, I think, at least a portion of the benefit that you were looking to achieve with Dark, reducing the cognitive load?

Ellen Chisa: Yeah, a big part of it was that and then I think the other part of cognitive load that's always frustrated me is you're often looking at your code in isolation so you see the text and you know theoretically what it's supposed to do, but you have to actually run the program to see what happens. So another big thing about Dark was any time you were looking at code, you were also looking at the impact that it had.

Brain Dawson: Okay, now I'm really curious. So can you tell our listeners and frankly me more about Dark and how it, yeah, how it solved that cognitive load problem, how it's supplied, and ultimately the company around it?

Ellen Chisa: Sure. Definitely it was more controversial with the DevOps folks, but the way it fundamentally worked was it was the programming language, the editor, and the infrastructure all tied together. You can think of it as a language, an editor, and a pass basically bucketed into one thing. So when you opened the editor in your browser, as soon as you wrote anything, it was already posted. So zero to hello world, three seconds. It was only for backend web services. So from that perspective, it was API endpoints, data storage, background workers, and event queues and we called them ripples but basically internal tools that you could write that only had access to your application.

Brain Dawson: Right. And is it fair to say that the problem – we'll call it cognitive load for shorthand, right – the cognitive load problem is what prompted you to decide to start this company?

Ellen Chisa: Yeah, for sure. I think that might be a nicer way of putting it, but I would say the problem I had where I wasn't enjoying the time I was spending writing software. I was feeling like I was wasting time. So it was pretty selfishly motivated in many ways, but yeah.

Brain Dawson: Look, most optimization in our space is selfishly motivated. I mean I like to say the developers and people in our space actually not solely the domain of developers, we like to solve problems and we like to solve problems that impact others but oftentimes that starts from addressing our own pain. So it sounds like you've moved on from that. And as we wanted to ask earlier, what's your – you said to quote you're in the process of figuring out what you want to do next. How are you figuring that out? Do you have a rough idea of emerging spaces, things you want to go after and tackle? Are you waiting till something else is a pain in the ass and then you're gonna – yeah?

Ellen Chisa: I think it's a hybrid between the two of those. So I at least have the high level vision of I definitely like working at things that help other people work on things and solve those problems and I find work really meaningly which there's lots of other things about life too, but I happen to like it so I like trying to improve that. And so I think, especially when you're committed into starting something, you're really committing to thinking about a problem for five to ten years if all goes the way you hope. And so from that perspective, you don't want to – at least I've never been able to just say, "Oh, I'm going to make a matrix. I'm going to find something that's a good business opportunity. I'm going to go do that." Like that doesn't work for me. It has to be both a good opportunity and something I'm excited to pour that much of my time into.

Brain Dawson: Right. okay. Okay. Well, in your experience, like you said, you have an engineering background. As an engineer, you identified a technical problem. You went and developed a solution for it, built the company around it. Now you're back starting again. It seems like it would be a great time to solicit advice from you for our listeners that are, you know, product managers, developers, lead engineers that are in a technical domain, and I'd hate to stereotype us but tend to be able to identify problems in the – abound. Do you have any advice based on what you've learned for how an engineer with a problem and an idea to solve it, can go about making that real, bringing that – whether it's in the form of a company, an opensource project? What lessons learned could you share to provide guidance?

Ellen Chisa: All right, so many of these. So think the first thing is first figuring out what the right vehicle is. Like you're saying, you might want to have a company, you might want to have an opensource project. Even within that bucket of company, do you want to have a bootstrap side business that you're doing alongside of something else you're doing professionally or do you want to build something that's venture of scale? And there's a whole bunch of different paths there.

So I think one is figuring out which path is correct for what you want to build and then I think a big piece of decided which path is correct is figuring out, like you were saying with what problem is Dark solving, what problem are you really solving for who? And being able to get really crisp about who the person who's going to be using that technology is. And chances are, as a developer solving your own problem, it will probably be more people who face the same things you do. But I would think very seriously about both of those questions.

Brain Dawson: Okay. And I really am going to want to get into your angel investor background, some of your authorship, but to maintain the DevOps string, I first – well actually, I got to get in my opinion piece. I will tell you the idea of Dark, brilliant, right? Especially my opinion piece is we always talk about low-code/no-code. We've talked about 4GLs. We heavily over the past 20 years or so have leaned more and more on interpretive languages, right? They've become mainstream. I'm assuming there's a whole batch of developers out there that have no idea what a compiler is. So one is the premise of Dark was very much going with the flow of where many rivers are meeting.

I would also say though I am curious of your thoughts on this – that I predict, and I hadn't necessary said this publicly before, that if we flash forward in ten years, based on everything we're seeing with ML, AI, cloud, the orientation around sort of flattening the DevOps divide, I see a world where what you brought forth with Dark almost becomes the standard. That going from code to production becomes much less of a detailed planning process, orchestrating and building tool chains and sets, that we arrive at a world where you build, test, and deploy code at rest, right? You know, it may be live. We have people like Kohsuke, the founder of Jenkins, that are doing live ML on test. But I have this vision of your code's in the repo, as soon as it's in repo, it's in prod. Curious –

Ellen Chisa: I totally agree. I think this is a really important shift. I mean even if you think about from when I started, when I was originally at Microsoft, we would work on things that you would only chip once a year and even when I interned it was once every three years. We're clearly going in that direction, and I think it's funny how much pushback there is to that last little bit, but I think we're going to get there, and I think that's one of the things that will make it way easier for more people to be developers.

Brain Dawson: Yes, yes. And for our operations people and our release managers out there, this is not a world in which you don't have a role. There's a lot of roles there. The highway, the infrastructure will always have to be built, maintained, and tuned and adjusted. But yeah, with canary deployments being a practice, with honestly the ability soon enough to begin – I mean we're already doing it – to be able to infer what program language someone is using, what architecture someone is using, be able to identify what areas of code need to be tested through ML and AI, the scale of cloud. Like I think and it's cool that you built a company that's aligned with this. Yeah, it will look really different. It will look really different. So let's shift. We'll go back to DevOps in a bit. You worked as an angel investor. I mean you did some angel investing. Well, actually worked explicitly. When you did that, going back to kind of the advice for people that won't to build things, what did you look for for companies to invest in?

Ellen Chisa: Yeah, for sure. And I still invest and feel free to pitch me if you want to.

Brain Dawson: All right. Right after this call, a million dollar idea, I promise you, Ellen, code delivered to production at rest. No, I'm playing, by the way.

Ellen Chisa: Maybe can't do that. I think people miss that there's different types of angle investors. So some people who angel invest do it very professionally. They're very focused on returns. They treat it as their fulltime job. They act a lot more like professional investors although they have a different risk profile. For me perspective, I think from a lot of other founders and operators who choose to do some angel investments, it's smaller checks and it's a little bit more community based, helping give back, help other people start companies, and really support them.

But for mine, I'm really only looking for three things. It's do I believe in the founder and do I want to work with them on something? Do I think I'll be able to help them? So sort of what would that working relationship be like? It's founder first and then the space which is do I think it's exciting, do I think it might work, do I think I can be useful in the space? I've passed on deals before because I just felt like I couldn't give the founder a very good perspective. And then the third part being do I see a way that this could succeed. Success not having to be a unicorn or anything like that, but do I see a path towards what the founder is trying to build?

Brain Dawson: Okay. And so to grab on that, not necessarily measuring success in percentage of returns but really success in the ability to bring to fruition what the vision is. Is that fair to say?

Ellen Chisa: Yeah. And I think success with some amount of financial return, but it doesn't have to be a 1000x. It doesn't have to return all of my angel investments or something like that. And I'm not looking for all of them to return the same thing. I think it's a good way to accelerate serendipity and meet a lot of interesting people working on interesting problems.

Brain Dawson: That is awesome. Very, very cool. Well, as you continue in your angel investing, I'm sure you're continually tracking the market and what's happening. Are there any companies or emerging areas of technology that you see as disruptive or like we talked about as the beginning of the future for software development delivery, et cetera?

Ellen Chisa: Yeah. I'm not sure this counts as technology exactly, but I think we should think about it more. But I'm seeing a lot more around people building real developer experience teams where they're thinking holistically about the brand, the community, the documentation, the tutorials, the support, the sample apps, and the product and how all of that ties together. And so while that might not change the underlying, I think it changes how we're able to adopt and build things more quickly.

Going with that, I feel like we've been seeing more about companies that really put the community and collaboration aspect up front. So I think about kind of the profile of the Dev Dota2 community, Kimber to Hacker News or Stack Overflow. Or I think about Glitch and Jam and how much they're focusing on collaboration while we're building software. And then kind of going to what we were talking about with Dark, I'm seeing a lot of focus on people focusing on what they're building and being able to get it out there quickly. So companies like Motif.Land or I guess a little bit further along but Nellafineversal I think are really pushing in that direction.

Brain Dawson: Okay. The trigger for me, Dark was focused on speed. You highlighted some companies that were focused on speed, time to market. You know, for better or worse and we can debate it. I have multiple positions on it. Sort of modern software development practices and movements, CI/CD, DevOps, some of the underlying tooling have hyper focused on speed, on time to market, on velocity. Do you think that this is the right thing to focus on? Is there a downside to the pursuit of speed or velocity?

Ellen Chisa: Yes, certainly. I think there's a tradeoff here. So I think when you're thinking about moving more quickly, I think historically it's gotten a bad rap I think from the move fast and break things era where people would ship things quickly without necessarily understanding not even just the impact they would have on their system and it might impact employees but like the impact on customers, the impact on society. I think that's a real problem. So then when you think about moving quickly, it has to be quickly and thoughtfully and with the ability to respond effectively if something goes wrong. I think we're seeing more companies there, too, like Honeycomb and the whole observability space, like Jelly and Alma and thinking about how your team should respond to incidents internally. And so I don't think you can have one without the other.

The flipside of it is – or I guess pushback on me, if you want.

Brain Dawson: No, no, no. I'm sorry, no. I want to hear the rest of the thought. I want to hear the flipside to it.

Ellen Chisa: Yeah, I think flipside I think the big reason, having spent a bunch of my career in product, that we pushed so much emphasis on getting what we build right because it takes so long. And so I think we spend a lot of time sitting around and trying to guess and trying to prototype and trying to do anything other than actually building software. And if we make it easier to build and ship software quickly, I think we'd save time in other places too and we're able to try more ideas and see what actually works instead of spending a lot of time like thinking hard and then sometimes having done something very expensive that then is wrong.

Brain Dawson: Yeah, yeah. This is interesting. This is a bit of when you talk about product management and sort of the difference between art and the science; and I'll almost put the art side as learned experience, opinion, and creating of the product manager themselves but also recognition that you have to get customer feedback, user feedback, feedback from other places. That leads me to want to ask, we're in this DevOps world where things move faster, where things are continuous, where in a sense we're becoming much more open and collaborative, right? There is no longer – and I'm not saying that this was always the case – an either project manager to execution relationship with engineering or a quasi-waterfall relationship, right, where as a product manager we build out a big set of requirements or even a small set of requirements, throw them over and step back. Some things have changed, I believe, for product management in a DevOps world. Do you agree? What things have changed? How is it different as a product manager in the shifting way we develop?

Ellen Chisa: I think it's much better and it leans towards how I always preferred to work and I think that's partially because I was an engineer beforehand. But I think doing that gives you a lot more ability to work as a small autonomous team together, be it product design, development, go to market and marketing, whatever the key roles within your organization are to really work on one thing together in real time as opposed to having these very structured hand-offs between groups. And I think that allows people to really broaden and deepen their skills more effectively as they can learn from their teammates as well.

Brain Dawson: Okay. I'm delaying the actual – there's some questions I provided you and one more question before I get into them. I'm a developer. I'm an engineer. Help me understand why a product manager is important to me.

Ellen Chisa: I don't think it's necessarily that having a product manager is important to you so much that there are jobs that often fall to the product manager that are important to you. So any time you build something and then someone comes in and is like, "Oh no, you built the wrong thing, do it all again" and you're like "Why did you have me do this," that sort of churn shouldn't happen if you have someone effectively doing the product role. Or if you want people to see your work and have it communicated effectively to the world but you don't want to spend all your time building and then marketing and then building and then marketing, having a product manager with you can make sure that whatever you build has the impact that you were hoping it will.

Brain Dawson: I love it. Perfect. And that then gets to why is Brian asking all these questions about product management, well, Ellen wrote a book of essays on product management a few years ago. Ellen, what I'd like to know is what inspired you, what prompted you to do that? Was it another personal PITA or something else?

Ellen Chisa: It was a couple of things. I'm really transparent, and so I mentioned before in the intro that I worked at Kickstarter. Part of that is like I always wanted to do a Kickstarter project and books are great examples of things to do as Kickstarter projects. So it was easy to do it that way. But I'd also been writing about product, and one of the things I'd found was at the time there weren't very many people doing it. It's really taken off now which I appreciate. But it seemed like people were responding really well just because there wasn't very much content. And so from that perspective, I wanted to be able to aggregate it into a more organized series of things than just whatever I happened to think about on Tuesday to make it a little more approachable to someone who is finding the work later.

Brain Dawson: That's awesome. And I learned something new. I did not know that books were a common Kickstarter. So based on that and I'll inspire our listeners, hopefully at the end, you know our listeners know you can Google Ellen Chisa and you will come across the book and you can learn more. But if you could help us cheat a bit and maybe share top two, three tips for product managers or we can look at it another way. We're in a unique time. You have to deliver product without the ability to sit down in a physical conference room, look at people, talk to them, work on a whiteboard. As you think about tips, is there any tips for product manager in particular in today's environment, in particularly in today's environment?

Ellen Chisa: Yeah. I've noticed that most of the product managers that listen to DevOps Radio also work perhaps in the infrastructure space. But I think one thing that's really important in this space, even compared to other ones is that explaining why you're building something or doing something is really important. Most engineers are super curious about why am I building this thing, why am I not building this other thing, how do we do this tradeoff, like what architectural decisions should I make, how is this going to evolve over time, do I need to chart this database now, what's going on there? And so I think especially as we're all at home and not necessarily in the office together, those things don't come up in the ad hoc way that they might normally. And so I think just keeping front of mind that explaining why you're building something is really important.

Brain Dawson: I hadn't thought. So that is something that I think about overall. And so you know, we do some – I work at a company that provides developer tools for want of a better word, right. It's an important quest to truly understand what we captured as the motivations, frustrations, and fears of software developers. And there's a lot I'd love to have a discussion about but a couple of things – we hit a couple, right. I love solving tough problems. I love having an impact on people with my tough problems. Oftentimes, developers either want to see when they show the code, we want to see someone's face light up, we want to watch someone solve something faster than they would have had has our solution not been delivered and deployed. But the other thing is a focus on wanting to have context, right, on the why. So it's really interesting that you highlight that and the fact that that's harder to convey when you're remote. So love that. Any other key tips for product managers related to or not related to the times?

Ellen Chisa: I guess not related to the times, but related to everything else we're talking about, I think particularly when you're building dev tools, you end up in this like funny situation where the people writing the thing are actually often the users as well. So it becomes really easy to proxy – and founders do this too and just say, oh, like I have this problem, therefore this is the answer or like I'm writing this feature, this is how I want it, so I would do it that way. And I think it's really important for product managers in dev tools companies to be helping to show the full spectrum of developers. And when working with their teams, talking about like, yes, we are one set of our users but we don't necessarily represent every single developer.

Brain Dawson:
Yeah, that's really interesting that you bring that up because we do – I have seen that at multiple places in my career whereas you're an organization that is delivering developer tools, developing developer tools like you did at Dark, and there is the real risk that you fall on, well, we're engineering managers so we know exactly what engineering managers want. What I'm running into is there's a number of things. Like what type of organization do you work in? What technology are you delivering? Et cetera. So you hit me right where my heart sings when you brought up dev tools. I spent a significant part of my career providing dev tools at police station and running our tools and technology team. So I myself am particularly fond of dev tools and productivity. You've been identified as being particularly fond of dev tools, productivity, work, and products for consumers. Did I capture that correctly because we know I kind of blew the title and everything?

Ellen Chisa: Yeah, that's pretty good. It's a funny set of things, but I like them all.

Brain Dawson: Well, string them together. I mean, well, first just to dig in on the tools because we're on that subject, why the passion, why the fondness for dev tools?

Ellen Chisa: I think that I really – like working in product or working as an engineer, you're delivering software. And so delivering dev tools is delivering the thing that helps people make the thing you love to make. So I think it's I love the joy of building something and being able to get that – just like you said, you give it to someone and they use it and it's exciting and it's even more fun when you're giving someone something that you would also use to make the end thing. Sort of convoluted but I think it's a very delightful experience.

Brain Dawson: I wish the listeners can see but your face just lit up the most it has and you smiled as you talked about that series of things. Before we move on, real quick, let's talk about productivity and the future of work. I mean I think probably 2020 and as we go into 2021, it's like the time where even if it was an area of interest for you prior, there's nobody in the world that can't be thinking about the future of work. Where do you think this field is heading? How is productivity, the future of work? I mean really everything you listed – office productivity, future of work, tools and consumer products, developing and what's oft talked about, right, this time of the pandemic, remote work, et cetera. What do we look like in '22/'23/'24?

Ellen Chisa: I guess this is what ties dev tools and office and productivity tools for me, but I think I really believe in experiences that are highly specialized for experts or who like specialize the task that you are doing individually. So kind of going to the idea of like no one really wants the same bug tracker. No one really wants the same like ticket tracker. Not everyone wants to write a document in the same way. Like these are all experiences where people want something that really customized to them. I think by making it easier to build software, we're going to make it easier for people to make these customized experiences whereas all of us using Notion or something like that, we're all going to use things that look a little bit different but work for us.

Brain Dawson: That's interesting. Okay. But we all gotta work together. So you mentioned collaboration earlier. I'm going to challenge you a bit on this and this is where I get in trouble in the interviews _____ 'cause how does that – I actually very much agree with the fact that actually really all practitioners, right, really in any field but in particular when we talk about developers and the technical stakeholders and practitioners, performance is key. You're almost like athletes. You don't go ask Usain Bolt to go run a track meet in a pair of house slippers, right? He picks the shoes that are custom fit for him and work the best. So I underscore that. I think that relates to what you're saying, but then how do we work together if we're all able to embrace our own preference? That's the problem to be solved, I suppose, right?

Ellen Chisa: Yeah, I think it depends. I don't know how you like to work, but I definitely have times where I'm going heads down by myself. I'm an introvert where I want to spend a bunch of time thinking alone. So the tooling I use for that is I still get a stack of Post-It notes and I sit on the floor and I write down everything in my head and then I move them around a bunch. I should probably use Rim Research or something that maps or Obsidian or something that maps that. But I think there's that set of private individual work, and then you get to the point where you're looking to share an artifact, and then I think there's a translation layer between those two. And I think we'll probably get new trolling for all three buckets.

Brain Dawson: Phenomenal. Phenomenal. I got to resist digging into that more. Cool conversation if we ever get to talk again. I want to shift to our standard dev oops question. Hopefully you got a chance to think about it. I'm not surprising you. This is not DevOps. This is DevOps Radio. This is dev oops, O-O-P-S, dev oops. What technical or other challenge have you faced in your career where frankly you messed up, right? There was a consequence but that consequence turned into a lesson to help you be better and hopefully can help our listeners.

Ellen Chisa: There are so many of these. I guess one kind of from the product side, one of the last projects I did was at Kickstarter we were adding four new categories to the set of categories Kickstarter had. And I worked with the CEO, and I worked really closely with this one engineer, and we had everything set up and it was ready to go, and I hadn't done a good job of level setting of what technically was hard or not between the engineering team and the CEO. And right before we were supposed to go, he was like, "Oh, never mind, I only want to do two of them today, not four." Not understanding like it's very different to do those migrations. It was a real zap. And so it ended up being everyone had to work over the weekend to fix this. It was definitely something that I should have been more clear about that expectation of when you make this decision, even though this sounds easy, it's actually not easy to change it.

Brain Dawson: So could I challenge you to package that up into a sentence of wisdom for me?

Ellen Chisa: As a product manager, one of your jobs should be making sure you fully understand the technical tradeoffs and the ramifications of the product choices you're making and being sure to effectively communicate that to all of the other stakeholders.

Brain Dawson: That's great. And I can tell you're a product manager because it's almost like you figured out, okay, how do I form that as a requirement statement? How do I make a user story out of that?

Ellen Chisa: It's just how my brain works. It's strange.

Brain Dawson: That's great. And I do have to say, to take a pause here, I just wanted to how awesome it is to – and I'm curious if you derive pride in it to have been in the early stages of Kickstarter. I can say I watch Shark Tank a lot. I want to say I was just watching one episode last night and of course two or three times in it, yeah, I started a Kickstarter campaign on this. When we talk about building things that have helped people do things, awesome sitting back here looking. How does that feel?

Ellen Chisa: I loved that job. It also impacted me a ton personally. Tons of people at Kickstarter were artists in addition to being engineers. That was what got me started writing. I took a bunch of classes that I think really expanded my mindset about building other things while I was there. That was when I started doing more talking about product. I think that really helped me understand why it was so meaningful for me to help people make things I think. I loved it.

Brain Dawson: Awesome. And to get my plug in, I don't know if it's ego. So I was in the first team, the early stages of the PlayStation launch and I still, to this day like just get a kick out of some of the artifacts and things we defined 20-some odd years ago, 25 years ago still live and impact people.

Ellen Chisa: I still stan Gex and Crash Bandicoot were my PlayStation games. I'm a big Gex fan.

Brain Dawson: Oh, that's funny. That is. That was early on. Crash Bandicoot was. So I was involved. I believe my name is in the credits somewhere.

Ellen Chisa: That's cool.

Brain Dawson: But that was our bonding time with my son. Actually it was kind of this generation where parents engaged in video games with their kids. So I love Crash Bandicoot. Ratchet and Clank, did you ever play that?

Ellen Chisa: I did not.

Brain Dawson: Okay. Well, we'll get into gaming later. We'll probably edit this out. But so we asked about the dev oops. What is a book, podcast, or resource that you would recommend to our audience?

Ellen Chisa: I'm split on questions like this. So if you're thinking about developer experience, Jeff Lawson from Twilio just had a book come out today. I guess I can't really recommend it because I haven't read it yet, but I've always really appreciated his advice. So that's exciting.

Brain Dawson: Do you know the title? Do you know the title? Want to grab it here. I want to –

Ellen Chisa: Ask Your Developer, I believe.

Brain Dawson: Oh, that's interesting. I want to know what he means by that, but I guess I'll find out. All right.

Ellen Chisa: But if people want personalized book recommendations, they can Tweet at me and I will do my best. And then podcast wise, I've actually never plugged this before but my younger brother has a podcast called "Tales of the SaaS Graveyard" which talks about what it's like to be a company that's kind of stuck in that $50 million to $200 million of annual revenue space and what it's like from every different job perspective so as an ops person, as a developer, as a designer, as a PM. And I think it's funny to hear all of the different perspectives.

Brain Dawson: Hi. That's exciting. Those are two awesome ones. This is actually – I love dev oops, but the recommend resources is one of the things I get the most out of the guests I get the privilege to interview. Both of those sound intriguing. So I will almost immediately go engage in those. Well, Ellen, as you can tell and I probably say a lot because we get awesome guests, I can talk to you for hours, I'm sure. Hopefully we'll get a chance sometime in the future to do it. But before we wrap, which we have to do, any final thoughts? Looking back any sort of words of wisdom, thoughts that you think are important to share with our listeners?

Ellen Chisa: Yeah, I think going back to what we were talking about before with the angel investing, I don't think there's really been a better time to build a developer tools focused company. So I think for anyone who's listening, I really have this problem and I've been working on it and I want to start to think about spinning it out, now is a great time to start thinking about it because there are so many angels and so many professional investors now who are excited about the space.

Brain Dawson: That's awesome.

Ellen Chisa: Not trying to keep people away from engineering. Engineering is also great. But if you have the desire to be a founder, now's a pretty good time.

Brain Dawson: Well and I guess I'd ask that offer. I'm not going to solicit. Are there any references that you want to share in regards to how to get in contact with your or how for that person out there that says, yes, I have an idea for a developer tool for who or where they might reach out?

Ellen Chisa: Sure. I'm on Twitter. I'm @EllenChisa or my website is EllenChisa.com which has my e-mail address on it. I'm pretty easy to find. I'm basically Ellen Chisa everywhere.

Brain Dawson: Okay. Well, Ellen, I want to say thank you for taking the time to share this information with us. Kudos and much respect, for want of a better word. I have much respect for what you've accomplished in your career. I look forward to seeing what you tackle next. And when you do start to embark on that, please let us know. I would love to have you back on.

Ellen Chisa: Thank you. And thank you for all the thoughtful questions.