Chet Kapoor (00:24):

Welcome back to the Inspired Execution podcast. Each episode shares the experience and learnings of a world-class leader on their journey to success. The guests on this podcast are bold, brilliant, and not afraid to change. As you navigate your own path, we hope you feel inspired by these stories, lessons learned, and the vision of the future.

We are super pumped to have Marco Argenti on the podcast today. After spending six years as a VP at Amazon, Marco joined Goldman Sachs to lead the team through a massive digital transformation. His unique approach to driving change includes building for purpose, working backwards from the customer, and driving business outcomes. We talked about all this, as well as the importance of redefining success through every stage of your career.

Marco, welcome to the Inspired Execution podcast.

Marco Argenti (01:17):

Thank you, Chet. It's great to be here.

Chet (01:20):

You have led Goldman through a phenomenal transformation and you talk a lot about embracing changes. How do you help people work through uncertainty to accept change quickly?

Marco (01:32):

We have a series of what we call tenets for engineering that are really what guide the culture of Goldman Sachs engineering specifically. One of our nine tenets is inspire trust. I think, really, the best way to work through uncertainty and also sometimes through fear is to create an environment where people can really trust each other. They can afford to be open and vulnerable sometimes and really show themselves in the truest sense. We believe that, ultimately, trust comes from transparency to be transparency with each other, being very clear on what are your expectations, and setting goals such that you have a certain tension as to meet them, but they're all achievable. Sometimes people celebrate the fact that they can over deliver on that even for a little bit, so really celebrating victories. I think, ultimately, trust builds a sense of safety and, of course, a sense of safety eliminates fear and actually gets people to feel that they can do the best work in this environment.

Chet (02:40):

I find when you're going through change, you obviously want to be very communicative and be transparent because that inspires trust, but you also need to take a set of people that you believe are, you can use different words, other leaders who are the influencers, and you want to make you sure that they actually get it and can lead the rest of the team. Is that something that you found to be useful?

Marco (03:05):

I think ultimately setting the right culture is really one of the main responsibilities of leaders. Really, cultural change comes from the top because you need to lead by example. I think one of the things that we've been doing is when setting the engineering tenets and we are setting the guidelines on how we wanted to change the culture. We started by gathering the most senior leaders having discussions on how do we want to role model, actually, the way we want to project ourselves to the rest of the organization in a way that we would've appreciate it when we were in a more earlier part of our career.

Then, of course, it's not just a sort of a top-down exercise, because at the end of the day I'm a big believer that you need to not only hold people accountable but also empower them. Really going deeper in the organization and really having discussions and conversation on how you make the culture something that it's really like what keeps us together as an organization, I think, is ultimately what we want to aspire to. It's this unique combination of top-down in the sense of being a role model and also bottom-up in the sense of being able to listen. That, I think, creates the right combination of things.

Chet (04:17):

That's perfect. One of your quotes that I really love, "Do not just build. First, ask yourself, 'why should I build anything?'" And that's building with a purpose, right? I have many examples around that, but that's a concept you can use when you have a greenfield project. But does it also apply to the brownfield part as you walked into Goldman Sachs? Has it applied to how you are running the Goldman Sachs tech team?

Marco (04:46):

I think the ability to answer the why question is often the difference between success or failure, because it's really how you define success and then how you drive towards that. The setting the objectives by answering the question, "Why should I build something? What is the opportunity and what is the problem that I want to solve," is really the beginning of any project and how you also drive a project towards success. One of our tenets is building with purpose. For us, building with purpose is really, first of all, to understand who's going to benefit from that investment. That, by the way, investment is not just building new product, it's also, for example, increasing the technical bar or operational excellence of a product. For example, setting KPIs in terms of service quality or service levels that your customers will actually notice, and then what you need to do behind the scenes to actually meet and drive those outcomes.

I think before you start building anything, the questions to ask are, "First of all, who am I building for and, really, why should I build anything," and really reinforcing the fact that today, as an engineer, you can't afford to be only focused on the how. This is no longer a pure builder profession. This is actually a strategic change profession. It's a profession that actually drives the art of the possible, therefore drives the strategic agenda. In order to embrace this new figure of the engineer, you need to understand the why and the business outcomes, first and foremost, even before you actually build a solution.

Chet (06:33):

You also talk a lot about working backwards from the customer. I call it having an outside-in point of view, AWS calls it customer focused. You spent a bunch of time at AWS. Were there any specific learnings from AWS and at Goldman on how you drive this customer-centric view, this customer-centric principle?

Marco (06:54):

