Ellen Chisa Video Still

Sachin Agarwal: I'm happy to have you here at Empower, it's pretty cool. I hope the chair is not overwhelming in its size and style.

Ellen Chisa: No, it's very appropriate for the fireplace currently on the screen.

SA: Yeah, there's a big fireplace, we're at a fireside chat. It's nice, warm. There's fire in the back, fire in the front. It's just how we roll. So let's just get started a little bit. You're not launching today.

EC:No.

SA: Okay, so you guys are still in stealth, I guess, is that still the term people use?

EC: I think so. We're not inherently stealthy people so I think it's pretty funny that we're saying that. It's really just, we're not announcing the name.

SA: Right, so you're not announcing the name, but why don't you kinda go over, just what's the problem you guys are doing, who you and your co-founder are, and what's the problem you guys are trying to tackle?

EC: Yeah, absolutely. My co-founder and I, we both feel very strongly that so much of the time we spend on building software products and on software engineering, is still taken up with work that we think of as being accidental complexity, so it's not something that you actually wanna be shipping to your users, it's not something you're excited about, it's not what you go out after work and talk about, it's just stuff you have to get done in order to do what you want to do.

SA: Yeah. And so when you talk about the stuff that you have to do, to get to the thing that you really want to do, can you enumerate the suckage?

EC: There is so much of this. We had... When we were fundraising, we had 10 slides of 10 different things that we talked about, but we really... There's three things in particular that I think are great examples of this. One is infrastructure. When you're thinking about building a product, the end user doesn't care about where you're hosting your servers. They don't care about where you're storing the data. They just care about the fact that they're able to use the product. And so one of those, is when you're building things, especially now that we live in this world of distributed systems, you end up spending just as much time thinking about how to operationalize and how to productionize what you're building, so that's one. Another one is, just as we've moved towards modern software development we don't have monolithic applications anymore. Everything's fairly microservices-based and you wanna integrate with a bunch of different products. And so when you're thinking about integrating with those APIs, you have to think about the performance, you have to think about the robustness, you have to think about, "What happens if something changes out from under you?" So you spend a lot of time there.

EC: And then the one I actually personally find the most frustrating is deployment. And so when you're writing a document, you can just write and you see what happens, and then when you think about the same thing, even just making copy changes on the website, you can't just do it. You have to go through this entire process where you deploy and then you're like, "Okay, did that work? Great, done." And so the three of those things together really add a lot of time to what we build.

SA: When you say they, "Add a lot of time," do they add a lot of time, like is it mental, that it's frustrating and that's where the time expense is or is it just literally time hours in the day?

EC: It's both, for sure. When you think about it, when you're looking to build a new feature someone has to say, "Okay, what if we did this?" Then it has to end up in some product manager's backlog somewhere and then someone takes it off, and then eventually, they do it, and then they probably put it somewhere to get code reviewed and then people are thinking about it, and then eventually it goes through some deployment process. And so something that might have actually just been five minutes of writing code, by the time you've actually deployed it, you're maybe same day if you're lucky probably more like next week and it's something that should have been five minutes.

SA: Yeah, and that's what best practices and continuous development and all that stuff, you can... I don't know what waterfall companies do anymore, I left Oracle, so it's good. So when you talk about what's missing there and that those three things really stink, what are the benefits that you see people... Is it they ship code faster? Is it that people are happier? Is is that we can build better things? What are the benefits of solving those hard problems?

EC: Yeah, I think the first one is, really we can go much faster. And so, if you imagine a world where you have an idea and you can build your idea in one afternoon, where every single side project you're done the same day, instead of it's this thing that you've been working on after work for months and that you never actually end up shipping like many of my side projects.

[chuckle]

EC: And so I think that's definitely a piece of it. But I think the benefit we get there is, it's not just that you're able to build things faster, it's the more things we build, the faster we learn, the more things we get to try out, and the more we see. And I think, in particular right now because these tools are only available to a limited set of people who are good at building distributed systems, many of us in this room, you don't get as many companies as you would, and I think the next generations of great software companies aren't just going to be software companies that are solving problems for engineers, it's going to be using software to enable things across a huge array of industries.

