Road to CTO: From Mafia Wars to Amazon, 35 years of tech leadership wisdom

Welcome to another episode of Road to CTO, our series where we sit down with some of the most experienced and influential technology leaders in the world.

In this episode, we talk with Dorion Carroll, a veteran with 35 years of tech leadership experience, former CTO at Zynga, VP at Amazon, and one of the most insightful engineering minds in the industry.

From scaling engineering teams from 280 to 3,600 people, to navigating billion-dollar decisions, to understanding what truly makes a great CTO, Dorion shares the lessons, stories and frameworks that shaped his extraordinary career.

If you're an aspiring CTO, an engineering manager, or simply passionate about how world-class tech organisations operate behind the scenes, this is a masterclass.

Chapters

• 0:00 Welcome And Framing The CTO Role
• 3:10 Translating Tech For Boards With Data
• 8:43 Stage, Scale, And What CTOs Must Own
• 11:50 Cloud Whiplash: Zynga’s AWS Return
• 16:30 Building Core Competence Around Customers
• 19:30 Paths To CTO And “Lesser” CTOs
• 23:30 Checklists, Mechanisms, And No More 3 A.M. Pages
• 27:00 Mentorship, Ownership, And Making Yourself Obsolete
• 32:45 Scaling What’s Harder: Tech, People, Or Process
• 36:00 Patterns, Anti-Patterns, And Revisit Patterns
• 41:00 Board Dynamics And Telling Hard Truths
• 45:35 From C-Suite To Amazon VP And Back
• 49:10 Making Amazon Mobile-First In Practice
• 54:00 Humility, Trust, And Principles In Leadership
• 1:11:36 Farewell And How To Reach Dorian

Transcript

SPEAKER_01: 0:00

The closer you got to the individual game, typically the less senior you needed to be because you didn't have the scope. This if you're the CTO, you need to be able to understand what is your role in terms of the people, the product, and the process, but all underpinned by hopefully your superior understanding of technology. Understanding I'm not spending enough time looking forward. The house is on fire, and I'm, you know, front man with the fire hose putting the fire out, I shouldn't be that person. I should make sure there's somebody else who's been trained to be able to do that. Then I should be thinking about what are the, again, the tools, the processes, the procedures, make sure the house doesn't catch on fire next time. You know, if the CTO says, oh, it's really fast, like you're full of shit. If you can change Amazon, that feels like a pretty major accomplishment. And in two years, I did. We have to think like the customer. Stop thinking like a web designer and your web pages and it's like you can't just load a web page with hundreds or thousands of products listed. The network will choke.

SPEAKER_00: 1:05

So what what did you find more difficult to scale? Like technology, people, or decision-making processes. Uh right, Dorian, good to see you. Welcome to Life on Mars. Thank you. I'm really glad to be back. It's good to see you, Alex. It's uh this this conversation actually, actually, you provided a very, very good conversation around the topic of finding a CTO, not so much about becoming a CTO. The first time we met in 2017, you were traveling around Europe. And um we hosted a Star Brand event, which at the time they were not totally not technical. But you know, not every day you get the CTO slash CIO Zynga. And I said, let's take on the chance. And I we had a conversation about how to find technical co-founders and how to find CTOs. Do you remember that conversation, how it went?

SPEAKER_01: 2:15

I sure do, yeah. And it it was actually really interesting because there were a lot of very successful and inspirational product people, financial people, operational people. There were some technologists in the audience, but they were really hungry to learn more about how do I find that great tech person who's going to help me bring my vision to reality.

SPEAKER_00: 2:37

And the set, yeah, and actually we did it we did a very special place because we did a coding bootcamp called Idolheck, which at the time they were really good friends of ours until they stopped teaching Ruby on Rails, but that's another story. Jokes aside, uh, I think we also got like some extra tech talent to attend that event because usually we didn't get technical people to come to the event. We got more like founders and CEOs and stuff like that at the start of it. But I remembered from that conversation the amount of it's very hard to talk about technology without going into technical detail. But the way you explain things made me think that he He has to be very good CTO because he's able to convey the ideas, the technicalities with plain language, accessible to business people, which I guess it's one of the most difficult traits you have to acquire when you want to become a CTO. It's like, how the fuck do we explain this thing about technical debt or terraform to the CEO, right?

SPEAKER_01: 3:38

Or the board. When when do you acquire that? Especially when it's very expensive. They don't want to spend money. See if you know it I I've learned a lot in like most of my career. You know, I I started in tech in 1986. So going a while back, uh, actually, really from the very beginning, everything I've done has been driven by and through data. And what I found that in in talking to the CCs or talking to other leaders or people you need to be able to convince, when you have data on your side, uh it makes it a lot easier. It just you have to be able to tell the story, you have to be able to help them understand the relevance of that data. And as I just think forward over, you know, it's 30 plus years of working with teams, with leadership, with data and systems and all of those things. And then I look forward for the next 30 years with AI, it's it's still all data. Uh, and so for me, that through line is a really strong grounding point. Data isn't necessarily the thing that will ground every technical person and will create the road for them, but I found in all the different industries that I've worked in, the closer I got to the data, the closer I got to the truth, the closer I got to being able to influence the organization, not just in terms of getting people to do what I think is right, but actually understanding what is going to be right. And then you have all of the aspects of scaling data, staging data, purging data, you know, all, you know, figuring out the costs associated with it and how to process it and turn the data into information and sort of create even more value as you move up the chain. And I think as compute and data set sizes have gotten bigger and more powerful, we can look and examine it so much more, but at the same time, you can make mistakes so much faster. And those mistakes can be horrendously costly.

SPEAKER_00: 5:40

I'm not gonna talk about the technical fuck up you shared four years ago, five years ago. I'm gonna leave people with the burning desire to find out. I'm gonna I'm gonna forward people, I'm gonna lead people to the to the episode who recorded back then. But uh I guess there's a lot of enduring uh because to my understanding of this is uh you know, the CEO is the ultimate decision maker of a company, the CEO reports to the board, even though like a CTO might report to the board as well. Um I'd say the ultimate decision maker of the of the company is the CEO. And the board having more financial and business backgrounds, they might have a harder time understanding the technicalities of some of the uh some of the things that the CTO wants to do in the company, right? Oh, maybe we need to refactor, maybe we need to uh increase the the size of the tech team, maybe we want to change this technology, maybe we want to break down the monolith and stuff like that, right? And it appears to be that most of the times when these conversations happen, like it's very hard for these arguments to become first-class citizens, right? Uh it's always like fundraising, hiring or firing, changing the leadership or product strategy and stuff like that. And the technical stuff is like second division. Um, how have you personally endured these conversations, this amount of rejection all over the years?

SPEAKER_01: 7:10

