Jeff Lawson on Ask Your Developer, with Pete Flint - podcast episode cover

Jeff Lawson on Ask Your Developer, with Pete Flint

Jan 12, 202148 minEp. 70
--:--
--:--
Listen in podcast apps:

Episode description

The podcaster did not provide a description for this episode.

Transcript

And so it's no longer Beller versus buy. It's really become build versus die as this Darwinian evolution is occurring in every industry, and therefore, the role of software developers and the importance of unlocking that talent has never been more important. So, Jeff, great to have you on the NFX podcast. Happy to get to you. Thank you, Pete. It's great to be here and happy New Year to you and, all the listeners.

I hope that folks are waking up for 2021 and believing that it's going to be uphill from where 2020 was. That's for sure. We certainly hope so. So kind of rewinding. So we Pete, gosh, more than decade ago, I think.

So when I was running Twilio, you were running, you know, and still are running Twilio, we were a truly one of the very early customers of Twilio and was just such an important tool for us in the early stage trying to connect consumers and real estate agents with a web platform in this offline online world. So it's amazing kind of what you've achieved. Since those really early days. Maybe just to kind of let's take 2020 as a context. It's been a crazy, crazy year.

You said on mad money that you think coronavirus a sped up digital transformation by as much as 6 years. Like, tell me what you saw in 2020 for your business. Well, if you think about what Twilio does. Right? We've really always offered 3 things to companies, and it turns out they've been particularly relevant for the era of a pandemic. Know, Twilio offers, first of all, digital engagement.

So the ability to use all these digital channels like voice, messaging, chat, video, email to engage with with customers and, you know, really any stakeholder and to do so with a lot of flexibility. The second thing that we offer is digital agility. The idea that, you know, with software, you can build anything, and you can build anything relatively quickly. And APIs are key Beller that kind of agility.

And the third thing is cloud scale, right, the idea that when you build something, you're not thinking about racking up servers or doing capacity planning. You just build something. You push out to cloud, and it works everywhere. And so those three things, digital engagement, software agility, and cloud scale is what Twilio's offered, and it turns out the world is needed.

Those things really more ever in the era of a pandemic because we had to really rewire the world in so many ways in such a short period of time. And new challenges arose that needed people building solutions to them ASAP was really the story of the builders of 2020. And, you know, you think about some of these industries that were really reinvented on the fly. Yeah. I think about health care.

And as a, you know, fortuitous coincidence, Twilio announced, HIPAA support for Beller care workloads in February of last year. And that's something we had been working on for, you know, like 18 months, and we happened to announce it just in time for the health care world to embrace telemedicine like never before. And so we saw so many companies, whether they were technology providers or medical systems themselves adopting telehealth.

And Early in COVID, a huge percentage of doctor visits turned into telemedicine visits. And I think we saw a massive And telemedicine is not new. There had been companies building telemedicine. There had been medical systems experimenting with telemedicine, but, you know, relatively small percent of doctors visits were done over video while suddenly it was, like, half or more visits became video visits, and that has accelerated in one direction, the adoption of telemedicine now in the world.

And you think about other categories like e commerce, it saw a massive acceleration of adoption, and not just obviously, you know, Amazon, but every company that offers e commerce saw a huge acceleration. I remember talking to the CIO of 1 of the major big box retailers mid year, and he said that they saw a 5 year of their e commerce traction of their e commerce adoption in 1 quarter. And, you know, so many companies Pete dealing with then the challenges of great. How do we scale it up?

And what are all the other problems that then arise, you know, so that executive was talking about how contact center for e commerce was completely overwhelmed with customers asking about orders and returns and all that off all the things you typically would play out over the course of multiple years of slowly building that infrastructure and staffing those teams played out over the course of a Currier. And so companies had to catch up and build. And so that really the story of 2020.

When I look at it, companies had these digital transformation plans and the whole industries did, you know, like, telemedicine and ecommerce and these curbside pickup workflows and all these things, and they just got accelerated. And most of these workflows are not special one off things that we did for COVID.

These are the natural course of the digital transformation of nearly every industry that just got accelerated out of necessity as we had to remove all face to face interactions in society and make these industries work as completely digital businesses. And so when I talk to a wide variety of leaders, they basically say, look, this gave more prominent these projects. It accelerated budgets.

It accelerated executive attention on these projects that would have potentially taken years, got done in quarters or sometimes even weeks. That's really amazing. It's totally amazing. It's amazing how this infrastructure that you've built up over time becomes this essential piece of infrastructure for communication, for work, for everything. It's remarkable.

And and so maybe just take a step back into 2008 when you're first starting Twilio you know, the vision has become a kind of a huge part of a society and the reality today. But back in 2008, maybe just just thinking through where you were back then and recognizing that our audiences, a lot of early stage founders, like, what was the starting point? How did you think about business back then? And what was the original idea?

I think that when you look at companies with sort of a big world changing vision or mission, those are usually retroactively put in place. To be honest. That's like the secret, but, like, the dirty secret of, like, every startup ever. There's a certain selection for companies because I think it is probably the startups that have this giant world changing vision on day 1 probably get so blinded by this.

We have to change the world and we have a vision and blah blah blah blah that they actually miss the opportunity right in front of their noses. And so I think probably the best startups are those that aren't founded with this, you know, idea of this giant mission. They're founded with a relatively simple thing is I know a customer segment that has a problem, and I'm gonna go solve it.

And if you do that really well in the early days of a startup, you kinda earn the ability to say, okay, we did that. We're making money and we're growing. What's next? How do we decide how to take our early success and turn it into future success? And that's when you start thinking about, okay. So what is the real, like, North Star of our company?