SA: Yeah, and one of the ways that people have tried to solve that problem is by using standard components and standard containers, and having VMs that they spin up, and things like that. Can you talk a little bit about where those things fail and why they're not good enough?

EC: Yeah. The fact is you still have to think about it. And I think Paul and I were talk... Paul, my Co-Founder, previously founded CircleCI and we were talking about this yesterday when we were getting things set up, where, theoretically, the way we have our system architected, I should just be able to sit down and everything automatically works. We have a container, the container is standardized around what version of everything we should be using, and still every time you sit down to do something, something breaks, then you fix it, and you [05:32] ____ to this version, but you shouldn't be using that one. And so even when you've gone to all the effort to try to set up everything well to work like that, it doesn't actually work.

SA: Yeah, the dependency [05:41] ____ hell and all the rest.

EC: Yep. And the more customizable you make things, the less likely it is to get the simple case off the ground and going quickly.

SA: Yeah. Do you feel like maybe it's hard to get off the ground and moving quickly, but those things help you do version two or version three faster? Or do you think it's the problems that you enumerated are always there?

EC: I think they're always there and I think it's also that we think it has to be this way because this is the way it's been. When we think about how dev tools has been evolving over time, we make things that make each individual step better, but it's because we're starting from our baseline of what we have. We had version control, we had CVS, then we had SVN, and so then we had Git. And those things are each getting better, but when you think about it, why does version control have to be the way we think of it being now? Same thing with editors. We had Vi, Vim, we had Emacs, Atom was the relatively new one. And we make these changes, but we're making these changes within these pretty confined systems that we're all used to. It's because, as developers, we think of these things as, "This is water, this is what we do." But it doesn't necessarily have to be that way.

SA: It's very diplomatic of you to mention both Vim and Emacs, so we don't have a war in here.

EC: I try really hard to not start... I will not talk about tabs or spaces either.

SA: Alright, fair enough. No question about tabs or spaces.

EC: No.

SA: So when you talk about the things that are already out there, you have the infrastructure as a service, I think of as like Amazon Web Services and Google Cloud Platform, and that kind of replaced actually having the box, in the rack, in the colo. And then you've got these platforms as a service, things like Heroku, I think is the one that really comes to mind. And then we've had people try to do other things like Skyline that are similar but a little bit more on top of that. Can you talk a little bit about those building blocks and what they've done to provide good things, and then where you see the opportunity going beyond what's out there?

EC: Yeah. I think a lot of services... I think there's a couple different ways that people approach that. I think a good thing that many of those services have done has been starting from a use case. And so I remember, getting started the first time I used Heroku it was like, "Everything's much better. I can now do every project I wanna do on Rails with Heroku, with Git." Like, "Great. So much better than what I'd learned before that." And so I think there are a lot of good starting places there that makes things easier. I think, even when you think about it, over time those services have continued to become more complex. Where with Heroku, you're still setting up Rails is 31 steps, you still have to figure out where you're going to put things. It's not necessarily easy even as it gets easier and is a more functional service.

SA: Did you say it's 31 steps to set up Rails on Heroku?

EC: Yeah.

SA: How long does that take?

EC: I think it depends on how many times you've done it before. And so, it gets faster, but I actually sat down, and wrote down all the steps as we started to think about this. Because people would say when we started talking about it's still too hard to build software, people were like, "Oh, no, no it's so much better than when we had to write Assembly, when we had to write C." And then when you sit down and start to think about it, it takes a long time. And I think one of the things, one of the inspirations Paul and I have taken from, in building this new company, is when you build a financial model in Excel any update you make to the financial model happens automatically and you get a quick win right away. When you're building financial model you have your first equation, and it works, and then you layer something on top of that, and then you layer something on top of that. Whereas, often when we're building things, like you're doing something like getting your scaffolding set up, it's two hours before something interesting happens.

SA: Yeah. It's weird to compare because you think of Excel as a weak version of a database, which is like a weak version of a program, and all of that and there's a reason why that works. And so it's really, really fascinating. Let's take a little bit about from the problem, talk a little bit about you and why it's interesting. You've obviously spent your career doing product management. And generally, I think of it as consumer facing or user facing product management. And now, you're building this totally new thing, that's really about developer happiness and developer throughput and things like that. And you're smiling, and you're excited. I'd just love for you to share why this is exciting for you, because it's so orthogonally different than what you've done before.