I think one of the big things that I learned at AWS is when you build software and services, starting from understanding who's your customer and also setting the right expectations from the start, expectations being for example, "What is the minimum lovable product or the minimum viable product? What will actually make those customers happy and make them become advocate of your service?" And then also, what are the right KPIs or expectations from a service level perspective? What is the right scalability, latency, availability, et cetera? Because not everything needs to be 100%, by the way. Really, tuning your service level expectations to something that drives the right outcome for that particular customer you're targeting, I think, will eventually make the developer experience much better because it removes a lot of frustration from the developer community.

We implemented what we call front to back organizational counselor. Our engineers are embedded within the businesses, but also importantly, they're not physically just physically embedded within the business, but they're also embedded within the business objectives from the start. They share the business objectives from the beginning talking to their business counterparts. One of the things that we do is actually to drive the building on the construction of a working backwards document, which we had to adapt from some of the Amazon learnings, but really something that puts down on paper. What the product is supposed to do, viewed from a customer's viewpoint, answering the five famous questions, "Who's the customer? What are the benefits are driving? et cetera."

But then also asking a set of frequently asked questions where you bring in all the themes that you want a product team to be aware of. For example, the operational excellence themes, for example, the business impact themes, for example, the security themes.

One of the feedback that I got when we started to introduce this working backwards and this written culture was that it was immediately seen as a mechanism to drive inclusion. The way I say that is because, by going through the process, you're actually making sure that everybody's voice is heard. When you read it at the beginning of a meeting, you are doing the ultimate sign of respect for the people that have actually written it, which is you are listening to their voice uninterrupted for the entire length of the document. Interruption and the meeting dynamic sometimes can be so disruptive, so this mechanism ensures that everyone starts with the same set of information, discussion become factual, become respectful, and then often lead to better outcomes.

Chet (09:38):

I want to double-click on something you said earlier. You talked about customers becoming advocates. I've found it to be challenging, at least we in the infrastructure software business. You guys do a lot of infrastructure as well to get the infrastructure engineers to appreciate that somebody is going to use their product three layers up to actually solve a business problem. Because the advocacy comes from not just the resilience of the infrastructure, but also the features, like UX and things like that. Have you figured out a way to get the folks down in the stack to actually appreciate the outcomes that you're looking to drive or the KPIs you're looking to drive?

Marco (10:19):

It has been one of the most difficult cultural changes, which is to actually have the senior leadership of the firm, especially people that are not in technology, to really appreciate the importance of those elements, which can be fairly easily kind of forgotten, especially if they work well. One of the things that we've done is, first of all, to actually get teams to present to forums where you have senior leaders in terms of how those improvements at the infrastructure level are essential to meet some of the customer expectations. For example, we want products to be fast. We want products to be reliable. We want to respond very quickly to issues. We want to have the least amount of breaks in our processes. We want to have the highest standards in terms of how quickly we respond to customers.

I think, to me, the difficult thing for a leadership and for us from a technology viewpoint is really to explain how you can draw a line between the quality of the infrastructure and customer outcomes. I think, to me, velocity and quality of the deliverables and the ability to actually meet sort of a non-functional requirements such as our responsiveness services, how quickly can I escalate an issue, or latency or percentage of transactions that we can do straight through processing for is something that business people will understand. See outcomes and customer outcomes and customer expectations is where everybody meets, is where technical people, no matter where they are in the stack, and business people meet.

So, elevating that and making that part of what we celebrate, what we highlight is not just a release. It's also the fact that we reduce the number of incidents, it's the fact that we decrease our meantime to recovery, et cetera. Those things, you put them as part of your KPIs that you surfaced to the leadership team, and then at that point you're closing a loop for which every engineer is going to be grateful for.

Chet (12:19):

No, for sure. I have a saying at DataStax that says, "Activities don't pay for college educations." Outputs are important because that's what matters at the end. So, keeping everybody aligned. I love the fact that it's not just the engineers, but keeping everybody aligned on outcomes and doing a document approach, a written approach is working for you. I'm sure it must have been a massive change on what you walk through.

Marco (12:45):

Yeah, it's still a work in progress. It's still a change.

Chet (12:45):

It's still in progress.

Marco (12:47):

It's still a change. It's still a work in progress. That's really the reality of it, because culture is difficult to change, but we see definitely signals of change, we see a direction being sent, and also we see a lot of recognition that there is a direct impact on the business outcomes. I think that is, at the end, what's most important.

Chet (13:06):