And, like, when we have to pick the next thing we're gonna do, should it be over to the left or should it be over to the we need some sort of guiding vision. Now we're gonna install a framework to help us make those decisions. And so that was how it was at twilio, which was what we knew was I'm a developer. Been a software developer. Yeah. I've learned the code in the nineties, and I had started 3 companies before Twilio. And I was one of the first product managers at Amazon Web Services.

And when I left Amazon, I knew I wanted to build my next company around something that I was passionate about, something that I get really excited about. And I thought back to, you know, my time as a developer and as a company Beller. And I realized that at every company I had started prior to Twilio, there were really two things in common.

This fact that there were very different businesses, but the common intersection of all the different businesses I had started was number 1, at every one of those companies, we were using power of software to really build a great customer experience, a differentiated product and iteratively understand our customers and build better and better and better solutions using software.

And to me, that's the superpower of software, your ability to listen to a customer and quickly iterate your way towards a better and better customer experience or product or solution for that customer. The second common thread though that I had in every one of those companies was in the course of building those companies, those experiences, those products, we had needed communication because we had needed to reach out to customers, let them reach out to for a wide variety of things.

You know, sometimes it was in our marketing, sometimes it was during our sales process, sometimes it was customer support, sometimes it was while they were using product. There are all these places where we'd say, oh, wouldn't it be neat if a customer could reach out to us and we could get them this answer, or wouldn't it be neat if we could proactively notify them this or that. And every time we'd have these ideas, we said, yeah, that'd be really Pete, but I'm a software developer. What?

I don't know the first thing about communications. You know, that's like, Currier wires and satellites in space and like, so you call these, the companies who seem like they didn't know this realm. You call, you know, the, you know, the hardware companies. The Currier and you'd say, Hey, you know, we have this idea. We're trying to build it, and you explain it to them. And, you know, the salesperson would say, we're happy to help you with that.

You know, first step is you're gonna run copper wire from the carrier to your data center. And then step 2, you're gonna buy a bunch of hardware and rack it up. Then step 3, you're gonna buy a software stack. Pop it on top of that telco hardware in step 4, you're gonna bring in a whole professional services army to come bang the whole solution into shape. We think we can do that for you, but it'll take, you know, 2 to 3 years 2 to 3000000 dollars, you know, sign Pete. We'll get started.

And every time I had this experience, I said, wait. Hold on a second. Like, we're a startup, spending 1,000,000 of dollars on this one feature idea. We can't really do that. More important than that, because maybe there are some companies, some, you know, big enterprises, maybe they could sign that check very easily.

The more interesting part of that answer was years It would take years to build this this v 1 of this idea we have, and customers would never get to play with it until we had built the whole thing and spent 1,000,000 of dollars in years. And then once has told us all the things wrong with it, then we have to embark on the next version, which is, again, would be 1,000,000 of dollars a year spent.

This is the complete opposite of that software ethos Everything we do in software, we can measure it in, like, weeks. That's what sprints. That's what agile is all about. You know, it felt like everything in the world of communications was like the old waterfall model, which kinda makes sense.

Like, it's an industry where they've been accustomed to launching satellites and putting up towers and buying spectrum for billions of and, you know, laying down 1,000,000 of miles of copper wire all around the planet. You're like, yeah, those are hard. Those are slows or high stakes things, you know. So I understand that, but how we get value out of communications isn't about all that anymore. It's really about the software now.

And so started Twilio to solve a relatively simple problem of how do we bring communications into the realm of soft and enable every software developer in the world who's has an idea like we had always had to be able to build it quickly and easily. And that was where we started and having done that in, like, the key thing though is if I was the only developer in the world who would have that problem, then we probably wouldn't have built a meaningful business.

And so I did a lot of research before we started Twilio talking to other developers and basically describing the solution we have in mind and asking, would you have a use for it? Every time I talk to a developer, they would say they kinda scratch their head for a minute. They'd say, and then eventually they'd say, well, wait a minute. I have a question that idea that you talked about the the telephone API. Could I it made some use case they had recently.

Could I notify my customers when a package shifts from my e commerce website so that they don't keep calling customer support to ask where the package is? And I would say, yes. Yes. That'd be really easy. And it's, oh, yeah. Great. Well, Pete me try it when you build it. And after having that conversation enough times, realize that I was not alone in wanting of seeing these use cases and needing a way solve it, and that's what gave us the conviction to start the company.

And it turns out now we've got over 10,000,000 developers in our ecosystem and over 200,000 businesses who are customers of Twilio. And so the key to me was, 1, solve a customer problem and, 2, make sure that the customer problem you're solving has legs to be big enough to solve many customers problems so that ultimately, it's a big opportunity worthy of your time and energy. Yeah. I mean, I think the sort of original vision is truly Morgan out, and I think there was a simple solved.

I think a lot of people didn't realize how big an opportunity was and the timing, obviously, with the rise of the smartphone was where you kinda have this sort of telephony meets software environment was obviously hugely impactful. Obviously, during that time in kind of 2008, we went through a recession back then. And now, you know, we've got this sort of crazy.

It doesn't necessarily feel like a recession in the sort of, like, in the same way, but clearly there's a sort of economic change going on. How have you personally navigated dischange with impact to coronavirus and remote work. And how have you, as a founder, CEO, evolved your leadership to successfully navigate in these crazy times? I think in a time like this where there's so much pain suffering or the very best discomfort that everybody is facing. The way to lead is with empathy.