I I'll I'll get to that specifically, but I think it's important to add a little bit of additional context, particularly if we're thinking about the road to CTO, because it ultimately depends on the stage of the business. It could be a startup where the CTO is the most technical person, is perhaps the technical co-founder and the one with the vision. Stage could also be a very mature business is looking at radical transformation, and they need somebody who can think outside of what they've been doing because they're looking to transform that business. The other is scale. The scale could just be you're going from three people to 30 people, and there are actually several points of change in that where it can be the technology itself, but it may also be the process and procedure. Three tech guys sitting around a table coding and sharing code is very, very different than a team of 15 engineers and a couple of product managers and a CEO. And this, if you're the CTO, you need to be able to understand what is your role in terms of the people, the product, and the process, but all underpinned by hopefully your superior understanding of technology. And being able to do all of those pieces together can help you navigate the situations you're talking about. But you know, I have one very specific example that comes to mind uh where uh at Zynga, we had moved into the AWS cloud. You know, there's several stories out there already about that. Uh, we were able to grow some of our largest games because of what the cloud provided, but we encountered several limitations with AWS at the time. And the CEO, with the then CTO, decided to bring all of that cloud computing back in-house. And so we uh rented data centers, we built out infrastructure, we created our own virtual cloud. The theory was we'd be able to burst loads from our private cloud up into the AWS cloud if we needed. That theory never came to practice. It was actually a pretty foolish idea in the first place. I don't think anybody's really getting into that sort of full fluid cross-cloud computing, uh distributed computing, and expansion contraction. But you know, there are other ways around that. And we got to a place where you know the business had turned sour, uh, the old CTO had left. Uh, I had moved into the role of the CIO and was responsible for all of this infrastructure, all of the cost, all of the personnel uh responsible for running it all. And the the CEO at that point and the CFO were saying, okay, how do we build out our data centers? How do we continue to drive better efficiencies while also ensuring that we have the future capacity we're going to need for our future successes? And you know, when I really looked into it all, what I figured out, working with my team, was that we should not be in the data center business. We should not be in the cloud business. We're a game company. We should be focusing all of our critical resources and our best and brightest minds on creating better games and better game architectures. And so I had to go in and show them in terms of the four years of 12 and a half megawatts of data centers that we had purchased on both coasts of the United States, uh, in order to replace all of that depreciated and now failing hardware, we would probably need$100 million of capital. Well, that was a number, so use the data. That scared them. And I said, we spent$150 million last time. So I'm actually telling you we can spend less this time, but it's still a giant number. And oh, by the way, you're saying we need to think about compressing our teams, shrinking our teams. The hundred people I'll need to be able to find that hardware, test that hardware, build that hardware out, build that infrastructure out, they don't work for us right now. So I have to hire a hundred people. Like, that's a number. I could back it up. What are the skills? What do they have to do? When would they need to come on? When would they roll off? And I just I created a very credible story to say we need to go back to AWS. They're the experts in cloud computing. We're not. They have the expertise in exactly what distributed computing platform we should be working on, what underlying storage systems we should be thinking about, how we should optimize this kind of a workload versus this other kind of workload. They'll work with us. Our engineers can be focused on that next layer of value in terms of what's directly going to benefit the customer. We're not moving machines and networks and cables and physical things around. That's not our core competency. And so being able to tell that story back with the numbers helped them understand this makes a lot more sense. And again, it just sort of came back to what is our core mission as a business, as a product? What are we doing for our customers? And building data centers isn't it. Like AWS, that's what they do for a business. That's great. Let them do it. And we could have gone with Google, we could have gone to Azure, you know, we could have gone different places. We were very familiar with AWS, so that just worked for us.

SPEAKER_00: 12:32

It's great. But I think this sort of conversation is gut-level CTO stuff. I think that most of the people who are listening to this podcast will never have this conversation. Or maybe if they're able to become a very successful CTO slash CAO. Like in your case, take me take me back to the to the beginnings, right? Because I'm very much intrigued about the first time you heard the word or the acronym CTO. And were were you inspired by it? Did you want to become one? Or or you thought, like, oh, I'm never going to be CTO. I don't want to be CTO. I just want to keep coding and doing like, I don't know, getting my hands dirty.

SPEAKER_01: 13:12

Yeah, well, uh a little bit of a precursor to that, but it just directly in answer to that, it was probably uh, you know, I started out as a marketing analyst and and office manager for a three-person uh investment management firm in San Francisco. I was there for a year and a half. I then uh went to a mutual fund company. Mutual fund company, although we had technology and we had databases and you know, lots of things to process what the investments were and who the the prospects or customers were. It it was much more about the financial services side. It wasn't so no, there were no CTOs. I went to Oracle from there. Oracle may have had a CTO, but it's even then in the early 90s, CTO wasn't uh a title that people threw around a lot. Uh I don't think Larry wanted the leather C's. You know, this is like he he he was the only chief. He was the only C. Yeah. And then you know, from there I went to Electronic Arts, which was much more of a studio-oriented company. Each different game team had their own technology product. They they approached it depending on you know what kind of a game it was, what platform it was, but again, not really a CTO. Uh and then uh at uh I I went from there to Excite, which was the search end engine and web portal. And there, interestingly, because they'd acquired a few companies, they had more than one CTO, depending on which part of the business. For Demetrians, for products? Well, I mean, so the Excite search engine had their uh co-founder and lead technologist who was the CTO of that. They had acquired another search engine, Webcrawler, who had a CTO who was incredibly competent and good at what he did, really a brilliant technologist. And then uh there was a third acquisition and you know, yet another CTO. They worked it out where only one of them really had the title, but each of them, in their own right, really stood at the top of the technology team. They understood the current infrastructure, the current technical architecture, the current workloads. And what really distinguished them and made me think, hey, these guys think differently, is their ability to look forward and decide it's not what's next, it's what's way after that. Are we even positioned to be able to get there? And then fast-forwarding a few more jobs at Zynga, uh, again, a game company, studio-oriented. We had five major games. Each of them had a CTO. That was the first time where I got the title of CTO, uh, uh, but on what in one of these game studios. And we were growing very, very quickly. And one of the things that as the five CTOs, we would meet on a weekly basis and discuss what was working, what wasn't working, what were the three greatest challenge we challenges we'd had to solve that week, share that expertise, uh, and then split up, run away, and go do our own thing again, uh, was this shared sense that for us to be incredibly successful, we need to be making ourselves obsolete in our current role as fast as possible. So anytime you're doing something, figure out a way to make it so nobody ever has to do that again, that a junior person can write a tool so nobody has to do it again, a more senior person can write a tool so nobody has to do it again, or a junior person has to manage it, or a senior person has to manage it, but try to work those core problems out to the system, the extent that you can create the process, create the procedure, create the practice, create the mechanisms to make those things that broke not break anymore and just become easy, then you can actually start thinking about the harder problems. And so there's this really interesting tension and dynamic in being a CTO is recognizing the problems you have and helping people understand how to make those go away while understanding, thinking about and anticipating the problems you may have in the future and doing everything you possibly can to prevent them from happening. And when they happen, do the deep dive, do the post-mortem analysis, build the practices, the processes, the procedures, the mechanism, so that whatever just went wrong doesn't go wrong again the next time. And they're a very concrete uh example and a little bit of the bittersweet of doing things, at least in the way I think was the right way. We were launching games pretty frequently. You know, every two to three months we were launching a new game. And most of the games shared a relatively similar architecture. Uh, but each game, you know, the game teams themselves, either the game was different or they just thought, no, we're gonna do it differently. We're gonna we're gonna have better technology than the last team. And invariably, in the initial days, well, hours, days, and weeks of a launch, if a game is successful, it starts to scale rapidly. And as those workloads really ramp up, you start to find all of the mistakes that have been made, whether they are the new mistakes, because you change technology, you change a version of something, you change how you implement something, or you didn't pay attention to the last team. And so my simple thing was just like, okay, every time we launch a game, anything that breaks, we're gonna put it in a spreadsheet checklist and share it, and then we're gonna document this the solution that had we done this, this would have prevented it from happening. And, you know, it started out as a couple of items. Uh, and then, you know, make sure you warm your caches before you open up the, you know, everything to the thundering herd of customers that are trying to come in. You know, any any of those sorts of classic mistakes that people make, but helping those teams avoid all of those mistakes so you can avoid the 3 a.m. emergency calls and emergency code pushes and all those sorts of things that really burn people out, but also uh help them focus on the things that truly matter. So leverage the the recognition of the past, the things that worked, the things that broke, the things that made the things that broke not break again. And use that. And you know, I think by about the 15th game, it was over 200 items. And we had a program management team and the CT, the the lesser CTOs, it's I hate to call them lesser CTOs, but these were the games that hadn't yet proven themselves. Uh into that, yeah. Yeah. They they felt like this was just bureaucracy. You're just making me do all of these things, uh, and it has nothing to do with my game. And they started to abandon the list, and then they would get the 3 a.m. calls and things would break, and customers would be pissed off at them. And it just, it's not like we knew everything. It's just we had created this body of knowledge that not only said, here are the things that will go wrong and wake you up in the middle of the night, here are the things to do before that so it doesn't happen. And it seems pretty common sense. What I was going talking about before in terms of procedure practice process mechanisms, I think what we failed to do is our mechanism was here's a spreadsheet. And what we should have done is turn that into code, or turn that into templates, or turn that into configuration as code. Ways that all you have to do is check out this repo, run this build script, and the 30 things that could go wrong in all of these ways won't go wrong with you. And you can have a junior engineer do that. You don't, again, that idea of either make it so nobody ever has to do it again or move it down the stack uh in terms of seniority as fast as possible.