EC: I actually, I think there's two things about this. One is I think developer tools are the best of both the consumer world and the enterprise world, where you're building things for people and a lot of the way developer products get adopted are by an individual developer likes it and they tell their friends and then more people use it. And you really have this one-to-one relationship with someone who is building what you're using. And on the other side, you feel like you're making this tangible business impact and you have this ability to build a business and think through the sales cycle, and sort of have this linear progression. Whereas, with a lot of consumer companies, it's either, it works or it doesn't. And I think both of those things together is really interesting about the developer ecosystem that isn't in other places.

EC: And then, the other side of that, is personally, you mentioned or Tasia mentioned that I worked at Kickstarter and most of what I've done is, I love building products that help other people make things. And so I worked at Microsoft on Office Mobile, and I was excited about that because it was, "What is a mobile productivity suite for people who didn't have a desktop productivity suite?" And then at Kickstarter it's, "What happens when we start being able to [10:31] ____ give capital to people who couldn't do their arts work or their technology work before?" And I think with this it's, "What happens as we start to make our engineering tools so much better that more people are able to become engineers?"

SA: So is that the big win? Does that making it... Expanding the pie of who can make programs? And you believe that more people don't do that because it's just too hard, with the scaffolding it's too hard to get started?

EC: Yeah, I think it's ridiculous. We keep talking about how we need more engineers, it's obviously true. And when you look at how we build products, you think about, say, a standard consumer onboarding flow. You're taking anything you can to get any step out of that process, to increase your conversion by 5% or something like that. And then we expect everyone to be able to go through and figure out this complicated set of tooling, each of which has its own specialized needs in order to do engineering.

SA: Yeah. And so we're talking about making it easier and quicker and simpler, but one of the things we talked about back in the green room, is that this is not low-code/no-code. This is actually a still very technical product that requires people to know stuff. Can you talk a little bit about... That's a very conscious decision that you and Paul have made. I'd love to hear a little bit about like, "Hey, this is the vision that we have, but this is the way we're going about implementing it."

EC: Yeah. And so, I think there are places for low-code/no-code solutions in the world. I think they can be really good with solving a very focused, specialized problem. I think the issue is when you have a low-code/no-code solution, eventually you hit the limits of what the tool can do and you have to switch off of that tool. And I think there is something that isn't empowering about that when you're building things, you wanna be able to build, you wanna be able to tinker, you wanna be able to do whatever you can imagine making, and you can't do that in a low-code/no-code solution. Whereas when you start by building better tooling for engineers, if it's better for engineers someone else is going to look at it and say, "Okay, that's not this thing I looked at before, where it was, 'I can't possibly do that.'" Right now, I think we have a lot of people who are either, "I can code. I can't code." We have two camps. And it's really not like that, Paul and I think of it much more as being a continuum. We think of it as people who can use Excel right now are doing some basic modelling. They can get to the next level of that. Maybe they're hooking things up with Zapier, to be able to connect services together without really writing code. But when you think about how people think, you can get people further down that continuum of being able to use software as a tool.

SA: So you're not just solving the kickstart problem of getting started. It's all the way through. So someone could go from one person's side project to crazy Series C, big company, whatever, on your platform, [12:56] ____ without having to make those changes?

EC: Yep.

SA: One of the things you had mentioned earlier, is that when you're doing consumer, it's either, "Yes, good," or, "No, it's not."

[chuckle]

SA: And either you get crazy traction and it works or it fails completely. But for developer tools, you actually have an opportunity to iterate and do things better. Can you talk a little bit about how that has changed the way that you've built what you're building?