For sure. One further question on this. You advocate and I'm assuming you do advocate that you don't need to wait for perfection, but you get a version of something that works and then look for feedback. I talk about the best things actually happen in the cathedral, but very quickly get to the bazaar because that's where the magic happens. It's not in the, "I'm solving a computer science problem, somebody has to start using it." How do you get the team to realize that getting feedback and iterating is really important?

Marco (13:40):

One of the things that I tell people when they ask me, "What will be an advice that you would give to your younger self or you would give to people that are at the beginning of their careers?" And what I often say is be ready to redefine what success means along the way. Really, be ready to redefine what success means along the way, because things might not end exactly where you wanted them to because things change along the way. One of the biggest mistakes that I see people make is being too rigid in their outcomes.

Often, failure is a result of this lack of flexibility. Look at what's happening right now. I mean, things are changing almost on a daily basis in profound ways, and so the ability to adapt and the ability to redefine success is actually often the formula for success. Of course, you need to keep a certain direction. If I ask you to drive to a different city, and if I give you a turn by turn navigation, as long as you arrive to the city, I can be very flexible on the fact that you might have actually taken some detours in the way. If you measure yourself with the wrong metric, which would be compliance to your turn-by-turn navigation. You will get what you measure, you will get a better outcome.

I think it's very important to be open to modifying your goals and targets. Obviously, one of the key aspects of the inspiring trust tenet that I mentioned before is that we embrace change and sometimes failure as an essential element of growth and be very vocal about it and really own it as a leader.

Chet (15:29):

Yeah. No, I love that. I often use a soccer analogy, which is it's okay to move the goalpost, because guess what, I mean, you may have been... Because things have changed, you may have scored a goal and you'll feel like shit. But if you move the goalpost, you'll feel much better about the outcome and you'll move on to the next one. That's perfect.

All right. We've got to talk about AI. You and I have spent some time talking about real-time data and AI and companies are struggling to get value from the data because of cost complexity. What would you share? Because you've been on the leading edge, cutting edge of doing this. What would you share with other leaders? What are some tips and tricks that you would share with them?

Marco (16:18):

Well, especially with AI, data is really everything. It's possibly the most important thing, because AI are trained on data and you evaluate AI based on data. It's almost sometimes difficult to really draw a hard line between what's AI and what's data. Data quality has been an incredible area of focus for us. We have massive effort to improve data discoverability, data interoperability, to have good data models that are consistent, that are extensible, having semantics associated to the data. I would say data is really the foundation of our digital transformation journey and the technology stack that we build on top of our data and the ability to really be able to extract signals from it, I think, is what really allows you to innovate and achieve agility, velocity, and also improve the quality of your decisions. Digital transformation simply will not work without those foundations.

We are, obviously, very conscious that a data strategy can also potentially drive additional complexity and potentially cost. That's why it's so important that we do it and we make the right decisions. We've been, for example, leveraging the open source community quite a bit. I think not only leveraging the open source community as a user, but also contributing to open source data platform is super important, because it makes developers feel part of it and part of what they're using and also being able to be in the loop and participating. I would say, is today the age of AI or is it the age of data? I mean, at the end of the day, I think today is really the age of knowledge in a completely redefined way. Really, this ability to turn data into knowledge and actually to leverage knowledge to kind of create new possibilities for companies, for jobs, et cetera, for how you learn, how you interact with knowledge, how you spread knowledge, how you could define knowledge. I think this could be possibly the biggest revolution that we will see in our lifetime.

Chet (18:23):

For sure. I want to double click on two things. One of the things I've been talking about when this is a little bit of the Generative AI and Open AI push and Bard and other people are doing, which is a lot of companies are going to realize that the models matter but not as much as they used to think. Their data matters a lot more because it's a signal from the model. That signal from the data is makes a difference, right? Do you agree with that concept?

Marco (18:52):

I agree with the concept. I would say that what is a model? I think it's essentially representation that comes from the data itself. It's kind of a form... It's a structure that derives from data and then is used to filter data into new data that gets produced. I couldn't agree more. In fact, I would say that, really, the big focus area that every company really needs to go through is to try to understand what are the valuable data sources that they have within the organization from which they can really extract knowledge. Then the extraction of this knowledge and then the augmentation of the capabilities of summarization, filtering, et cetera, can lead to really tremendous competitive advantage to those who don't take the same approach. I think, at the end of the day, like I said before, I can almost not distinguish where data starts and when AI starts. It's kind of part of the same.

Chet (19:52):

I'll just say personally, the last time I was so excited about technology was when the browser came out. Obviously, HTTP and all that stuff. I mean, I was excited about the iPhone, but this generative AI stuff is just mind-blowing on how big a deal it can be and for enterprises, right? Because you could take all the predictive stuff that you've been doing for years and make it so much better with these large language models that you're going to get that are in open source. It is not a just go to one or two vendors. I hope you agree with the enthusiasm of how much it is going to affect the world we live in.