SPEAKER_00: 20:39

You touch on something that is very interesting that we haven't covered in this podcast series before, which is the lesser CTOs. And I was gonna go into that because when I was taking a look at your LinkedIn profile, and I I remember from our conversation in 2017 that prior to becoming like a one of the chief chief officers in Zynga, you had been the CTO of Mafia Wars, if I'm not mistaken. One of one of the uh I'm not into mobile gaming, so uh I know fuck all about this. Only Pokemon Go. That's the only thing.

SPEAKER_01: 21:10

Before mobile gaming, so exactly.

SPEAKER_00: 21:12

So that's actually Facebook gaming, right? Yeah, social gaming. Um but for me it's very interesting because you have the idea of product level CTO, then you had a division-level CTO, then you had a company-wide CTO, right? So my question is when did you have the oh shit moment I'm the CTO now? Because I don't think you can get that feeling in a product level. Maybe you have the CTO feeling of or or that feeling of, oh shit, I'm the CTO at your previous companies where you were VP engineering and you are managing effectively speaking, perhaps larger teams that are Zingat product teams. I don't know if I got that question through.

SPEAKER_01: 21:52

No, no, you you did. And I this this brings up another point, which I think you alluded to at the very beginning. And you know, in terms of what I mentioned in terms of scale and stage, within this particular game organization and the game hierarchy, you know, from individual product to a game franchise to a division to the company at large, um, we obviously the closer you got to the individual game, typically the less senior you needed to be because you you didn't have the scope. You weren't looking at all these problems across an entire division or across the entire company. That said, you might actually have to be much more technically connected because you're down as close to the product as possible, where the division CTO is looking across lots of things. They still might be incredibly talented, but typically they're going to be the ones who are more experienced and can recognize uh situations and issues or help prevent them where the others are actually implementing. And so you sort of have this mix of what percentage of your time as an individual contributor engineer are you spending coding? Are you spending on administrative tasks like meetings or planning or writing documents? And uh what what amount of time are you spending looking forward? And you know, a general rule of thumb, it's like 70% of your time is focused on coding, 20% is the admin stuff, not just meetings, but you know, you've got to do some research, you've got to figure some things out, and then maybe 10% of your time I'm thinking about the future. But for the CTO, depending on your scope, you might actually reverse that. Where you're spending 70% of your time thinking about the future, 20% of your time with the administrative uh burden or or you know the the the efficiencies, hopefully you can get there, and then 10% actually with your hands dirty in the technology. And as you move up that stack, you know, as uh you know, from a product CTO to a franchise CTO to a division CTO to the company CTO, I think those percentages change. And I'm just these are general rules of thumb. It may be very, very different. You know, in a startup with 15 people, if you're the CTO, you're probably doing a lot of coding. Uh you know, and so it it doesn't, it's not a universal rule, but there really is a difference. And I think the thing that helped me was as I changed and developed in my road, uh understanding I'm not spending enough time looking forward. You know, the house is on fire and I'm you know, front man with the fire hose putting the fire out. I shouldn't be that person. I should make sure there's somebody else who's been trained to be able to do that. Then I should be thinking about what are the, again, the tools, the processes, the procedures to make sure the house doesn't catch on fire next time. And I need to start thinking about that, not necessarily why the house is burning, but you know, once we've got that under control, and then really starting to think forward a lot more about why did it catch on fire? What are the things that made that happen? Why, what are the things that we can do that will prevent that from ever happening again? And it it's it's how you spend your time thinking. And as a CTO, you might be close to the technology and the person who's expected to think about the future of that technology. You might be more in the VP of engineering role, as you were saying before, where you're actually thinking about the team, you're thinking about the skill set, you're thinking about the career paths and the progression of those skills. Uh, you might have to do both. And so at Zynga, that was the thing that was really interesting is when I was hired in, Mafia Wars was starting to grow rapidly. Uh, unfortunately, it was, you know, falling over every day because they just had too many users. And they, no, they had a bunch of really smart 20-year-old engineers, but they'd never done this before. So they didn't know why it was on fire. They just knew it was on fire, and they're all there with their fire hoses and their bucket brigades. Um, and at that time, there were, again, I said to the five major games, Mafia Wars was one of them. And the feeling inside the company was the CTO has to be the most senior technical person on the team, and they spend all their time in the technology, understanding the technology, helping everybody else figure out the right way to do things with the technology. And like I said, in some cases, that is right. They didn't have any CTOs at that point for their game studios, who were also VPs of engineering. And after about three months, uh, I moved from individual contributor to managing a team of about 15. We called them the Systems Pod. They were the guys that dealt with all the infrastructure, scaling the machines, configuring, upgrading software. They made sure that our infrastructure, because again, we were running everything uh ourselves at this point before moving to AWS. And that was a very technical team. That sort of operational excellence role was something I'd done before. So I was very familiar with it. But what I needed to do was again to recognize the things that these people were doing and what can I do to help them be the most effective they can be. And so, probably six months in, I ran the entire engineering organization while still being the senior most technical person on the team, helping them dive deep when they need it. But from you know, falling over several times a day to some changes were put in place, we only fell over once a day, then we only fell over once a week, then only once a month. And after about five months, the game stopped crashing. And people kept you know going into this. Like, well, why are you spending your time on all of this infrastructure? Why are you spending your time on all this process? Why are you doing it like we need our engineers coding? How many lines of code did they check in? It's like, you got it wrong. That is not what we want to do. We want them doing the most valuable work they can be doing. And part of it was I was the senior most person on the team, so they kind of had to listen to me, you know, from a technical perspective. I had a good working relationship with our general manager, who was essentially the CEO of our game, and making sure that they bought into those sorts of uh decisions, which made them feel like we were slowing down. But in fact, we were laying the foundation and making sure that it was very solid so we could go really fast. Because if the game's falling over every week and whatever you were shipping this week ain't shipping this week because every it's all hands on deck to put the fire out, uh you don't you don't have any regularity. You can't actually promise senior management, you can't promise your customers we're gonna get these features out because you don't know what's gonna burn next.