EC: Yeah. The interesting thing about building a platform is you need to... You can't just do it all at once, but you also need to get far enough that it's interesting. And so when we think about that, we think about testing all of the fundamental... This is just good product development, just testing all of the fundamental things we're doing. And so what we're starting with right now, is we're spending a lot of time working on our editor experience, and that doesn't mean our editor experience can build literally anything right now. It means that we start saying, "Okay, what's the first thing we wanna try to build? What's the first side project we would want out of this?" And then we build it, and then we bring other people in to try to build the same thing and see how it works. And that's just using everything ourselves. Paul and I both spend a bunch of time working in our code base. Everyone we hire will spend time working on this code base, I'm very excited about it. And so it's fun to be able to solve our own problems as we're building it, but it's also interesting to see how people react to it as we go.

SA: What's the most interesting or surprising reaction that you've seen, already, so early?

EC: It's really fun to watch people's reaction. One of the things we, again, took inspiration from Excel on this, is we show the output of every function in line, in the editor as we're building it, and so it's cool when people even do something simple. They're like, "Okay, I'm starting to do math." And you just see it in line, like you might in a ripple or in a tutorial, but it does that for everything. And so right now we've spent a bunch of time playing with the Twitter API, but you can see like, "Oh, this is the most recent tweet that Paul favorited." "Oh, this is the most recent person who followed me." And you can start manipulating that data to build interesting things, and it's fun to see that people aren't expecting it to be so easy. They're not expecting to see what they've built right there, right then.

SA: Do they find what you guys are building to be delightful or faster? 'Cause what I'm hearing is a lot of these squeal surprises of delight, that people get that instant dopamine feedback, shortening that loop.

EC: Yes. That is definitely what we're going for. We've learned a lot about that so... I would say, we're now in the fourth concept of how we're doing things and not that any of those has taken that long. This is a very new company, which is why it doesn't have a name. But I would say, each cycle, every two weeks, we learn something about the editor experience. And so, this week, it was, we felt like our for-loops felt like they took four steps instead of one. And so, then it was like, "Okay, clearly, this is better the way we're doing it now. What did we do wrong? How do we break this? How do we go about fixing that?”

SA: That's cool. So you've already gone and started doing that, so it's not just like, "Oh, we've got our roadmap and our vision, we're going through," you're still doing that small iteration cycle, going back and doing that stuff. How much of your work is new stuff versus making what you've already done, even so early, better?

EC: Almost entirely new stuff.

SA: That's awesome. So you guys have made the right decisions 95% of the time. You're just going through it and... 'Cause you know the problem that you're solving.

EC: Well it's also that we don't wanna get stuck in a box where we sit there and make everything perfect for the two of us and then we learn that no one else likes it. That's pretty much the worst possible thing we could do.

SA: Yeah. Spend forever, build the thing, drop it, and then no one does it.

EC: Yeah.

SA: Yeah. That's bad. One last question before we open up to the audience, is you've went from Microsoft to Kickstarter to Lola to this, and I believe you've travelled all over the country with these different jobs, right? Is there something unique about being here in the valley, for the good and the bad, but that made you decide that like, "This is where I wanna do the next phase of my life."?

EC: Yeah, it's about this company and I think that's to people in this room as well. I think, in this area, more people are willing to adopt new developer tools and more enterprise products. So until two weeks ago, I was in Boston, and it's a pretty hard sell in Boston to get someone to adopt a tool that they haven't seen before. And I think just sheer volume of people here who are willing to try things, and willing to work on it, ability to go to events like this, ability to go to meetups. It's just the density is completely different.

SA: Cool. Well, with that, I'd love to open it up to questions to the audience. Again, no questions about tabs or spaces.

EC: Yes, please no. [chuckle]

SA: But everything else, I think is fair game.

[laughter]

SA: Alright, well, we're going around. I have... I can keep going, 'cause this is super fun for me.

EC: Okay. [chuckle]

SA: You know, one of the things is, as a PM myself, and someone who writes terrible, terrible, terrible code, and so is no longer allowed to do that. One of the visions that you guys have is making it easier for more people to write code, deploy code, ship code, see the outputs. Do you have a feeling, in terms of what... Who's gonna be next? Is it the data scientists who are gonna do it? Is it the PM's who do it? Is it the marketing folks? Who's gonna grab onto this, that isn't writing and shipping code right now?

