Editor's Note: This transcript was automatically transcribed, so mistakes are inevitable. You can contribute by proofreading the transcript or highlighting the mistakes. Sign up to be amongst the first contributors.
More than likely, you've uttered the phrase, yeah, I'll just Dropbox's that to you, that turn of phrase has become so popular. Thanks to the capabilities Dropbox's has offered to the masses, people around the world can share and store documents, pictures and information simply by dragging a file into a folder. But how does that file get stored and how do those precious items live in a space that seems almost endless? Andrew Fong is the vice president of infrastructure at Dropbox.
And on this episode of I.T. Visionaries, he dives into the nitty gritty of how he helps keep those mementos accessible everywhere. Plus, he describes how a small task force formed in 2013 shaped the future of Dropbox forever. Enjoy this episode.
It visionaries is created by the team at Mission Dog and brought to you by the Salesforce Customer 360 platform, the number one cloud platform for digital transformation of every experience, build connected experience, empower every employee, and deliver continuous innovation with the customer at the center of everything you do. Learn more at Salesforce.com platform. This podcast is created by the team at Mission Dog. Welcome to another episode of it, visionaries, I mean, Faizan, host of Visionaries, and today we are joined by special guest.
Andrew, what's going on? Nice to meet you.
Super excited to be on this episode.
Awesome. It's great to have you. So we're going to be talking about what you're doing at Dropbox. We're going to get real into the weeds of some of the cool stuff that you all have done, particularly some of the things in your background that are fascinating. Let's get into it. How did you get started in technology in the first place?
I have always been interested in technology. I love Legos. I'm sure a lot of a lot of the people that come on the board probably say something to that effect as well.
I remember very distinctly my first foray into deep technical. I got a actually the first foray was probably Lowgar writer on Macs Max in middle school making a little turtle run around the screen. That was a lot of fun. And then I remember the first, like, super deep technical experience I had was I was on like an early version of the Internet perusing. And I find this thing called Linux. Of course, I have a Mac, though, at the time.
And so I download the Mac version of Linux called Linux, and it's a complete disaster to try to use. It's like a 13 year old kid trying to figure this out. So that's sort of my first foray into technology. And I sort of stuck with the Linux thing and kept doing that and turned it into the first couple of jobs and then eventually at AOL and YouTube and now Dropbox.
Yes. So flash forward to today. What does it mean to be the infrastructure guy, the vice president of infrastructure?
Let's say so at Dropbox, this means that primary responsibilities are everything from our supply chain capacity planning network, data centers, deployment systems, internal cluster management and the storage layers that run on top of that. That's the technology remet. With that comes a lot of the responsibility of reliability, durability, as well as a lot of the budgeting, one of the budgeting aspects from from the organization.
That's what I meant. What do I do on a daily basis?
I think of it as a big portion of my job. Actually, primary portion is going to be really focused around talent and culture and value. So I try to spend a lot of my time, probably a disproportionate amount of my time there, as well as on the direction setting aspect of technology within the organization.
Yeah. So do you work both on internal technology like internal employee technology and externally on the product, or how does that work?
So we have two different organizations that do infrastructure, things that Dropbox one is our internal team who provides. Think of them as the systems that run the corporate infrastructure at Dropbox, so your laptops, the financial processing systems, the sales forces, those integrations that go back to the internal users of the Dropbox Dropbox employees, my agreement is on the production side. So everything is effectively what we run an infrastructure is the Dropbox cloud. So when a piece of data is stored from your computer into the Dropbox system, it ends up in a system of records that the infrastructure team is ultimately responsible for.
So that's that's the division of labor when it comes down to the infrastructural components instead of Dropbox. Awesome.
And so what does what does your team work on from day to day basis, day to day?
These days, we're spending a lot of time on covid related activities. I am super blessed to have a supply chain team that was on top of a lot of what's happening in the world in terms of covid in late January, early February. I remember our head of supply chain came to be the Aslak at 10 o'clock at night. This is I don't mean 20 20 is going to be a normal, normal year. The direct quote from him, and I don't know if I could have come up with a better quote for those that have been following all the news that 20, 20 has not been a normal year.
And what he was saying was, look, we do a lot of we actually use what are called Odem computers. So we buy them and sorts them out of Asia. They're effectively specked for Dropbox. And so we manage the supply chain from everything from the motherboard assembly to the assembly to drive assembly. We manage that supply chain and the commodities behind that. At this point, everyone's familiar with covid. The China at that point was coming off a lunar new year.
Employees weren't coming back to the factories at the rate that they normally come back at cities. We're getting locked down. And what we're seeing is we're seeing a backlog of of capacity that was not shipping out. And the reason being is it wasn't just simply wasn't any manufacturing and moved to Taiwan and then eventually moved to the United States. That started in February for us and has led to a that's been the day to day for us for a while now, has been around just simply managing that and all of the other things that have come along with it.
You first you looked at Asia and you had to solve that problem. And so there was a team working effectively 24 hours a day trying to figure out, OK, how do we fix everything down the sheet metal to make sure that we're going to get deliveries and capacity will come to our data centers. And then as it goes out, as the virus spreads around the world, the Bay Area starts to lock down. So some of our last mile integrations happen in the Bay Area.
What's the impact on that? So we had to work with our suppliers here to make sure that we still had people that were able to go to factories in Fremont to assemble machines. Then we have to figure out how do we get them shipped? Is are there going to be rules around where things are moving around the country and everything down to we have manufacturing in Mexico as well. How does that play out as well as they were talking about maybe the water restrictions there in terms of in terms of international travel?
So all of these things.
So there's been a big focus on covid. That's been a big focus for twenty twenty for us, but it can't be the only focus. And we also spend a lot of time on our three or three year horizon of how do we think about storage technology evolving? How do we think about a lot of the different efficiencies that we want to put in the system. So, for example, we have a very large fleet of MySQL servers in the thousands and they all have SSD in them.
So faulty devices, disproportionately more expensive than spinning media. How do you keep the cost profiles of those down as your product is growing? And so that leads us to thinking about new technologies and new abstractions that allow us to scale the database technology slightly decoupled away from the rest of the stack. And so we've been investing sort of on the multi year horizon on technology like that. So those are sort of two examples of what sort of my day to day looks like right now, sort of managing everything from a three to five year portfolio down to how do we make sure that the capacity that's going to need to come into the data center shows up at the data center in the next month or so?
You know, we talk a lot about reliability, durability, performance on this show. I'm curious, like, what steps did you take initially to make sure that everything was reliable, durable and and performing correctly for Dropbox?
So my background actually is in site reliability. I was a site reliability engineer at well as a site reliability engineer on YouTube for a long time. My background is around reliability, and when I joined Dropbox, that was I think it was the third set reliability engineer that joined. And so I spent a lot of time and I've been spending a lot of time in that space for my entire career. Dropbox. So what do we do to actually make sure all of this is reliable and durable and performance?
I think of reliability as a core feature that we have to have. And when we go into any type of planning, reliability has to be a core as durability as well, a core aspect of what we're paying attention to, whether it's in metrics reviews, whether it's in a system design or engineering review, it has to be the number one thing that we are worrying about as an organization, because from my perspective and I've seen this, if you slip one month in reliability and you shoot for your three nines or four, nine or five, that's how many won.
The minute you regress a little bit by the time it takes to recover from that, regression can be measured probably three to five times more time to recover to get back to where you were then, sort of the initial eye off the ball. So you slip a week. You're probably looking at five to six week recovery. You slip a month, probably looking at six months to get back to where you were from an operational posture. So we think about it is something that must be ingrained in us every day.
It's our number one company. Value is worthy of trust in infrastructure, are one of our values is reliable, that you are efficient and inclusive. But reliability is something that's just core to how we actually operate as a business. I think a lot of reliability is around processes, but there's also technical like when we do our design reviews, they mentioned this before. It's a core of what we're looking at. We're literally poking holes and trying to figure out exactly how the system will fail.
And I know you want to talk about that later. But one of our systems, Magic Pocket, which was our storage system that we built, one of the things we did is we applied a process called FEMA, where we looked at failure mode, analysis of the entire system and spent hours, if not days, weeks testing a core set of failures and documenting them and then validating that documentation against watching it a second time. So these are these are sort of the types of approaches we've used to validate systems from failing and just making sure that we actually have the type of rigour we need to make sure that we can try the reliability and durability and guarantees that you have to when you when you're dealing with systems of record.
Well, yeah. Let's get into the magic bucket stuff now. So tell us a little bit about Magic Pocket and what was going on at the time.
So for those who don't know, Magic Pocket is Dropbox is internal coding for internal storage system.
Six, seven years ago we started maybe actually well before that we had started thinking about building our own storage system because we were primarily posted on three as a storage system. So these are if you think of files, we saw metadata, which is the name of the file, the access time of the files, the who owns the files, all of that is in one database. And then we have blocks and blocks are just the blob data that's inside of a file.
And we we're storing the blob data inside of a three. And we started to think like, OK, with a business like do we want do we want all that data there? Are there positives for us to maintain this? Can we build a general purpose storage system with a different cost profile? Can we build a general purpose storage system that gives us the ability and flexibility to do other things with the data that we wouldn't necessarily be able to do on S3?
And we believe the answer was yes. At the time we had probably six hundred petabytes of data inside of us. Three, six hundred, seven hundred petabytes of data necessary. So we had to transfer that data out of S3, move that all into Dropbox data centers and do that on a pretty tight timeline as well as build the storage system which didn't exist. That's the magic pocket project in a nutshell, something we tackled probably roughly six, six 1/2 years ago.
Now, at this point, you know, one of the things we hear a lot about cloud transformation going the other way. So it's a little it's a little unique to have it pull back off of us.
I think that the primary thing to understand about Dropbox and S3, the storage system, is that they solve fundamentally different problems. Magic Pocket is a box storage system that's effectively impotent, right? Once S3 is not an item put in storage system from its interface and allows you to change, update, move and do a lot of different, a lot of different actions to the blocks that are stored there. Now, when you think about that and you combine that with the access patterns, because when you look at Dropbox is access patterns, you primarily have data that is warm but not hot, meaning that we know that when you put a file in your Dropbox, you'll use it on some time horizon.
And we have multiple versions of that. As well, and so we know those versions are never going to be accessed unless you roll back to it with those characteristics, we can actually build a storage system that's more efficient, that is three for our use case and would be very specific about this for our use case. You could not put the S3 API on top of Dropbox and expect it to work and behave the way S3 behaves. We use that three and other for other types of storage because Mattrick Pocket is actually built for the bulk of the data.
We have the six hundred now multiple exabytes of data because we knew that the economies of scale that we're going to have, this is actually probably something on a financial side would be advantageous as well as from a technology perspective. Keeping that data close to us into our compute and our databases would allow us to do other things with it because we weren't going to have to pay network transfer fees. We weren't going to have to deal with the way that Amazon was dealing with consistency.
It gives us some different different levers to pull.
And we thought that was a very unique opportunity for us from a technology perspective to actually create a little bit more leverage for the product as you're talking to other infrastructure leaders.
Is this something that like as you're telling them this story, is this something that they're, like, jealous that you were able to have the resources to do it? Or are they are they are they like why'd you why'd you do that in the first place? Like, what's the feedback you normally get?
It's varied. I can tell you that managing a system like this is you need to go into this with your eyes wide open.
I've definitely had conversations with other infrastructure leaders and other tech companies that have talked about doing things like this.
Now, if you want to build a system like this, especially at the scale that this operates at, because if you don't have the scale, the economies that the unit economics don't kick in. And so what do I mean by unit economics? The cost per gigabyte, you don't actually get that value from the vendors you're going to work with until you start buying in volume. So you need to have a volume that actually makes sense before you even go down this journey.
But then when you do that, you also have to be aware that you have to manage a network engineering team. You have to deal with supply chain. We talked about it earlier. So you have to deal with those type of events where if you're on a street or you're in a public cloud and you have a medium sized workload or a small workload, potentially even some of the larger ones, you don't have to deal with that. And those competencies aren't competencies you actually have to have through your organization.
And I'm super lucky to have an amazing team that's able to handle a lot of these a lot of these issues that come up. But if you don't have a supply chain team that's capable of going down and sourcing sourcing sheet metal in the middle of a global pandemic, you may not want to think about, this is a route you want to go. It just adds a level of complexity to your business that may not be advantageous. And for us, storage is key to our business.
So the value prop actually makes a lot of sense. But if you're not a storage company or a company that does a lot of storage and it's core to the business, this might not be a thing you want to invest your resources on. We definitely don't invest resources in other aspects of our infrastructure where we believe there's better things that we can just buy off the shelf.
Yeah, that's a great point. I think that you nailed it, that if it's core to your business, it's something that you really have to take a look at. And if it's not, then. It's a different conversation, so what are some of the things that you just mentioned, what are the types of things that you don't want to build, that you're just going to look at buying off shelf?
Melani is one. We utilize a lot of the public cloud providers Melani capabilities. That's a area which requires a tremendous capital investment as well as operational investment to handle right now, if you look at sort of the public cloud providers, if you have I mean, if you look at Google, there probably thousands of engineers working. When I say I'm an Amazon, that's an investment that we'll never be able to make at the same level of those companies. And the research aspect of that really drives a lot of what's happening in that space.
So we try to use the public cloud for for that type of technology. Additionally, our analytics and data processing is very similar. It's a capability the business needs, but it's not a core capability that differentiates Dropbox. So one of the other teams, I believe, is our data insights platform teams, and that's primarily built on the Amazon. Most of that technology is utilizing just sort of their normal, the normal processing capabilities they have built in a very familiar architecture.
For those that utilize utilize public cloud for analytics. We utilize a little bit of snowflake. All of these things. Those are those are not core capabilities to the business, but there are things that we need to run the business.
So we tend to look at those as can we buy that and other things on unmagical pocket that that were particularly insightful or things that you didn't see coming.
I can talk a little bit about how we did production validation for Magic Pocket. Sure. I think that one of the biggest challenges with launching a system like Magic Pocket is that we were moving six hundred petabytes, seven hundred terabytes of data, and this is manufacturing growth versus organic growth. This data existed in a place in the world already, Amazon, and we were moving it. So there was and if you're storing the data in both places at the same time, you're paying double for that.
So you want to converge these onto a single system as fast as possible so you can deliver your financial models that are X that are right. You do that, and that gives you a time horizon in which financially you must be able to do this.
And at the same time, manufacture growth means you don't get to live and breathe the system and understand the system in the way that you would normally get to. If you started from zero and your company grows, your dataset size grows and you iterate on that and you learn about it. So the learnings that we had to have happen had to happen in a super short cycle.
And so we put in pretty stringent production validations at a level that I wouldn't say you would use unless you were going to do something at scale immediately.
And so we touched on the FEMA process. That was one where we put people in rooms and we asked them to do tabletop exercises to think of every failure mode they could have. And we had program managers write down every single idea people came up with and we grouped in bucketed and filtered those down into what were the the major risk areas for durability, what were the major risk areas for availability. We did this across supply chain, across the network, across hardware engineering, across this software stack.
The one aspect that we also had kept a second team in reserve called a red team or blue team that would actually go to code audits of the team that had written the initial code base to make sure that we could find things like race conditions, to make sure that we could find things that were just like logic errors that no one had seen, because there in the code base, living and breathing this code base all day long, we took that angle on it as well.
And then we also put some launch timers up in terms of how long had this did the system have to run before it without losing data or how long this is about to run before it had an outage, before we deem it ready to go.
And we also built some very sophisticated staging environments that allowed us to mirror some traffic and allowed us to look to do a various set of tests there as well with live traffic. And additionally, we had to put a lot of operational rigor in that you typically don't see. On day one of the launch, we ran through a very detailed rollout playbooks, which we still use today in terms of how the system had to behave for an architectural perspective, is located at three different regions, how those regions were going to be updated.
It was not as something we thought about as we went. It was these were things that we said, OK, from first principles, how would we design this in such a way that we are not going to lose data or cause an outage from day one? And we don't have the opportunity to learn because this is 600 to 700 petabytes of live user data that has been in production for many, many years, that we need to do without the users ever realizing that there was a change.
So there's a tremendous amount of production validation that went into this, probably roughly four to six months of just validation. I think the timers were something like one hundred or ninety to one hundred and eighty days of running. The system was sort of the runway we got before we actually flipped a bit and said, this is life. Final piece on the magic bucket stuff. So. What would be like in your after action report here would be the the one thing that you would do differently if you could do it all over again.
What ended up happening culturally is that we had created a team that was incredibly talented, incredibly deep, and had a team of just the best engineers we could possibly put together. And they were just a machine that was just running. The challenge with that is that post launch.
How do you keep that machinery running? Because you have this massive system going where the team has to change and turn over, because these people have been working on it for many years now, two plus years for crazy amounts of hours. And so you have to reload and rebuild the team.
That was the one aspect that I don't that we thought about, but we're not intentional enough about. And you don't see the issues come out on day one because the system is up and running and everyone's paying attention to it. But one hundred and eighty days post launch or three hundred sixty five days post launch or 18 months post launch, you start to see the team members start to drift into new areas and new things that they're finding exciting outside of the magic rocket systems.
And so then you have to reload the team. And I don't believe and I would if I could do this again with the with the leadership, then we would have reloaded that team in a different way and been a lot more intentional about finding the next thing so that we could get people excited immediately post launch with a different set of people working on the next piece of it, because we sort of had a lull after the launch where we didn't actually where it was.
It became harder to manage the system because we were losing knowledge as the system, as a system matured and people rolled off on the new projects. That's probably the one biggest thing I would have changed.
Yeah, that's a great insight. I think that speaks volumes to like any huge project. Right.
Is like the people who who worked on it for a long, long time that after that a lot of them want to go work on something new and B, as soon as they walk out the door, all of that institutional knowledge and all the little things that they that they did and built and and all the patches and everything that went into it all need to don't you don't want them to leave.
And especially in a place like Silicon Valley where where people obviously jump from company to company a lot, you need to figure out a way to keep them engaged and hopefully like with you, with you as much as you can.
Yeah, I think the thing that I would say is the analogy I use of the teams now is sure, a lot of people have heard this analogy, but the settlers, town planners, police sort of analogy in terms of how you manage software, we had people that were much more the go figure it out sooner. The settlers. Let's go. Let's go look at this landscape. Let's understand it. Let's build something. Let's get it out the door.
A little bit of the town planners. But we never moved to the next phase, which was like, let's make sure we operate it and operate it well for an extended period of time. And so we didn't get that operator mindset into the team early enough because we really had these people that just wanted to go to the next great thing, as opposed to people that found deep job satisfaction and making sure the thing was running.
That's great insight. I love that. And that's a good analogy. I don't hear that a lot, but it's similar to like in sales. You know, you have you have sellers, you have customer success. You have, you know, the whatever Spears' nets and whatever same sort of thing. So taking a step back and just looking at Dropbox holistically, you know, you've been there for a long time now and I'm sure a million things have changed in in the eight plus years that you've been there.
But is there anything and now, you know, Dropbox, you have hundreds of millions of users, you know, more or less a household name in the technology circles. Obviously, as so many folks that use it, just like, you know, all over the world.
Were there any of things in those early days that you really, you know, any stories or things that kind of you cherish and hold on to that you couldn't believe?
Like looking back on it now, there are a lot magic pocket, which we covered in depth was definitely one.
I think that if you're lucky enough to go through hypergrowth, the company, you see so many things, you get to have so many experiences that you just would not get in other environments. I had worked at Google and I had worked at AOL as a YouTube, so I had seen hypergrowth through YouTube. But there's always the safety of Google. And so when I when I went to to Dropbox, it was, you're working in this environment. It's a massive scale without the safety net.
And you just you have a lot of technical experience. But you also have a lot of these people experiences and a lot of these, like you build these very deep connections with people that you just wouldn't expect that you would find when you're working side by side for something that's like probably eight, nine in the morning to midnight, 1:00 a.m. you're eating there, you're eating at work.
You're just working side by side with them for so much of the day and so much your life that they become you become very close to them and you come very close to, you know, them, their families. And so that's something that I will always cherish from that experience. I think that's one just the people aspect. I think from an experience perspective, I have I feel like I done every job inside of a company in some ways.
At some point you do so much recruiting early on that you click resumes in the job fairs and then for my teams and then go make sure that we had a campus recruiting pipeline stood up for some of the reliability aspects. I remember interviewing somebody for our head of physical security, which I'm in the technology side. I'm not really sure why I'm interviewing someone for the head of physical security, but he did interviewed somebody that was going to own sort of the camera sides of of the office building or doing surveillance of the office cameras and come in the lobbies, things like that.
That was an interesting experience because I knew nothing about it and had to learn about it to be able to do an interview. You just see this life cycle of a company and you just have these experiences that are just very, very telling. Probably one other one that I would say is that companies go through ebbs and flows of the brand perception in the market and such. And so getting to see that also because it plays into sort of the recruiting and the retention.
For me, there is like times I was like, OK, this is a great opportunity and just be able to reframe things as, OK, some of the team is leaving. What can I do to learn from that? Because any company that I ever work at, that's it's not an hypergrowth. There will be turnover. And so how do you think about that? How do you learn lessons from that? And it's like every one of these things is an opportunity to learn something new.
So I really cherish sort of that growth opportunity through that things that just let you learn so much so quickly.
I know you don't have a crystal ball here, but what do the next few years look like at Dropbox? What does infrastructure look like as you go? It seems like, you know, you've done a lot of work to get to this point, but I'd imagine that there's a bunch more to be done.
There is definitely a lot more to be done. I'll give a sort of reflection of the last 18 months and mirror that to where we'd like to be going forward as well.
There's been two big things on the technology side that are on the hardware areas that we've invested in smaller drives, which Dropbox is the first cloud provider to have these at scale in the market, in production, have over an exabyte on these. This is a drive technology that is looks to be the only viable option at above twenty terabytes from a spinning media perspective.
And so we made a huge investment in that technology perspective.
So if I think of that and then we made a huge bet on AMD as well, we were the first major cloud provider to put AMD in the data center at scale. And so both of those have given us, from our perspective, a huge advantage for the next few years. And it gives us a runway to continue making in technology bets like that where we can find levers that can either unlock a new capability for the business or unlock a new capability of ground cost.
Those are the types of things that I see us investing in. How can we build out a tech stack that allows us the flexibility to truly be the hybrid cloud that we want to be, I think is another aspect that we'll continue to invest in over the next three to five years. We utilize we utilize cloud providers for international data storage, for example.
Are there other things and other capabilities that we need to do that expand our global reach? From an infrastructure perspective? We have a massive network, but are there other things that we can do? Can we bring data closer to the user in some way that we haven't thought about yet? Can we increase performance on that as the products, the A needs evolve? So a lot of it, I think in infrastructure is there.
A lot of it is driven the product side as well, just in terms of how is product thinking about it. So I tend to try to stay very close to the product side of the house as well and sort of make sure I understand the company narrative because a lot of that drives that we have to do in infrastructure.
You mentioned leadership a little bit, you know. Company values being critical, building a team, being critical, you know, as a leader, how do you view the kind of head of technology role or whether, you know, whether you're in infrastructure, whether you're a CIO or CTO or security lead? You know, there's the I heard once that there's like to see the eye and the right and to be the sea, you have to be the chief.
And usually people are good at the at the eye or the middle letter, but not as good at being the chief.
How have you looked at that from a leadership perspective and maintaining building the right team and keeping folks around you that, you know, are part of the mission and feel feel included?
My so everything for me starts from belief. I am a huge believer and it all stems from belief, purpose and values. So on a continuous basis, I spend time with my leadership team on what do we believe? So infrastructure Dropbox believes that they are a force multiplier. Every single thing we do has to be about becoming a force multiplier for the organization.
And then from a purpose perspective, I think of it as what we've worked out and we talk through talk through is our goal is to maximize product velocity sustainably. So everything we ship and everything we build has to be towards that purpose. And then our values are reliable, efficient, inclusive. And so you touched on how to make sure that including that's actually a core value to us. So making sure we have the perspectives of the table, making sure that we take the time to listen to the various points of view, making sure we integrate, that is very key to how I think about things.
And as a leader of the world of infrastructure, that's actually I spent a probably disproportionate amount of my time making sure that the organization is aware and understands the purpose and values, because I think it allows the micro decisions on the ground to be made without having to have me or the leadership team dive into the one foot view and help teams through things. But. If you're doing it towards making things reliable or making things more efficient or being inclusive, you can't go wrong, and especially if you have your belief in the purpose in your head at the same time.
So I work for the organization in terms of way of making sure everything is framed up that way, whether it's our cars or I run a podcast every week as well. We talk for 15 minutes with somebody and infrastructure and we pick projects and we pick topics that are very core of our values. So a project of ships that was done in a super inclusive way that increase reliability for the company is going to be on the podcast. We're going to talk to that person.
We're going to make sure people understand exactly what the person's mindset was and how they how they went about it. So to me, that's that's how I think about it. I think it's about creating an environment where those values can be true and the team can we'll do the rest and you make sure you have the right people around you that value that are bought into those values and those beliefs of the purpose.
Final question here. Before we get into our lightning round, any any exciting trends that you see on the horizon we touched on and I think AMD is a very, very hot trend.
I think that what they're doing on the CPU space is revolutionary. I think that's going to be a huge trend inside of the industry in the next eighteen, twenty four, thirty six months less tomorrow.
I think that also is a trend. I think every company in the world right now is trying to get that into production. Those are the two big ones on the hardware side. On the software side. I think things are shaking out right now and of the container world and how people are thinking about build systems in that aspect of technology. I think there's a repeatable aspect is still coming up over and over again. I don't think we've gone fully through that journey yet.
I don't think there's been a full intersection of how the release build and sort of the production teams have all come together to say this is how how we want to operate it. I think people have done it at small scale, whether organizations are smaller and they take on all three hats. I don't know if it's been that sort of pipeline problem has been solved at scale yet and that we have technology solutions that sort of solve those workflows end to end.
Those are probably the workflow. I think that's actually probably the trend more so. Is that the worst crisis point solutions people think of the holistic workflow that you're working through?
OK, let's get into our lightning round. These questions are fast and easy, just like the Salesforce Customer 360 platform.
You can go to Salesforce.com slash platform to learn more. We love Salesforce. They've been here since the very beginning of this show and they're just the best. So check out the Salesforce Customer 360 platform. Go to Salesforce.com slash platform to learn more lightning round questions.
Andrew, are you ready? Sure. No one. What app on your phone is the most fun? Kansi Dropbox Most fun is probably.
I read a lot of Reddit in my spare time.
I spend the most time that are you to have you picked up a habit during shelter in place?
I have not picked up a new habit. I have doubled down on some habits. Actually, I would say I was not using my well, my wife's peloton that much and now I am a huge peloton fan. That's probably a habit I picked up in the last the last couple of weeks somewhere.
Hilary, are producers. Ears just perked up in the in the distance. We always we we end up, we end up talking culliton she's a huge peloton.
Plutonian What do you have a favorite instructor.
My favorite now probably Alex Song is probably my favorite instructor. I spent my time between powerlifting and and Teletón these days.
If you weren't a VP of infrastructure or in technology at all, what would you be doing.
I know the answer is is probably the most fun I've ever had in doing something, so I don't know if I would do something different. My wife is a lawyer and I'm always fascinated by it, by law. And so I spent a lot of time peppering her questions of maybe something the legal field. Do you have a hidden talent or passion? I don't.
I'm pretty much like what you see is what you get.
How about a book or podcast that you've read or listen to recently that you enjoyed?
I have to podcast that I'm a huge fan of. One is the NPR podcast. I, I almost I wasn't that religiously. I also am a huge fan of ESPN The Daily right now. I think the stories that they produced are pretty, just always creative. And I love listening to them on a wall these days.
What's your best advice for a first time VP of Infrastructure?
I'd say you don't have to do everything. That's one thing that I've learned over time is that the giving up things and asking people to do things is part of the job and it helps people grow. And it's better for everyone. It helps scale you. It helps them. So finding the ability and just being OK with giving things up for others to do and being OK with it, not coming off the way you would. But with the outcome being just as successful.
Well, that's it, that's all we got for today. Andrew, anything. Any final thoughts? Anything to play? I don't have anything to plug. This is really fun. I think you guys ask a lot of great questions. And I'm sorry I don't have a hidden talent or passion that I can think of. I probably ask my wife if I have one, but she's in the other room.
Sounds like his powerlifting. Yeah, I know I do.
I'm a huge fan of powerlifting. It's it's in a weird fashion, but.
Yes, but yeah. It's been awesome to have you on. Thanks for getting in depth on that stuff. Super fascinating. And yeah. We appreciate it.
Talk soon. Thank you.
It Visionaries is created by the team at Mission Doug and brought to you by the Salesforce Customer 360 platform, the number one cloud platform for digital transformation of every experience, build connected experience, empower every employee and deliver continuous innovation with the customer at the center of everything you do. Learn more at Salesforce.com platform.