And you know, I think about it. You know, I talked very early on in COVID. Obviously, we closed all our offices the 1st week in March. Everybody started working from home. Now luckily our business is one with a lot of knowledge workers, so we're able to do that relatively successfully. But, you know, talking to a lot of employees realizing how everybody is struggling was something. You know, nobody is immune to this. Right? You think about, you know, people with kids.

They were struggling with homeschooling their kids. Pete who were single and lived alone. They're struggling with loneliness. People with roommates are struggling with the fact that they did not pick their roommates because they wanted to spend 24 hours a day with them. And so many of them were, you know, very sick of their roommates very quickly.

It's like everybody introverts, you know, are oftentimes in a home with no escape to be alone and extrovert they were trapped in their home with no one to talk to. Like, everybody was struggling with something. And so as a leader starting with empathy and starting with just hearing where Pete are at and how best you can help people through the very real and very personal struggles that they're having while also helping them to be productive people in the company to achieve the company's goals.

And you can't strike that balance if you don't have and don't know where people are. And I think encouraging, not just like, you know, myself, but encouraging all the managers inside of the company to approach their job in that way was really Morgan. And kept emphasizing to manage.

Like, you know, one of the things that I said early on in COVID, which I think turned out to be true is, like, I find oftentimes you start a call in normal James, you know, you a friend, a family member, a coworker, and say, hey. How's it going? How you doing? And in COVID, I would start calls like that. How you doing? And then realize that, like, that you know, throw away question that often we start Omri calls with, actually to kind of real meaning.

And you'd follow it up with, how are you really doing and actually get to a real conversation with folks how they're doing, what they're struggling with, how they're feeling good, how they're feeling bad, and encouraging every leader in your company to really approach their conversations that way and to moderate the work to meet people where they're at. Some days, you know, I'm feeling down, and you can take up some slack. Other days, you're feeling down, and I can take up the slack.

And that is how we together are able to actually, push the company through and how we're better together. Yeah. Q.cu. Yeah. Get on to it in a bit, but you've been so thoughtful about company building and culture Beller, and it sort of really shines through. And I think that the investment that you make early on when times are good pays off dividends when times are challenging. Secure to see you.

Maybe switching gears to a little bit, the early stages of reaching developers and scaling, like developers with a ones that were really spreading the word for your product, how did you start that? And was that very much an intentional approach of this sort of bottoms up developer strategy or something else We know it's interesting. Part of our strategy here was driven by 2 things.

1, I had a conversation with an early venture capitalist who I'd known from prior endeavors, and I pitched him on the idea. He was like my safe pitch because I knew him really Beller. And for feedback, and his feedback was, wow, you're gonna need a lot of sales this thing. And I said, oh, no. No. No. Not at all. Developers are just they're gonna buy it. We're not gonna need sales. This can be amazing. He literally laughed me out of his office. He said, yeah.

Yeah. But I did start the company with a very much a bottom up, like developer focused mindset. Now, of course, we have since come to add a lot of salespeople, and so the venture capital was right. But initially, we did focus a lot of our energies on just how do we get the word spread? How do we get Twilio into the tool belt of every developer in the world? That's the goal.

Because if they're anything like me, once it's in the tool belt, they will have all these opportunities to use it because the business problems that arise that developers are tasked with so often need communications that if we're there in the tool Beller, the moment that problem arises, they will use Twilio. And that has proven out to be true. And so we just started by treating developers like customers. And it's like sounds really simple, but there's a lot to it.

Most companies who claim to serve developers actually don't see developers as customers. They see them as a strategy. They see them as, like, you know, you think about, like, the big platforms that added developer element to what they do. It's about how do developers make our platform better. And so developers aren't customers. They're like an audience that you try to win over in order to add more value to the company. And if it works, great. If it doesn't, then you change strategies.

And that's why a lot of the platforms so frequently say, Hey, you know what? I know we put out that API last year, but working out. We're gonna pull it back, and developers mistrust those things because they are not the customer. They are part of a strategy. And so we always said developers are the customer, and you treat them like a customer, you treat them as the source of your revenue and the source of your success as opposed to a strategy.

And so part of what that is, like, I actually took a lot of inspiration. One of the companies I started before Twilio was a streams Sporting Goods Pete business. Actually, bricks and mortar retail business in Los Angeles, a store called 9 Star, and we were doing skateboarding, snowboarding, surfing, BMX biking, all this kind of scheme type sports. Yeah. It was totally random. I don't do any of those sports. It's a long story.

But one of the things that always struck is super interesting about that is that those are like lifestyle sports. Those are like Pete who skateboard think, like, they kinda wrap their life in the ethos of that sport. They wear the clothing. They visit the store's locks. They love hanging out with other people who do that sport. They are always interested in the new gear. They watch the sports on TV. They've got their heroes. Like, it's a lifestyle.

And I think software developers are actually kind of like that. Not all of them, but a lot of them where they actually, like, think about it. They go to work. They write code. They come home. They got their side projects. They write code. They love reading things like hacker news just to learn new tips, new tricks, and always get better out of this sense of curiosity and enjoyment of this field that is both a profession, but also a hobby. And so we treated it like that.

You know, we did a lot of things, I think, to help encourage We sponsored a lot of hackathons. We ran hackathons. We, you know, gave out a lot of t shirts. At one point, I predicted that we would give a, I don't remember the exact actually. It was actually Blackberry. It was like when the iPhone was launched and you could sort of see the writing on the wall for Blackberry. I said, prediction in 5 years, Twilio will ship Morgan shirts than Blackberry ships phones. That may have been true.