SPEAKER_00: 28:22

Yeah, that there's like in all of these, there's a couple of things I don't really understand, perhaps because I haven't been in the context of such large companies. And like, for instance, defining like these lesser CTOs, from the point of view of the company, you're sort of empowering them to be the ultimate responsible for this area, this division, this franchise or this this product. But at the end of the day, if they don't do their job, there's going to be another CTO on top of them, right? So I know their job is on the line if the product doesn't perform well, if you don't solve these burning issues and whatnot, but you're not a CTO, effectively speaking. So I don't know if that really drives your salary up, uh drives your ego up. And what are you gaining as a company by enabling all of these lesser CTOs?

SPEAKER_01: 29:10

Yeah, that's a really good question. The one thing, you know, I thought you know, Zynga had a ridiculous proliferation of the title CTO.

SPEAKER_00: 29:17

It's like, you know, you're the CTO like dilutes the word, right?

SPEAKER_01: 29:22

Or the role, it just dilutes. It's like everybody's a CTO. Yeah. Yeah. Well, and that was, you know, Mark Pinkus, the founder, one of his things is everybody's a CEO. His point was whatever you own. That's Zynga thing. Okay. You own. And so if everybody's CEO and you're a technologist, well, you then you're a CTO. Like, yeah, okay. But you know, at the point we had 30 CTOs, that was kind of ridiculous. Uh again, there was a hierarchy. What what you know that idea of the lesser CTO, it was more like these are people who have developed enough of the necessary skills, proven themselves to own something of consequence outright. We had mentors and other uh ways that people could get help, request help. You know, I met with probably five other game CTOs, sort of these lesser CTOs, uh, typically once a week, sometimes every other week. Again, several, you know, very easy questions. What went what they tell me three things that went well this week. Tell me three things that went horribly, and tell me what you did. And what are you going to do next week? You know, and whether it's technology, whether it's people, whether it's process, whether it's pushing back on product because they're asking for too many features, and you need to be able to figure out how to prioritize, you know, building out some infrastructure uh security or some stability or whatever it might be. And just taking what I've been through and in some very simple questions. And they knew what the questions were, so they can come prepared if they wanted, and just help them from all the stupid mistakes that I've made. It's like, oh, when I did that, here's the terrible thing that happened. And all of a sudden, they could see I can get ahead of where Dorian was at this stage in his career because he just gave me that secret. I don't have to do those dumb things. I can, I can go past it. And so we had uh you know a technology organization that was very communicative. And I won't say that everybody was in support of everyone else and rah-rah, but there there was this aspect of, hey, we see this senior engineer who really is showing potential. He's got the ownership, he's got the technology skills, he needs some help. How about we put him on this little game in a CTO role and you act as his mentor and help grow them? And then that idea of making yourself obsolete every six months, it's like whatever you're doing now, you shouldn't be doing six months from now if we're gonna grow. And we grew from 280 people when I started to 3,600 people 18 months later. So whatever I was doing when the company was 260 people, if I was still doing that, you know, at 3,600 people, I was doing a really terrible job and I shouldn't be there anymore. Uh so you have to look for other people and groom them. And then if you're on that road and you're that person, you gotta look for the people that either have the knowledge or are willing to share it with you. If they're not willing to share it, then you got a problem.

SPEAKER_00: 32:17

But uh on the subject of mentorship, now that you bring it up, it seems like the thing that these like lesser CTOs were mentored by the up immediately upper level CTO. But how about in previous companies? Um, there was there any moment like you you flipped the switch and you understood that you were becoming a great leader, not only a great engineer, and from there you started pursuing the CTO role? Or or did you have any sort of conversation with a mentor in previous companies? When did that happen? When did you have that moment of enlightenment?

SPEAKER_01: 32:52

So that that was uh maybe eight years before the the Zynga times I'm talking about, uh maybe even a little bit 10 years. Um I was at a point where I'd been managing a team. This was I was uh running the technology team that ran the ad platform for excite, the web portal and search engine. I I probably had 12 or 15 uh engineers working for me. Uh I had kind of made myself obsolete before uh that phrase had entered my vernacular. But it was like I was looking around, going, well, what do I want to do next? Because I've got a guy that I've trained up. He's fully capable of doing what I'm doing. It's not really that challenging for me. I think I can add more value at the company. How do I have that conversation with my manager, uh who was the VP of engineering? And I just said, I'm just gonna have the conversation with him. He's here where I am, I'm at a crossroads. I see there's a lot of opportunity in the company, but I'm not actually sure what I want to do next or where I'm needed most. And he asked this really simple question, which I was just brilliant. He was a great leader and manager. Um he said, Well, what do you like to do most? I said, Well, I like to solve problems. That that to me, that's what it's like. The why is the thing that really motivates me. The the what and the how are interesting and you have to know how to do them, but the why, why did this break, or why can't we get this to scale, or you know, why are we doing it this way? That was the really interesting part. They said, okay, so if you really love solving problems, because I was struggling, there was one team that had five very senior engineers. And I I love working with really smart, experienced senior engineers. Like the stuff that you can do is phenomenal, but it's very much of a startup environment. Uh and, you know, personalities can get in the way too. But it's it's always incredibly uh rewarding to work in those small teams. And there was another product that was growing that I think was probably 30 to 50 engineers and other sort of technical support staff that had the opportunity to grow. I said, I, you know, I'm really attracted to this small team. I've done that before. It's so rewarding. Well, I haven't done this other thing. He said, Well, if you think about it this way, how many hands do you have? It's like, yeah, I have two hands. Okay, got it. He said, Well, if you've got a team of 50, how many hands do you have? Well, you got a hundred. It's like, okay, how many problems do you think you can solve with two hands? Versus, how many problems do you think you can solve with a hundred hands? It's like, aha. I can do a lot more with more people, but it's a totally different set of skills or or things that I would have to exercise while the underlying technology and thinking those things through would still be a requirement. And so I took that job. And that was sort of my first transition into sort of a larger scale VP of engineering role. But then we were we were launching the Excite Shopping Channel, which required us to partner with a lot of content providers, you know, whether it was, you know, people had their merchandising in uh XML files or in JSON files or in some database or CSVs. You know, we had to figure out how do we scalably pull in updates to the product catalog, and how do we uh do that in a way that will adapt to each and every one of these things as we bring new merchants on, as those merchants change the way they represent their data structures? How do we normalize all that data? Again, it gets back to the data pieces, but there was there was an awful lot that needed to be thought through that was, if not programming per se, it certainly was about technical technique. How do you want to approach this? What layers of abstraction do you want to put in place? How what kind of performance do you need? How quickly do you need to be able to process updates so that changes at some merchant site are reflected in our catalog? And so those sorts of things, but also run a team of 30 engineers.