EC: Yep, that's a great question. I also, as a former PM, I feel like the best code PMs write, is you write really terrible codes, so someone else will do it. Where you're like, "I made this Amazon Echo prototype, it seems pretty cool." And then someone will completely productionize it overnight, which is always enjoyable. I think one of the things about it, and I think this goes to the fact that both of us were PMs who were writing code for fun, I think it's the people who really wanna be doing it, who aren't doing it now. And I think it's the people who are already willing to say like, "My day job isn't writing software, but I'm gonna go home and I'm gonna try it on the weekend because I wanna maintain that fluency." Or, "I used to write software and I don't get to anymore." People have moved into management or leadership roles that don't involve still writing code day to day and shipping it.

EC: So I think it'll be those adjacencies. I think technical designers would probably be one of my first guesses because they already... They have the way to think like an engineer and the way to think about building systems, in that order. And then I think, similarly, PMs, particularly, when... You've probably had this too. I feel like every PM has the stuff they put on the backlog, 'cause they know that's the right thing for the company and they have to do it. And then they have that feature that they really just wanna build and they'll spend all their time learning how to code, just so they can build that one feature, and ship it without wasting any time, theoretically. So I think that'll probably be...

[overlapping conversation]

SA: Yeah, wasting other people's time, but wasting your own time, it's totally...

[overlapping conversation]

EC: Yeah, wasting your own time's totally fine. [chuckle]

SA: Yeah, whatever, It's like my time's worth nothing. A PMs job is to unblock other people so you're real protective of other people, but yourself, whatever.

EC: Mm-hmm.

SA: When you talk about technical designers, that's actually a really interesting one. One, can you define what you mean by a technical designer? 'Cause I... That's an interesting term. And two, are we talking about going from sketch to this? Are we talking about... Just talk a little bit about how you see technical designers, what they do and how they'll be able to use Ellen and Paul's cool new start up.

EC: Yeah. So when I think about it, I guess I shouldn't call them technical designers. What I'm thinking about is people who like to design in code and like to design in the medium that they're working in. I think it's a relatively controversial topic within the design community. Some people think that by having to think through the implementation of things you make better choices. Some people think that by thinking about the implementation details while you're deciding what to build, you're actually constraining yourself unnecessarily. But there are people who like to go in the direction of coming up with what they wanna build while building it. And I think that's what I mean when I say 'technical designer.'

SA: Cool, got it. I see a question. There should be a mic. Ah, she's coming up now. Thanks for waiting.

Audience Question 1: To follow on that question, one of the things that I've thought a lot about over the past few years, is thinking about not only the roles that are going to be more relevant in this type of product, but also thinking about it from a context of the next generation of developers that are coming up, and thinking about it in the context of, generationally, the next group of folks coming out of school in the next five to seven years. Their minds are hard wired to think about things from the notion of, "I know that I can automate anything or I can connect these applications together to do what I want. So where's the tool that's gonna let me do that quickly and easily?" And just interested in your thoughts on that context of the change that's coming with the new people coming into the workforce as opposed to the people that are already there.

EC: Yes. I think the most exciting thing about building better tools for developers and making it more accessible, is that to some extent, everyone we have now will be such a small part of the pie. And so we'll have 10 times as many people, 100 times as many people who are able to do this and I think that makes the world look very different. And so, when I think about that, actually, I wonder a lot, if you could build a company without job titles or without descriptions, 'cause I feel like more and more it's about, "What specific skill sets are you bringing to the team?" It's like, we're hiring now and I can describe it as we want a developer who knows about functional languages and types systems and a developer who wants to prototype quickly. But I don't actually care if it's that thing, I just know that I want both of those skill sets represented on the team. And I think, one of the things that will happen, is people come and expect to be able to do this. They won't just say, "Oh, I wanna be able to do this therefore I'm gonna be an engineer." They're going to be people coming out of all disciplines who say, "I wanna use engineering to accomplish this," and it will be just be one more tool that they have available to them. And I think that will really change how we think about building teams within companies to get things done.

SA: Cool. Well, I see the big clock back there says, "Zeroes... "

EC: Okay.

SA: So I think we're out of time.

EC: Thank you for having me.

SA: Thanks for being here.

EC: Yep.

SA: Everyone, Ellen Chisa.