But track jackets are were a big part, and they still are a big part of our culture. And the idea was, you know, to create this sense of pride is like, I'm a Beller, and I wanna connect with other builders. And I've got my tools, and I've got companies who really understand that and help me unlock the best. Like, I'm very inspired by Nike as a brand and as a company, like, the idea that they took the idea of unlocking the athlete in every person is their mission, give or take.

I it's not exactly the wording, but that's how I interpret it. And I think that idea of how do you let something come out of people that is inside them in a part of their life and a part of who they aspire to be. And I think that every company in many ways wants to be builders and wants to be builders of technology and wants to be able to compete with the likes of Google and Amazon and Uber and Facebook and be an amazing technology company, and it's hard, but it's aspirational.

And I think part of how we thought about it, both at the individual level as well as company level is like, we're gonna help you do that. We're gonna help you be great at this thing that is aspirational for you. Yeah. I mean, back in the day, the developer conference, the event, I mean, the word was out, and it was clearly are those sort of tactics were highly effective. As you think about the strategy, you know, I know from Truly's perspective, we implement Twilio during a hackathon.

And it, you know, suddenly it was implemented, and then it was just, like, irreplaceable. I'm sure that kind of embedding defensibility is being hugely valuable. But, you know, as you think about network effects and, obviously, something we and effects think a lot about. Like, what do you think about the broader platform opportunity here? I know that company has been very active in M and A. Over the last couple of years?

Like, how do you think about border defensibility and the network affects your building at scale today? I think that a lot of people hang a lot of their hopes on, like, network effects and, like, that's what'll make us succeed. I'm a little less of a believer that there's, like, the silver bullet, if you will, of success.

And a lot of people look at the success stories of network effects, you know, like Facebook and believe that if they can only build that, then, you know, that's the key to their longevity or their success. I don't totally buy into that, to be honest. I think that that is one tool in the toolkit of trying to make it that the more people you serve, the better off all of your customers are, but that's certainly not the only tool in the toolkit.

And I think a lot of people put too much into that one tool because you look at some of the successes of, say, you know, a Facebook and all that kind of stuff. I just think you gotta have a multi pronged approach to add more value to your customers every And it's sort of as simple as that. And so network effects are often thought of as, how do I create a stronger company? What's my moat? Really, I'd be asking the question How do I add more value to my customers?

And as I grow, is there a way that the rest of my customer base or the rest of my or whatever I'm building makes my solution better for all of my There's a lot of ways to do that. You know, one way is to build a comprehensive product that moves quickly. So as I think about Twilio, we very quickly went from a one product company to a multi product company. That bucks the conventional wisdom in a lot of ways.

A lot of conventional wisdom was like, you know, do one thing, do it Beller, you know, find a niche, get rich. Like, there's a lot of fancy sayings for it, but I'm a believer that in the world software, you have to try a lot of things because it's relatively inexpensive to try things. And so we very quickly, you know, Twilio Voice was our first product and we pretty quickly only, about 18 months into the life of the company announced our second product, which was twilio SMS.

And it turns out that, like, SMS is probably a a bigger product than voice. And today, it certainly because the number of use cases for it Pete really exploding, and we're really unexplored because SMS had been a really pretty esoteric and difficult to use technology up until Twilio, and so we unlocked a lot of innovation around what is possible with messaging. And And so I think that's a way.

And then we continue to invest, and we've got now, you know, video, chat, email, as well as, you know, now data infrastructure and a lot of facets to our platform. And the idea is once you get to know Twilio, there are so many ways you can adopt us and use us. We just solve a bigger and bigger set of the challenges that a developer has. But for a company, what they're looking for is more comprehensive solutions.

And that's where having one platform that shares all of these attributes instead of having to go cobble together lots of different things really helps a company to pick a vendor that they trust that they wanna work with and allow that company to go solve more and more challenges for them. And I think that ultimately the key to success especially in B2B is trust. You know, trust is the number one thing that you sell. And, you know, you think about what the cloud is.

The cloud is saying to your customer, Hey, you know, this part of your business, whether it's your infrastructure, whether it's some app, whatever it is, trust that we are gonna execute on this idea better than you can do it internally. Trust that we are gonna keep building, that we're gonna keep it reliable and secure, and we're gonna add features and functionality, and we're gonna do it better than you can do it yourself. That is essentially asking for your customer's trust.

And so fulfilling on that trust every day, that's ultimately how you build your business, how you retain your And I like to think that we earn our customer's business every day. So there's no idea of, like, we don't think at Twilio, we don't think about lock in, and we think about, you know, any of those things, all we do is think about how do we earn our customers business every day with a combination of trust and execution. That's how we do it, and that's how we stay ahead of anybody else.

That is scalable to, like, every business, if you will. You've done. I mean, it's such a terrific job. I think just from a kind of network effects perspective, we think about this straightforwardly. So I think exactly what you just said, which is, like, as you add more users, how does the service become more valuable for every other user is exactly what you've done, exactly the same process we think about network effects.

And then also defensibility, clearly, you know, you've built a variant during company, which is in defensibility is really coming from embedding from scale, from network effects, and also brand, which is really a proxy for trust.

So q. C u. And it does seem, you know, I think a lot of You may have seen this in your journey, but early on, investors, I think, might have perceived what you're doing as plumbing for services that could be easily ripped out or doesn't provide scale benefits or isn't trusted. And I think they probably misunderstood how big the market was, and that's been borne out clearly that this is an enormous Morgan, and this is not a commodity process or commodity product in any way.

You know, it's interesting. There's a good book I've recently discovered called 7 powers. Have you heard of it? I've not heard of it now. I'll make a book recommendation here. 7 powers by Hamilton Helmer and he talks about essentially, you know, what is power power is your ability building your company to achieve essentially long periods of outsized returns for your shareholders. And then he says there's basically 7 fundamental powers that enable you to do that.