SPEAKER_00: 36:46

Actually, the the road to CTO is very convoluted and it's very different for everybody. Like a lot of people come out of a corporate, like uh I interviewed an ex-Google who just became CTO right after Google X. Uh, there are people who become the CTO by staying 30 years in the same company. And like one of or one of one of my co-founders in his previous job, he joined the company as an intern and became the CTO 10 years later, right? So that's possible. Some CTOs are product people, some CTOs are more like information people, and some CTOs are cybersecurity people. There's a lot of CTOs. And I oftentimes make the joke that everybody can be a CTO if they string the company tight enough, right? So you can be the CTO of yourself. You can see you can be the CTO of a really small company if you don't have the expertise. But I I seem to understand that prior to joining Zynga when you were VP Engineering and you had held that title at a comp a couple of companies before that, you could have probably become a CTO, right? Like a global CTO, a company-wide CTO. Or do you think that going into Zynga and becoming a lesser CTO prepared you more to become a CTO than actually making the jump from VP engineering to big-time CTO?

SPEAKER_01: 38:07

I don't actually know the answer to that. Um I I took the job.

SPEAKER_00: 38:11

Is it related to team size or to responsibilities? What is it related to?

SPEAKER_01: 38:17

As you were talking, a word popped into my mind, and I I feel like it's probably a critical attribute of most successful people. But I think for technologists and people on the road to CTO, it's perhaps more true than for others. And that word's curiosity. Uh you have to have curiosity. You have to have curiosity about the technology, curiosity about, you know, can this actually do it? Can this be done? What are things that nobody's ever done before? What are the things that everybody's done before but never been successful? Can you make that successful? I'm sure entrepreneurs have to have curiosity. There are lots of others. So it's not exclusive to the CTO. But I suspect there are not very many successful CTOs who aren't curious. Uh and so you know, with yeah. And you know, maybe that's obvious. I don't know. But it it is uh when I think about that, I was curious about, you know, one, you know, what Zyngo was doing. Uh they they were being very successful, they were pre-IPO. It seemed like, you know, from a financial investment of my time perspective, it could pay off pretty well. It did. So that was ended up being a good call. Um there were just aspects of what they were trying to do uh at the company that I thought were really interesting. In fact, when I because uh you know they had multiple game studios, I didn't interview for the Mafia Wars position. I interviewed for being a game CTO at Zynga on one game, whether it was a game that they hadn't yet started, whether it game was a game that was running, uh, you know, regardless. And in fact, I had the conversation with the company CTO, who had recently been put into that position. He had formerly been the CTO of their largest, most profitable game, and he became the company CTO. Uh, he sort of said, Well, you know, what resonated with you the most, where do you think you want to go? And I said, Well, where are there the biggest challenges and the biggest problems that you know match some extent of my skill set? Uh, but again, that you know, the curiosity, but also, you know, a desire to serve. And that was Mafia Wars. Uh, and it turned out, you know, with the other four CT game CTOs at that time, I needed a mentor to ramp me up. And I happened to pick the guy who had been the former CTO of Mafia Wars. So it just worked out very well. But some of that was just happenstance. It wasn't really part of a plan.

SPEAKER_00: 40:47

Well, let me circle back to something that you said that kind of like made me think. Um, I had this sort of epiphany right now. So bear with me. I'm gonna be making it up as uh as I talk. So you mentioned that the CTO at the time at Synga had previously been the CTO of the most successful game. Which I understand it creates some sort of competition in in companies where they have like this store of CTO or CTO of stores of multi-products, they are in a constant competition among with each other because do they know that the most successful product CTO will become will can eventually become the CTO of the firm? Or that's just total bullshit and I just made it up. Like did you actually think that was possible? Or did they have in other companies?

SPEAKER_01: 41:38

The thing that was interesting to me going back to when I started on Mafia Wars, I was an individual contributor CTO, then I had a team of a dozen, then I had a team of 30, then I ran all of their technical stuff because at the time they didn't believe that CTOs could both be the technical leader and the VP of engineering, the manager of the technology team. And yet, a couple of months before I started and got hired in as that individual contributor, they promoted the CTO of their most successful game into the CTO of the company, who not all the other CTOs reported into, but he did have a technology organization. But there, he very much is the senior most technical leader and running an organization, you know, in defiance of their thing that CTOs don't do both. Like, okay, I'll keep I'll put that aside for now, but I think you guys are ignoring the obvious here. Um, it it didn't specifically create competition. Um, I think, you know, one, we did have uh over the course of about two years, we developed a, I think, a pretty well-defined uh process and set of criteria to get promoted. What were the things that you needed to do? And, you know, for most people, they were really just trying to get to from senior engineer to being a game CTO, from game CTO to being a you know, studio CTO, and then maybe a franchise CTO, then a division CTO. And I don't think there were very many people who had aspiration to get to being the CTO. Uh really weird and somewhat embarrassing story, I think. Um the CT, the CTO that we had, uh this who who was you know moved into that role just before I started, uh, about four or five years later, you know, lots of things had happened. I'd moved through being the CTO of Mafia Wars to being the CTO of the shared technology group, to being the CTO of the mobile uh development division, uh, and then from there actually became the CIO. And at some point, again, the business was struggling. Uh uh Pincus decided to bring in a new CEO. And as part of bringing that new CEO in, uh he decided out with the old, in with the new. He was going to bring in people that he knew. So the CTO was out, the CFO was out, the chief people officer, head of HR, was out, and I think the general counsel was out, but that was perhaps for other reasons. And I hadn't done anything bad yet. So I guess his view was whatever, whoever screwed all this stuff up, they all got to go. But I was totally unfair, but that was his view. Uh he was he was kind of arrogant. Um and, you know, as I was, you know, as the CTO was getting ready to exit, he prepped me. He's like, okay, the leadership team has met. Uh we're gonna be moving you into the role of CTO. Uh the CIO organization will continue to report into you. We've got these other technical leaders we're gonna put under you. And I said, wow, that's that's amazing. On the morning of the leadership team, this is the C-suite meeting where we're gonna go over this and the rollout of all of it. Uh, we have a I have a meeting with the new CEO and one of these senior technical leaders. And he just tells me flat out, um, or tells us flat out, okay, you're gonna be the CTO, you're just gonna stay as the CEO doing a great job like you're already doing. Like, oh, that's completely different than what I had just been told. But that's the old guard, you're the new guard. I can't really argue. But what was just the embarrassing part was walking into the you know, the C-suite boardroom with the giant projector with the PowerPoint slide, with the org chart on it, with my name in the CTO box and this other guy's name reporting to me. I'm like, you couldn't even update the slide. That would just it, yeah. I remember talking to the the exiting CTO that evening, and he was like, I had no idea that was gonna happen. I would have given you a heads up. I really apologize. We we worked very well together. I have a tremendous amount of respect for him. So I have no reason to believe that he wasn't being completely genuine. But I, you know, definitely that definitely created problems for me and the uh the new CEO.