Marco (20:31):

Well, some people-

Chet (20:32):

Or not.

Marco (20:33):

No, I mean, I'll tell you that I had to try to suspend by disbelief for a very long time. I've been exposed to AI for many years. Looking at what's been happening and looking at some of the results that you see out there and some of the stuff that we've been experimenting, I'll tell you that I agree that, at least as far as I'm concerned, there hasn't been anything that I could say has been more top of mind and more potentially disruptive than any other technology that I've seen. You hear all the time a comparison being made with other inventions. Lots of people are saying, "Hey, you know what? It's like the internet. It's like the browser. It is like the fire or the wheel." My favorite analogy is it's like the printing press, because it is, to me, fundamentally revolutionary knowledge. The same way as the printing press, actually removed the obstacle of actually being able to access knowledge so that you didn't have to know someone with the manuscript or know the person in order to actually understand their thinking.

The book actually removed the scalability constraint and now everybody could have a book. And then libraries were created, universities were created, knowledge was available at scale. But then another constraint that remain until today is the accessibility of a book from a knowledge standpoint. If you have a very insightful but a very difficult to read book, sometimes you need to study for 10 years just to be able to arrive to a level of understanding. I say 10 years, any amount of time. Imagine a very complex mathematical paper, but might have insights that might be of relevant is also to [inaudible 00:22:18] mathematician. For the first time, a book that is codified, knowledge that is codified in an AI has the ability to explain itself based on the reader. In fact, with the prompt, the reader almost becomes the writer and the reader and the writer are, for the very first time, are at equal footing at the same level.

Now, you actually can extract relevant information from a corpus of knowledge in a way that actually follows your understanding. That has never been done before. I'll tell you one thing. That is not just about scalability of information in books, it's also... We talked about data. I know you have a great product for data that is in computers, but do you have a product for data that is in people's head? If you look at any company in the world, a lot of data, a lot of knowledge is very tribal, and it is actually in people's heads. One of the great things about language models is the fact that you can combine artifacts of what people leave as traces, what they write, what they say, or you can train them on the thinking of people. Then at the end of the day, you can actually codify that knowledge into something that can actually be at scale. People could one day interact with some of the experts without having to send an email or without having to... They would just chat with the model that has been trained with their thinking and imagine how scalable could that be.

Chet (23:51):

That's a great segue into our rapid fire questions, which is brought to you by GPT-3.5. We're not quite using 4.0. What song are you listening to on repeat?

Marco (24:04):

Oh, I'm listening to Ordinary World by Duran Duran.

Chet (24:09):

Ah, we both date ourselves. That's awesome. Favorite app on your phone?

Marco (24:15):

I meditate with an app called Calm. I really like it.

Chet (24:18):

You should try Waking Up. It's just as good.

Marco (24:21):

Is that because it looks like I'm falling asleep?

Chet (24:23):

No, no, no. The app is by a gentleman by the name of Sam Harris. It's a good app, but Calm is great as well. If you would like to have dinner with anyone dead or alive, who would you choose?

Marco (24:34):

Probably Alan Turing and I would pick his brain on AI.

Chet (24:39):

Yeah, he was way ahead. What's your least favorite tech buzzword, least favorite?

Marco (24:46):

Framework.

Chet (24:52):

Spoken as a true practitioner. One word or phrase to best describe great leaders.

Marco (24:59):

I think great leaders are those who inspire others to operate at their best. Just get the best out of other people.

Chet (25:09):

Generally, you would agree more than what they think they can get from themselves. That's the part that a lot of people forget, which is you think you can run a nine-minute mile. You actually may be able to run a eight-minute mile if you do this the right way.

Marco, this has been all our conversations. Awesome. A blast. I think we could go for another hour on this. At some point, we'll have you back. We really, really appreciate it time. Our listeners will absolutely love this.

Marco (25:37):

Thank you, Chet. It's been a great honor to be here. Thank you.

Chet (25:40):

We'll talk soon.

Marco (25:40):

Bye.

Chet (25:42):

Thank you so much for tuning in to the Inspired Execution podcast. If you enjoyed today's episode, please like and subscribe. We have many more phenomenal guests and inspiring stories to come, so be sure to join us next time.

Inspired Execution

Marco Argenti

CIO, Goldman Sachs

Driving Business Outcomes in the Age of Knowledge with Marco Argenti of Goldman Sachs

Episode Transcript