And, you know, most businesses don't have all of them, but thinking about these in terms of how you are building power in your business, I. E. The ability to have outsized returns is Morgan. And he's got several ones, counter positioning, scale economies, and it's kind of what network effects often goes to switching costs, or network economies, actually, more of the network effects, 1, process power, branding, and corner resources.

And so I would give that as an interesting book recommendation to any listener who's interested in kind of thinking about, you know, I wanna serve customers, but I also wanna make sure that I don't give all the value to my customers because if I'm starting a company, I need to create value for myself shareholders too, which is absolutely fair. And I think there's a pretty interesting framework that I've recently become a fan of. Of course. Okay. Checking it out.

Okay. As on the, Amazon order list. So talking of books, you are releasing a new book called Ask Your Developer. And so what's the kind of genesis for this? You mentioned the prologue that there's a and I've seen it so many times that Arthur developer billboard, and this is a kinda quick code for developers. Tell us a story about that. Well, you know, we it was about 2014, I think. We had bought a billboard we need to decide what to go on it.

And we'd hired a firm, like, you know, like, a communications firm or whatever. And they, you know, they did a lot of work. They talked to a lot of you know, of our employees. They talk to customers and, you know, they basically pitched us and, like, here's the, you know, here's the best idea. It's like we're gonna, you know, great companies use Twilio and, like, put a logo I'm like, Beller, it's like we just spent 6 months to figure that one out. And, so we're stuck with we got a billboard.

It's going up on Monday, and we need the creative. What are we gonna put on it? And something that had been in the in my head for a long time. Like, one of the things I just would think about in the shower or whatever was the whole idea of, like, you know, those commercials for drugs, they say, ask your doctor if Currier than is right for you. You know? And I was just, for some reason, my brain just always went to ask your developers if Twilio is right for you.

And so I were in this meeting, and we literally just had to, like, we could not end the meeting without deciding what went on the billboard because it was, like, going up on Morgan. And I just blurted it out. How about ask your developer? And everyone's like, what do you mean? And I'm like, well, know, it's just sort of like developers know about Twilio and, you know, executives should be listening to their developers.

And, you know, that's one of the Morgan trends that's really going on is developers are able to adopt services and tools very quickly, very inexpensively. You know, things like Stripe or Amazon Web Services Morgan anything else that are allowing them to innovate faster and drive the businesses forward. And so, really, I think that executives should be, you know, listening to develop both in terms of like, you know, it's sort of like this wink and nod to the developers of the world.

Like, hey, you know, you know about Twilio, good for you, but also this bigger message around developers should be thought of as leaders inside of companies who actually know a lot about what companies need to do to innovate and to win in this world, and and businesses should consult them. And so we did the billboard And, you know, it's sort of interesting because you go back and forth. You know, some people are like, what an idiotic billboard? It doesn't tell me what you do.

Obviously, we have our tagline, you know, tagline on it that says, you know, Twilio you know, communications platform. But in some ways, it is so simple that it's easy to consume, but has sort of profound implications. And so, like, over the years, thought a lot about this notion of asking your developer, like, what does it really mean? You know, it's sort of like a fun tag and it's a fun billboard. Because it's a wink and a nod, but it also I've thought a lot about the implications of it.

And over the years, you know, was 10,000,000 developers in our ecosystem and 200,000 customers. And I've had this conversation with so many different customers through the years asking me, typically their business executives saying, Jeff, I have a question. Like, we're struggling to figure out, like, how do we get really good at building software? How do we hire great developers? How do we organize the team? How do we make sure we retain those developers?

Because, you know, hey, we're not like a Google or a Facebook or someone who's known for being a great engineering culture. And so I've shared my tip over the years. And, you know, I thought about it some more, and and I'm in a somewhat of a unique position, being that, hey, I'm a software developer myself, but now I'm also the CEO of a public company.

And so and I see the division between that developer mindset and the business mindset because I live with one foot in both of those worlds generally And so I took my unique vantage point and wrote down in this book, essentially, how do we create a shared parlance, a set of understanding between what business executives are trying to accomplish, and what developers and technical talent what they want to accomplish and how they go about

doing their job because there's so many things about how developers do what they do that I think are not really fully understood by especially business executives in the world. And so by starting to create the shared understanding, I think it can help businesses to you better in the digital realm. You know, I kind of start the book by drawing the comparison to, you know, look, it used to be that IT was something you outsource.

That, you know, this stuff, like, back in the era of they need to manage laptops or, you know, deploy the ERP system. You're like, yeah, you know, that's something that's outsourced. It's not a source competitive advantage. In fact, it's a cost center. We just need to be as cost effective as possible. It made sense. You would outsource all that stuff.

But about 15 years ago, you know, what started to happen with the web and now with mobile is the interface that most companies have with their customers is suddenly a digital interface. Yeah. It used to be your bank. You know, you thought your bank was a good bank if, you know, you walked in the branch and it was, you know, well kept. It was designed nice. It was clean. The teller was friendly, and they gave your kid a lollipop.

Now you like your bank if they have a fast mobile app that, you know, adds new features and functionality that helps you in your daily life. If they're listening to you and they're building new things and the mobile is easy to use and always getting updated. Right? That's what makes your bank seem like a good bank to you because your bank is now an app. It's no longer a brand. And in that world, every company needs to be able to listen to customers and build.

That's how you differentiate in the eyes of your customer. You know, you can't just buy a solution off shelf, the same solution that, like, every other one of your competitors has and assume that you're gonna be differentiated. Like, no. You have to build it. Listen to customers. And so it's no longer build versus buy.