SPEAKER_00: 45:57

Oh, politics. Um look, one of the traits of really smart people is that whenever they explain really complex problems, they uh they go on talking about like very large situations and they make them sound very obvious, the solution of which they they they make them sound very obvious. And you do have that trait. So in hindsight, everything looks so easy because when you've been talking about like a reorg, scaling up, scaling down, moving off the cloud, going back in, stuff like that. The way you explain is like really fucking obvious. But people in their homes, they will be like their brains will be exploding right now. So I'm pretty sure that at the time you faced difficulties and you didn't see it that obvious. And right now you have the the benefit of time, right? Um so what what did you find more difficult to scale? Like technology, people, or the decision-making processes. Uh what did you struggle the most?

SPEAKER_01: 47:04

Seems like technology maybe not, but for me personally, I think it's the people part. Uh and I had to learn that. You know, and again, going back to that, do I take the team of five or I take the team of 30? I was like, hey, if it's only five people, I can probably deal with that. That's a lot easier. But I went to like, let what's my uncomfortable zone? That's more people dealing with more people. So I had to learn those skills. And I can't say that I have innate technical talent, but I'm I'm much more comfortable in technology. I think the curiosity says if I don't know it, I can learn it. And just try things and and you know, I used to you know spend hours after you know the end of the workday, you know, either reading O'Reilly books uh or you know, trying things out on a dev instance or whatever it would be. So I could like, I just learned this thing. Let me see if I can make it happen. Uh I I learned by doing. So again, some of it's just recognizing your strengths, but not just playing to your strengths. And so for me, the harder part I think was people. Um I think whether it's you know people or product or the technology, uh one thing that, at least for me, seems to be incredibly important and kind of maybe a cheat code. And to me, there's sort of three pieces. There are patterns, anti-patterns, and what I'll call revisit patterns. And so patterns are things that you've done before that you've recognized, and you just you can do them again. So, hey, I had a three-tiered architecture that had this back-end data store. I understand the pattern of a three-tier architecture, where the scaling is, what the networking needs to look like. I'm gonna swap out the storage backend, but the pattern of the three-tier architecture remains the same. Uh, I'm gonna go from you know, uh client server to a three-tier architecture. Well, client server is just a two-tier, the pattern of client server, here's that. I'm gonna go to distributed computing. Like, okay, well, I've got a three-tier architecture that now has another dimension where I have to be able to distribute things, but I can recognize these things. Um, anti-patterns, like, well, when you do these sorts of things, you're creating a single point of failure, you're creating a scaling bottleneck. What are the things that you can recognize that when done, things blow up? Kind of going back to that checklist concept again. It's like, what are the anti-patterns? To me, one of the most interesting things is to revisit patterns, which is things that didn't work in the past under the technology constraints that existed. Don't discard them now. It might actually make sense that the you know the I.O. throughput of an Oracle database from five years ago may not work for this workload back five years ago. But now you've got much faster storage subsystems, and the abstraction layer of the database technology is not the bottleneck. It turns out the bottleneck was always the storage subsystem at the hardware level. And so revisiting patterns that you might otherwise discard because, oh, everybody knows that's not going to work. Um, so that that to me is really funny. I have one story on that. Um, I started the the first Oracle database I worked on was version 5.14. And the going back, I think it's 1987.

SPEAKER_00: 50:20

Um The year I was born, by the way. So I was just time things.

SPEAKER_01: 50:41

Before I made this change to the data, this is what the data looked like. The after image file said, after I made the change to the data, this is what it looked like. And then there was this concept of a checkpoint where when the system issues a checkpoint, it merges the after image on top of the before image, and now that becomes the new before image, and the next change will become the after image next checkpoint. And you can stack these things up. So if the system crashes, well, you've got a before image, a starting point, and then you've got several after image changes. You didn't reach a checkpoint, so they weren't committed. So you roll all of those back and you come to here. Kind of like versioning software. This and so that's how they did that. But in order to manage the storage component of that, it was essentially the snake eating its tail. So you would allocate files that would go around and around and around, and at some point it would say, okay, I hope you've uh saved all of the changes from this file because I'm gonna start writing over it again, you know, the before image. Because if you didn't save it, you're screwed because you no longer have a starting point for your database. So, but you want to make sure you've got enough storage and enough of these things that as you go round robin, you're never gonna come close to that. And as a DVA, you freak out when things you set up alerts and alarms and figure all those things out. Fast forward 13, 14 years, we had uh a large uh uh database, uh happened to be Oracle, but that that's not pertinent to the story, that was managing uh email pointers to email bodies on disk that were related to uh uh spam. This was Postini, which was anti-spam antivirus. And so we just had this whole this large database of pointers that said, okay, this the the email message's body is stored over here on this hard drive. Uh that was fine. But as we purged data, we would delete these individual records, these individual pointers from the Oracle database. Well, at scale, as things really started to grow, we couldn't the deletes couldn't go fast enough. And we needed a new architecture. And I went, well, why don't I revisit a pattern that I've seen before? And I know that the Oracle truncate operation is a single once and done. It just releases a bunch of allocated blocks and whatever data is there, you can't get to it again. So instead of deleting individual records that have to have a full commit cycle so you can roll each one back, truncate, I'm just gonna throw those out. So we created, we saved 15 days worth of data uh in our spam archive. I created 30 individual uh tables as each of the buckets, and then as data was coming in, the pointers would be written to whatever was the current bucket for that day, which meant I had 15 days where I had pointers stored that I didn't need because they were already obsolete based on our product promise of only preserving 15 days, but it gave me 15 days in case something screwed up. And every night I would just truncate the table that was 30 days old. Single operation, boom. I don't care how many records are in that table. I don't have to worry about rolling anything back. You can't roll back a truncate. It's a data definition language command as opposed to data manipulation, and that just admitted all of those performance problems went away. And so that the pattern recognition becomes really important, at least from my perspective. And so everything I learned about you know horizontally scaling Linux boxes was like, oh, I I I get distributed compute in the cloud, they're just virtual. There's no difference. Uh everything I learned about and the mistakes I made with you know uh configuration as code, like that applies to everything you do. And you know, abstraction layers, how can you pull things out? When have you put too many abstraction layers in? Those patterns become really, really important. And I imagine there are cases where successful patterns actually become anti-patterns. So the one that I can think of is uh we used to feel really, really great when we were running our system on the largest hardware available at the time. Aren't we amazing? This was before a lot of distributed computing. Well, it turns out in retrospect, if you're running on the absolute largest hardware available at the time, you're screwed because you can't get any bigger. So what seemed like running everything on some beast of a machine was the best thing you could do, and that was the pattern, clearly became an anti-pattern.