It's really become build versus die as this Darwinian evolution is occurring in every industry, and therefore, the role of software developers and the importance of unlocking that talent has never been more important. Yeah. That's so clear today. I mean, you see it from the kind of most famous and most successful people that, mostly software engineers, or I've spent time being software engineers, today, the most successful Pete. I guess do you see that?

Is that message still not resonating today, or is it just that people don't have the capabilities to execute in that way to turn their business into digital businesses just because they don't have the skill set? Well, I think that a lot of companies have realized as, you know, the years have gone on and people have seen disruption in industry after industry.

I think people realize that it is hard to actually create a world class engineering culture is hard to hire developers and make them successful. And so that's really why I wrote the book is just try to share some of the things. Like, I find that, you know, development is this weird esoteric and complex thing. And it's relatively new.

Like, we've only been doing it for, what, like, 30, 40 years, but in the modern, like, agile sense, we've only been doing it for 20 So it's a new addition to the economy and to the world and a lot of mystery around it. And, you know, software developers don't always help this.

You know, these mysterious questions that we don't have great answers too that can really infuriate, I think, you know, business leaders and myself included, like, I've been in these conversations, been like, oh, this is infuriating. You know, questions like, you know, executive says, yeah, we got our big marketing. We got a big conference.

We need to ship the thing, and the technical leaders will say, well, I can tell you when we're gonna ship it, but I can't tell you what we're gonna I can tell you what we're gonna ship, but I can't tell you when we're gonna ship it. And you're like, I wanna pull my hair out because it's such an infuriating answer, but it it is largely true that you know, there's unknowns. And the way you account for unknowns in software engineering is by relaxing either features or time James.

And so there's a trade and any engineering leader who, by the way, is a third one, too, quality. So any engineering leader who will tell you, yep, I promise you all these features on this Pete. Guess what they're giving up quality. And so and there's often the unspoken thing that's getting relaxed there.

And so it's like, what I'm trying to do is explain to executives, like, here's how software engineering works so that you can have a mature and realistic conversation with your teams instead of, you know, the sort of like pound the Beller, like, I demand it and like getting crappy product. That also wasn't something you wanted, but if you don't articulate it, then that's probably what you're gonna get if you demand features on a date.

Another one I think is interesting is, like, you know, as business executives, you know, one of the main tools that we have, if not the main tool is budget. Right? That's how we kind of can make decisions and actually, you know, we can give budget or not give budget to various initiatives or James. And so oftentimes, you know, an executive might hear, oh, this project is running Pete, and their, you know, default reaction is to say, well, great.

Let's just, let's throw more money at it and hire more people. Let's get it back on track. It's counterintuitive, but that actually will typically make the project even later. And so I go into explaining why. Why is it that you can't just throw money at a late project and expect it to catch up when in fact you'll pay do more harm than good. And so setting out to create this common parlance between, like, how does great development work? And what are some things you need to invest in?

You need to invest in engineering, infrastructure, to make them successful. And I draw a lot of parallels to James, actually, because I think a lot of executives had to learn how sales work and they know what their great salespeople are capable of, and they can draw the line between what really good sales looks like and how it impacts the business.

And so I draw a lot of parallels to things that we've learned about how sales processes work and try to map it to, like, how development processes work and how engineering culture and engineering capabilities will help you build a great business, but you need to be able to speak the same parlance. Like if you just yell at a salesperson, you know, why didn't closed the deal Pete.

It's like, well, understanding how a sales cycle works is really the key to understanding, you know, if your sales process is healthy or not, but just kinda yelling at them about closing the deal isn't really gonna get it done. James thing goes in engineering. You wrote in the book, don't treat developers led digital factory workers to the new creative workforce. Guess, two questions. So what was that something that you kind of experienced personally as your time as developer?

And then also, you know, someone who's spent some time coding as well, there's something imagine a lot of engineers. There's something quite special about the developer mindset, which is quite different from the sales mindset or the finance mindset. What do you see as the superpowers of the developer mindset, and then also what is perhaps some of the challenges with that mindset? Well, the interesting thing is that code is a creative endeavor.

And what you do when you write code is you do a lot of creative problem solving. And, you know, that involves obviously figuring out how best to solve the problem with code, writing that code, debugging that code. I mean, these are all creative problem solving endeavors. You had a lot of businesses assume that the only type of creative problem solving developed are capable of is turning a specification document into a, you know, Pete of code.

And so they, like, literally a lot of businesses are constructed in a way where it's like, well, we feed in, you know, product requirements documents on one end and, you know, some Morgan dew, and the other end, we get some code. And I think that is totally discounting the capabilities that so many developers have as creative problem solvers.

So my biggest thing that I advocate is don't share solutions with developers, share problems And what you do is unlock the full creative problem solving ability of those developers. Right? And so what I mean by that is, you know, a lot of businesses create walls okay, these are the customer facing Pete, and let's say you've got product managers, and their job is to write a specifications document for what we need to build and to throw it over the wall to the engineers.

And then the engineer's job is to write software that matches that specifications document. And so what you're doing is you're sharing a solution, build this thing. I wanna form with field that says name and 40 characters long, and I want you to go build that.

And if a developer has no idea why they you need that form and doesn't know anything about the customer or the problem that's getting solved, Beller, they'll dutifully build you your form even if there could be much better ways of solving that problem.

But if you share with the development team and with the developers, here's why we need to build this We're trying to reduce the friction in our sign up form and make it so a customer can get started in 30 seconds instead of half an hour, which it currently takes. Now you've got developers say, well, there's a lot of good ways to solve that problem.

And by the way, you know, whenever we think of as our first step, you know, there may be a hundred steps after that that can make it better and better and better.

If you take the problem and put it in front of the team, that enables them to use their full brain and come up with things that connect both their understanding of the technology, the understanding of the architecture of what you have and find the, you know, least path highest impact way of getting to a solution to that problem that may not be available them if they either, a, don't know what the problem you're trying to solve is because they just Pete handed a spec.

Or, b, the spec doesn't give them the leeway. To actually come up with a better way to solve that problem. And so that's where sharing problems instead of solutions really accelerates your development and gets the most out of your talent And the other thing that it does is it treats developers like full human beings with full set of capabilities, and the best developers wanna companies where they use their full brain.

And so if you hire developers and don't allow them to do that, I suspect that many developers won't stay in those jobs for very long because they don't feel like they're getting fulfilled by the work. I couldn't agree. Well, you're under pressure as a CEO to be the person with all the ideas and the solutions, and that's complete disaster.

I know personally when you open it up and you share the problem, not the solution, then the creative, you get the full creative force of the Morgan, and it unlocks remarkable ideas, and it's a necessary ingredient for a startup success. Switching to kinda culture and communication, I remember hearing you speak at a conference about draw the out, and it was part of you'd be very thoughtful. This was many years ago, very thoughtful about culture building.

Can you explain just firstly about how you think about the internal culture at Twilio? And then kind of perhaps into the book, what are the cultural changes that businesses need to make to fully other than sharing that problem, not solution? To really unlock the full power of this digital transformation. So I think about culture, you know, people often use the phrases culture and values interchangeably, and here's how I think about it. Actually add a third one to it, the operating system.

The culture of a company is what you feel when you come to work every day. You interact with your coworkers. You interact with customers, and you go back doing your job. How do you feel? About that. That's really the culture of the company at work. That's a very amorphous thing. Right? How do you feel? And so what leaders need to do is to put words to that feeling I think of those words as handles that let you guide it, that let you steer it, that let you maintain it.

Those words, those are values. That's taking a feeling you have and you want people to have and putting words to it so you can ensure it's proper development. Cause if you don't have handles on the culture, then it can go off in all sorts of directions. Cause you think about it, like, if you're growing your company, there's lots of different people who come from lots of different perspectives and mindsets, and they will just bring who they are.

But if you have handles on it, you can actually guide what we do together and what we accomplish together, how we work together. That's the goal of having values and making them actively used as handles to guide the culture of the company. And as I think about values, you know, you mentioned one of our values draw the owl, and that comes from an old internet Pete, how to draw an owl, step 1, draw some circles. Pete 2 draw the rest of the owl.

And, like, in the early days of Twilio, that just tickled us. We thought that was so funny, but, like, it kept coming up strangely in building the company. Like, somebody would, you know, ask me a question. Hey, does anyone know how to do this? And someone would just say, you know, draw the owl. Right? Who basically means figure it out. Ship it. Like, there's no instruction book. It's ours to write. So ship it and figure it out and iterate.

And so one thing I found is that you articulate the values of company, what you're really doing is you're creating the unique parlance for this group of human beings. And every group of human beings has essentially a set of heroes, rituals, and symbols like, they come to identify that group of people. And you see it in religions. You see it in countries. You see it in colleges.

Like, when you affiliate with a group of human beings, There are symbols, heroes, and rituals that help you to become a part of that group. And then in many ways, that's what you're doing because you wanna create this sense of pride and affiliation the group of human beings that are gonna work at your company. And so that's why I thought of it. And, like, you know, nothing, like, you think about typical company values words like integrity. You know, that's fine word.

I know what it means in the dictionary, but is it really one that you use in your everyday language? Is it really one that differentiates your group of human beings from the next one? Not really. And so it ends up becoming one of those empty words in the wall. And so the way I've thought about it is, like, you know, we have a value. No shenanigans. First of all, I think it's more actionable. You have the sense of, like, what I'm doing shenanigans? Yeah. Maybe it is. Right?

Like, you can actually think about that. But number 2, is it's a unique word. You know, no shenanigans. That's why people say it a lot inside of Twilio. And because it's unique, because it's memorable, you kinda want your values to be almost hashtag word of these so that people remember them and can invoke them in making decisions because that's where the values really become a part of your company when people invoke them regularly to make decisions as teams.

That's where the values are doing their work. And the third thing I mentioned is the operating system, which is kind of a newer part of my thinking Pete, you need an operating system that speaks to the values and the culture really come about when you're doing the work of the company. And a lot of people think of culture and even values as some things that are like in the hallway, the conversations, the water cooler type stuff, for the, you know, do people hang out?

And that's not really where the culture is made. The culture is made in getting the work of the company done. How do we make decisions together that everyone's not gonna agree with. How do we hold each other accountable? You know, those are the real things where people are gonna disagree. People gonna have have different ways of solving problems. And it won't be clear how you resolve those tensions. That's really where the culture is made.

And so I've started to think about you need to build a set of mechanisms and take those values and turn them into mechanisms or practices within the company that actually put them to work and help the company to resolve those tensions in a way that is the way you wanna do it for your culture and your values. So for example, one of our values is ruthlessly prioritized, and we put that into practice with a system we called James, and it's our planning tool.

And it's, you know, sort sort of like OKRs, but it adds one very important thing to the OKR system that OKRs don't generally contain. Prioritization. So you've got your list of goals. We call them priorities, and they're in order. And you force a conversation. What is more important than what And when we inspect James Pete documents, where we write one for the whole company, there's a lot of discussion about why, number 1, number 1, why is it better than number 2 or number 3, right?