SPEAKER_00: 55:22

Well, actually, I mean, and probably you've got also like the the time vector, who it's like after so many, many years, there's technology adoption cycles, bubbles, and stuff like that, passing facts. And you're probably you probably didn't believe in NFTs, but I don't know about that, or like blockchain, because it's like I actually been working from technology for long enough to know that this is just a passing fact. But um let me just uh for the last 10 minutes, uh, I've got a couple of questions. Like at a level of a CTO that most people that they will even be the guest on this show, they probably have never experienced, right? Uh, one of them is one thing you mentioned very briefly, but um just in passing, but I think it's really important. It's like you become the CTO uh quite unexpectedly at a big company and you have to face the board. Right? Um you didn't have time to prepare for that. I guess that when you well, I mean, I know when you're going up the technical ladder, you know what the expectations for the next level are. And like, oh, I need to learn about this, I need to manage a larger team, I need to be able to manage multi-product, or I need to like kind of like solve this super complex technical issue or help the company to save money on whatever we're spending so that you know I can I can check all the uh uh tick all the all the boxes and be able to make it to the next level. But how do you prepare to be the CTO when you don't know that you can become the CTO? And what are the things that you wish you had known of board dynamics, right? Um, that you didn't have for a first time board joiner, so to speak.

SPEAKER_01: 57:08

This this may be specific to my personality. Uh you might call it a personality trait, you might call it a personality flaw, depending on your perspective. But uh I'm I I'm not really big on lying or making shit up. Uh so going back to that aspect of data, and if you have the data, you wouldn't be a good CEO then. Um but you know, telling the truth. And you know, I I've found that often the best way to earn people's respect, even if they hate what you're saying, is tell them the hard truths back with data. So for me, you know, I I love numbers, I you know, they just float around in my head all the time. Uh, I love you know connections in data. That becomes really important to me. But I also realize that for board members uh and you know the C-suite, they're for each of their areas, they're thinking about what are the numbers that worry them the most? What are the hard truths that worry them the most from a technology perspective, from a technology organization perspective, from how your organization delivers value to these other leaders? Like, what is it that worries them the most? And what's the hard truth you can tell them, hopefully backed by data, where you can be their ally. You can help them, make yourself useful. And it sort of goes back to, you know, when I started at Zynga, it's like, well, where can I be of the most value? Uh again, that's not necessarily for everybody. That's my personality. I want to try to figure out that. And I've found that when I do that, I get elevated faster. Uh, because people are like, oh, this guy tells us how it is, tells us things we don't want to hear sometimes. He's usually right because he's got the data on his side. When he's not right, he admits it and goes forward again. Like, if I want somebody I can just trust and know is doing that everything they think they can, I can just use this person. If I need somebody who can lie through their teeth and nobody knows it, he's absolutely the worst. I don't want him. So it kind of depends on what you're trying to do. And again, in startups, that you know, I've worked with people who were CTOs who were just flat out liars. And, you know, often in technical due diligence, you know, when we're looking at potential acquisitions, if you know, I'm asking somebody, oh, so you've got this architecture, you're doing these things, that's like, how fast is it? You know, if the CTO says, oh, it's really fast, like you're full of shit. Um, if I say, okay, so what is really fast? How do you measure that? Oh, well, you know, this transaction can take, you know, a second or two. Like, which is it? That's materially different at hundreds or thousands of transactions per second, one second or two seconds. It's like, you know, when we were doing things at Postini, we knew each little plugin in our process. We had seven different plugins, how many milliseconds those things took. Per number of bytes being processed. And I had all that data on top of my head. So when people were doing diligence on us, I was like, oh, well, this plugin, we haven't been able to get down under seven milliseconds. It actually jumps to about 13 milliseconds when we throw in this size of a file. But the vast majority of files, vast majority being about 80% or more, are all under that size. So we can predict how fast that chunk is going to go. Like that starts, okay, that's credible. He's got the data, but he's admitted, oh, it doesn't always work that way. And he's admitted seven milliseconds isn't good enough, but that's the best we got right now. Like those to me are super important. That made me feel as a person, I'm on top of things. I think it earns respect with other people. And so the closer you can get to the thing that makes you you, for me, as I said, it's it's it's data and being truthful, but you know, what is it for you? It may not be that. It might be I've examined these 17 new technologies, I've played with all of them, and this is what I'm seeing. And you might just be the you know a technology noodler, and that's incredibly valuable too.

SPEAKER_00: 1:01:03

And how about the moment like the other thing that I think is pretty unique to your role and to your career is that after you know having a C-level job, uh you move on to Amazon, then you become VP, right? So you're no longer a C-level. Um I don't know if like probably because you you made it with Zynga, right? Uh, but but I I don't know what other things did you have to leave on the table or you had to let go, right? Uh oh now I I was used to doing this, I was used to this dynamics, I was used to having this sort of information available to me or this budget or whatever. Now I'm just the VP, just a VP on Amazon, excuse me, it's just like crying in a fucking porch, right? But but um but you're not the you're not the CTO anymore. So how did you how did you manage the situation emotionally? Like I know it was like it was probably like a good match because you stayed there for years, but yeah, you're not the CTO anymore.

SPEAKER_01: 1:02:05