And actually the ordering of those things is super important. So we took this value of ours ruthlessly prioritized, and we turned it into a practice that is now used throughout the company to make those hard decisions and communicate them to other people. And so that's the 3rd part, I think, of building a great company culture is actually taking your values and putting them into practice with these mechanisms that are used throughout the company.

Yeah. And it obviously changes over time how you think about the printing systems you need to Beller from early stage to mid stage to late stage to public. So, Jeff, you make a really compelling case about the need to think like a developer. And then that perhaps there's Morgan Chesky Airbnbs who's sort of banging the table for saying his need to think like designer. Are these things in conflict? They're not. There's a place, obviously, for both.

I think, you know, developers you don't even think like a developer this is a lot of different personalities in the world, but what you need to do is respect the things that developers can bring to the table and how they can help you be creative problem solvers in the business. As opposed to just feeling like they're code monkeys. And the same way I feel about designers. Like, designers have a role in so many processes. And, you know, I think of designers as people who tend to think outside in.

They think about the interfaces that customers are gonna use, not literally interfaces, but, like, designers tend to think about what the internal appearances of a thing are, and they think less about maybe the internal machinations of things. And you need that. If all you do is think about how it's Beller, like, which is what engineers often think about, and they don't think about how it's used, well, you'll often end up with suboptimal outcomes for your customers.

But if you just think about the exterior appearances, how it's used, we don't think about how it's Beller, that can take you on a path of a lot of pain with bad architectures or the things that aren't scalable or things that don't actually work. And so you need both mindsets. You need the mindset of creative problem solving in terms how can this technology be used to solve a big hard customer problem?

And you need the designer mindset of saying, if we build a thing to solve a customer problem, are we sure that the users are gonna get the value out of it that we think they're gonna get when we started out. And so I think they're very complimentary mindsets. Yeah. And then obviously going back in history, so Leonardo DaVinci He was both an amazing visually minded designer, but a remarkable engineer as well.

So I think over time, we've kinda separated these disciplines think that if companies hinge their success on being able to hire the next Leonardo DaVinci, I think that is not a strategy probably for building a business. Yeah. I think you need to accommodate the fact that most people are not gonna be great at both things. You need to build a team that has all the skills you need. I agree. I do think that many of the best developers have a designer mindset and vice versa.

There's a just this curiosity and customer orientation and how they think about kind of solving problems in different ways. It's usually valuable. The customer orientation part, absolutely. Like and you need to Beller in part of the book, I do talk about, how do you get your small teams to be really customer focused?

Organizations, if you think about it, as they grow up, they tend to build a lot of silos and a lot of walls that are designed to shield technical teams and developers from customers, you know, customer support or your sales team or your sales engineering team or product managers themselves. Are all designed in some ways to prevent your engineers from talking to customers.

And I think that's a big disservice to your customers, to your engineers, and ultimately to the mission of the company you're building, and really what you should seek to do is, like, the product managers in particular, they should be the ones who their job is seen as, how do I facilitate the right engagement between the engineers of people building the process that people wanna solve those problems and customers.

And, obviously, you can't, you know, put developers all the time on the front lines of every sales cycle or every customer support in clearly, you need to have those functions. However, if you Pete those silos go up, you know, poke some holes in those silos and make it so developers do get opportunities to interact with the right customers and to take those learnings away. It really inhibits your ability to design and build things from that customer perspective.

Yeah. We talked a lot about software development as applies to business, and it clearly is true that sort of digitization and software processes are kind of embedding everything that happens in today. I'm curious as you think about how this sort of this mindset and software development is applied to broader life and the decisions we make in terms of how we live, who we spend our time with. Is there any insights that you have about applying this mindset to one's life?

I think there's a creative problem solver mindset in a whole lot of people. And I think if you try to let that come out in your work and in your personal life, and embrace it, you know, whether it's, you know, personal things you're doing, hobbies, whatever. And I think that if you can actually figure out how to apply it to your work and your personal life. You know, I think that just leads to a fulfilling life because I think human beings, I think we're sort of wired to build.

I think that's part of one of the defining attributes of humanity. And so giving yourself places where you can exercise that, I think, is, I think for a lot of people, not everybody. There's no number one rule for every human being except we need oxygen and calories, but I think there's a whole lot of people for whom they would benefit from being able to exercise that creative problem solving ability, but who your job doesn't necessarily involve it on a day to day basis.

And, you know, think about how to incorporate that into life. That resonates with me. I think if you look back in this sort of industrial revolution, it was focus on mechanization of everything and really sort of humans doing robotic tasks and thankfully computers doing a lot of those robotic tasks. Today, and now it kind of frees up the creative juices and ability to really apply kind of what is fundamental to us. So maybe we end on that. This is the opportunity to Beller.

As we go into 2021, you know, developer mindset to use creativity to build something remarkable is truly a good for the world. It is time to build. The world has bigger problems, than we've seen in a long time. And so it is a time to Beller, and that's a great way to end. Well, Jeff, thank you so much for spending time with us today. Looking forward to reading the book, Ask your developer. I'll be sending a few copies to our UNFX portfolio companies for sure. Thanks again for joining us today.

Thank you, Pete. It's great to be here. And to everyone listening, I hope you have a fantastic 2021. You've been listening to the NFX podcast. You can rate and review this show on Apple podcasts, and you can subscribe to the NFX podcast on Apple Podcasts, Spotify, Google podcasts, or wherever you get your favorite podcasts. For information on building iconic technology companies, visitnfx.com Omri.

Transcript source: Provided by creator in RSS feed: download file