Yeah. I I and interestingly, if I liken you know Amazon and their product organizations that roll up into larger divisions, it's actually similar in structure to Zynga, where Zynga throws CTO titles all over the place. Amazon doesn't throw titles all over the place, but you know, when I started, there were 40 technical VPs across all of Amazon. Corporate Amazon when I started was about 120,000 people. All of Amazon was probably 1.2 million, but you know, it's warehouse workers and distribution center workers and that. So if you're looking at the corporate part, it was about 120,000 people. I was one of 40 of the senior most technical people. So 120,000 people, 12,000 people. Now I'm one of four uh one, you know, if you get down to an organization of 4,000 people, I'm one, I'm the technology leader for an influence of about 4,000 people. Just rough numbers. Zynga never got to 4,000 people. So I may have been the CIO, but I was actually more valuable with more potential impact and scope at Amazon, not to mention the fact that Amazon can and does things and did things that Zynga never was going to. So it it was actually a much bigger role. And then very specifically, and this is this is also kind of weird, but maybe it it's it's fair to disclose. Um when I was at the uh at Zynga, I was the CTO of the mobile division. A lot of it because I understood technology, I understood these patterns, uh I had never written a line of mobile code. I've still never written a line of mobile code. I understand architecture, I understand bottlenecks, I understand networking, I understand backing stores, I understand local caches, I understand all of these other patterns. And you're just squeezing it into a different network architecture and client server architecture. Uh so you know, going back 30 years earlier, yeah, everything I did in client server, it's kind of that's mobile. Now, I didn't need to be a smart, yeah, I didn't need to be better at Swift or you know, uh C sharp or any of these things that were being used in the client. That didn't matter. Uh at Amazon, I was the VP of the mobile division. And again, I didn't need to be the senior most mobile coding expert. I needed to understand what were the overall problems. And the biggest problem was how do we ship an updated app binary every two weeks with 50 to 100 other contributing Amazon teams who don't work for me. Because I'm responsible for the core mobile technology and shipping the app binary and creating tools and techniques and practices so all of these non-mobile developers around Amazon can actually create compelling mobile experiences that respect the network, that respect the device, that respect frame rates, that do all these things that you have to understand matter in mobile. But I didn't need to know how to write the code to do that. And so for me, Amazon when I started was not a mobile first company. Two years prior, you know, Jeff had stood up in front of a company meeting and said, we're mobile first. And that just meant I think mobile really matters, and I'm gonna say these words, but none of their actions followed suit. And you know, I knew that mobile was the future. People are like, well, but people don't shop on mobile. They they they do their research and then they switch to their desktop. Like, that's some subset of the US market, but that is not the globe, that's not the world. Like most people in the rest of the world don't have a desktop computer and a mobile device. Like you guys are not paying attention. So again, using data, showing trends. I had a really brilliant, uh technically savvy but marketing uh product lead who understood all of that data, all those things. So I was armed with all the data that I needed. And I had a chance, in my view, when I took the job, was I wanted to change Amazon. Which if you can change Amazon, that feels like a pretty major accomplishment. And in two years I did uh in that role. I started out, everybody was talking about pages and clicks, and I would just I would redline documents. It's like in mobile, there are no pages. In mobile, there are no clicks. It's screens and tabs, it's scrolling. You have to think like the customer. Stop thinking like a web designer and your web pages and it's like you can't just load a web page with hundreds or thousands of products listed. The network will choke. So you have to, we had to think differently. And I felt it was really important to use different words. I get a little obsessed about words, but I thought that was really important. And I remember when I was leaving that role, one of the VPs who'd been one of the most ardent uh resistors to this change said we've got it figured out. We know what we're doing. I remember we were in a document review session. He comes up to me before the meeting, he's like, Dorian, I'm really sorry. I didn't get a chance to proofread the final version of the doc. There's one mention of web page and one mention of click. We're gonna fix it before we send it out to everybody. And it was like, I did it. And it seems so dumb that that was my victory. But the victory was I actually made my position obsolete. That by doing the things that we did, the team did amazing work. We were able to stabilize the environment, create the practices, the procedures, uh, the mechanisms such that that team of 200 technologists did not need a VP anymore.

SPEAKER_00: 1:07:38

So then I had to go find another job. What a great way to wrap up, like going full circle to what you said at the beginning. Um, you know, um, you know, the signature question of the podcast is just like the most expensive fuck up. You already answered that. So I had to come up with something else for this time around. And um usually podcasts are really terrible at like asking these kind of questions, and people or fireside chats, they go into like, what is the advice you would give to other people? That's a fucking lazy question, right? But I think I get a twist to that one because you are one of the humblest persons I know. You're always feet on the ground. And um CTOs tend to get a little bit like uh high-nosed when they when they go up the management ladder, they tend to build an ego, they tend to be like, ah, they have these these aspirations or or like they they tend to look at people over the shoulder. And I wanted to ask you specifically, what kept you so grounded, so humble when you scaled up the management ladder? Um, and how could that help other people?

SPEAKER_01: 1:08:43

Uh that's that's an interesting question. A lot of self-re-reflection required. I do want to say one thing, though. I think I've met more humble CTOs than arrogant CTOs. So I did your characterization may be from a different set of experiences. Uh you know, the CTO at Zynga, uh, very humble, very capable, had the right to be arrogant, but wasn't. And other CTOs, the CTO at one of the CTOs at Zig at Excite, I was talking about, described himself as a Leaddite. How can you be the CTO and somebody who doesn't believe in technology? He was exaggerating, but he always wanted to look for the simplest solution. What is the least technologically sophisticated solution I can come up with? That's what we should do. And so that I thought was humble. It's not not what grandiose thing can I imagine. Uh and then, you know, in in terms of your question, no, I forgot what it was. Um uh well I forgot it. How do you keep your your feet on the ground? Oh, feet on the ground. Um I don't know. Maybe this is maybe this is a weak answer, but kind of going back to you know, being honest and truthful. Uh if I don't believe it, I'm not gonna tell somebody else something. Uh if I question it, I'll let them know I'm questioning it. If I'm wrong, I am pretty quick to admit I'm wrong, but you better have good data to prove it. Uh, is I I'm not I'm not an easy pushover. And so, you know, with that, I I hope I earn respect. And with that, I build trust and confidence in me. And if I'm speaking on behalf of my team and I can create examples of what my team is doing, I can get people to trust and respect my team as well. It's so much more important for me for other people to trust and respect my team, because their teams are gonna be working with my teams. And if there's mutual respect, a lot more stuff is gonna get done, and I'm not gonna get called in to referee. These people trust and respect each other. When they disagree, they'll be truthful and honest and tell each other the hard truths and hopefully they'll work it out. If they have to escalate, fine. If I have to be in every meeting because they can't get along, I'm doing a terrible job. And so for me, that idea of you know trust, truth, respect becomes a really easy way. If because if I don't trust or respect you, then I don't really want to work with you. Uh I might have to, but uh, you know, there are definitely multiple times in my career where I got to that place and I left. Like I don't I don't want to work with people like this. And it sort of comes down to this core idea: if you're willing to violate your own principles, they never were your principles.

SPEAKER_00: 1:11:25

That's good parting thought. Um, after Amazon, you retired. I don't know if that's the word. Um, but now your your LinkedIn profile reads advisor and mentor. Funnily enough, now you've got a more serious profile picture than when you had back in the day when you were employed. And now you've got a really professional uh headshot. Um so how can people reach out to you for this kind of mentorship or advice? And what are the kind of people that you can help? Is this something specific that you're looking for in mentees?

SPEAKER_01: 1:11:59

I think you know, messaging through LinkedIn is probably the easiest. It's probably not a good idea for me to give people my email address, although it's not that hard to guess. But I'll just I'll leave that out there. Uh but yeah, reach reaching out. I I am very interested. Maybe I'm a different form of technologist. I've I've spent a lot of time uh cooking and gardening. So uh completely different skills and different things, but I'm still looking for the patterns and the anti patterns and revisiting patterns in cooking and gardening.

SPEAKER_00: 1:12:26

Good, Dorian. Thank you very much. It's been a pleasure as always.

SPEAKER_01: 1:12:30

That's been wonderful.