Host Intro (Gene Kim)

I had mentioned, in day one, that one of the goals of the program is to help leaders develop the careers of their teams and for themselves. In that context, I would like to introduce Ian Eslick, who I'm a huge fan of. You may know him because he was recently the CTO of U.S. Bank — he joined them in 2019 from Amazon — and he just accepted a new role as the SVP of Infrastructure at SoFi, whose mission is to help people reach financial independence to realize their ambitions.

I've had the opportunity to observe Ian's journey at U.S. Bank over the last four years and have been fascinated by the arc of his career there. Last year, we were talking about some career puzzles that we've been mulling over in the programming committee: How do engineering leaders more reliably navigate into the most senior roles in their companies? What can leaders do to best advance the careers of themselves and their teams? What enables it? What hinders it? And what can we do as a community to bring teachable skills to bear? I've so much appreciated Ian's thoughtfulness on these questions, and he's going to share some of his experiences and learnings with you. Here's Ian.

Ian Eslick

Wow — thank you Gene. And wow, that talk before. The only way to follow a talk like that is to change it up and talk about something completely different.

As Gene said, the genesis of this is kind of a more personal talk. Usually I get to talk about cool technology and teams and evolution, but you asked me to talk a little bit about my own journey at U.S. Bank — and kind of how I moved from a relatively focused role lower in the organization to a CTO with significant scope of responsibility, as well as driving some very large change initiatives.

What I'm going to try to pull out today are some of the things that I brought that I found really useful, and things I learned about the company that were essential to unlocking value. Hopefully it'll help spark some thoughts in you about how your company is set up, how you can learn, and how to work with those constraints.

A little bit about me. When I started doing the counting, I got sort of stunned: I've been in technology for 35 years. I don't know if Gene knew this, but I started my career as a civil servant for the Navy at the age of 16, as a high school intern working on Unisys mainframes, writing COBOL, and playing around with early multimedia in the eighties.

Over the years I've worked in lots of different industries. I describe myself as a high-tech plumber. I've built microchips, I've built medical devices, I've worked on low-code technologies, I've done AI, I've done research in machine learning.

And there's something common in all of these jobs. I want to talk about really the two key things I want you to think about today.

One is the superpower that almost everyone in this room has to one degree or another, and it's systems thinking. When you are solving a complex technology problem, or you're trying to solve a schedule, you're dealing with people, processes, technology, constraints, money — especially those of you who have moved from engineering delivery into management. We deal with a lot of this.

I've been at the talks over the last few days. They're all about systems thinking: models for organizing your team, models like the one that was just mentioned, changing the way finance is structured to change essential constraints so you can change the way your team executes. But in order to be successful with the insights that come from systems thinking, you really have to figure out: how do you instill those insights into the culture that you're embedded in?

I think of this as hacking the culture — the good kind of hacking, not the bad kind. And what I mean by 'good kind of hacking' is you have to figure out the pressure points, the points of leverage, the storytelling that's going to make a change that ultimately drives different decisions, different resource allocation, and different behavior.

When I think about systems thinking, something I've developed over the years is a pretty simple playbook. Take a point from Coach Lasso — or Coach Wooden — be curious. Why is this crazy thing happening?

One thing I took away from my time at Amazon is the principle-engineering tenet of 'respect what came before.' That's been essential to avoid insanity, because every system you encounter — which often is working counter to what it's trying to accomplish — evolved under very specific constraints, by very well-meaning and intelligent people trying to solve the problem with the constraints of the day. And then those systems atrophy over time: the world around them changes, but the system stays the same.

So that respect is essential to be able to open your mind and be curious about why this is going on. And then the classic five or seven 'whys' — just why, why, why? Sometimes I get in trouble because the teams are like, "I don't want to talk to you, you just keep probing and probing and probing." But you have to understand what drives the behavior that you're seeing.

Once you've done that — I was very influenced early in my career by Goldratt's The Goal and the Theory of Constraints. It's essentially a way of thinking about: what is the bottleneck for my system? What is the one constraint that if I relieved it, I could compress time, accelerate value, change minds?

So I'm going to start with two examples — one small, and another a bit larger.

01Example 1: Month 4 on the job — COVID

On month four in the job, COVID happened, and that created a lot of really interesting moments for companies all across America.

I got a call on a Sunday morning from my boss, who I'd worked with in the past. He said, "Hey Ian, I know I talked to you about this a week ago, but I really need your help. We've got to figure out how to take a hundred thousand transactions and run them through a system in a week that was designed to do a hundred a month. And right now we're looking at hiring two or three thousand people from our branches to do data entry into a system that crashes every tenth time you hit the keyboard. We have no idea how we're going to get the throughput in the week. There must be a way to automate this. We have 18 days before His Earth!" And that was what it felt like — except we only had seven days.

So you have seven days to take a system that's typically designed for a scale cycle time of three months — legacy mainframes, service buses, and all sorts of interesting things. We were able to identify an old SOAP interface that the third party had, so there was a natural way to do engagement.

The solution itself probably ended up being two pages of code and a data-mapping exercise — like, from a technical standpoint, trivial. But there were a lot of limitations in the way the third party allowed us to interact with them, and that created challenges for the bank.

One of the things I love about U.S. Bank is the principle of 'do the right thing.' It's instilled in the culture, it's the top value, and it's really how a bank should be thinking. Given all the impairments, the challenge for us was to figure out how to navigate policy and procedure in a matter of a day or two — in order to go through security, risk, compliance, EA, multiple risk organizations — multiple debates, technical integrations. We had to get three or four technical teams aligned.

Ultimately that was the system bottleneck. The CEO was like, "anything you need, pick up the phone, call anyone." And so we just did problem solving — how would we work through this? Be curious about the security constraint or the risk constraint or the right exception or the right framing or the right mitigation. And we were able to ship on time.

What was really interesting about this exercise: of course crises are fun, but they're also an incredible catalyst for changing culture, because during a crisis people are a lot more open to new ideas. All of the normal antibodies to change sort of go down, and there's only one goal that matters: nail that goal. And I'm willing to look at the other things differently. That doesn't happen every day.

For years, this little example resonated — there were three or four other workstreams with similar amazing outcomes. But it resonated because the senior leadership of the company said, "I had no idea it was possible to move this fast — never seen it." Another interesting one was that they'd never seen an engineer — because we were doing daily stand-ups morning and evening with half the managing committee of the bank. When legal was going, "No, no, you can't do that," I said, "Well, if you took this legal risk here — we looked at it this way — the legal risk is small and acceptable, but I can do it tomorrow as opposed to a week from now."

Winning an argument with a general counsel member in the managing committee is not common. But it was exemplifying that systems thinking — that engineering thinking — looking across all the constraints, finding the one that relieves the bottleneck.

And then I learned something really important about culture afterwards. I got a nice call from some of the senior leaders saying "thank you." And then this quote has stuck with me ever since. He said: "You know, it wasn't so much that you got the result. It was how you got the result. Do the right thing, be respectful, be calm."

I started thinking about all the leaders I worked with. Every one of them was calm under pressure. No matter how bad things got, people were just very even-keel. It's a Minnesota thing, but it's also essential. When I was interviewing, I had somebody say, "Hey Ian, don't be the New Yorker when you come into this environment. Don't tell everybody they're crazy and don't tell everybody they're stupid — really engage." That's my natural tendency, which worked well in this particular environment.

02Example 2: Building a Dev Platform

The other example, very apropos of this conference because we've been talking about platforms for a few years: when I walked in, we were a service organization. We had many different service groups — DNS configuration, CI/CD pipelines, authentication, cloud.

When I started out I was like, "Wait a minute — so a developer on some of the teams I inherited has to work with 30 independent teams who don't talk to each other? The documentation isn't in the same place — it's all different systems spread all over, and essentially all tribal knowledge. You have to be at the bank a long time to learn what those processes are."

So I started asking questions: "Well, why is that?" "Well, you know, it's the way we're organized." "Have you talked to this other person?" "No." "Would you mind getting into a meeting? Maybe we could start a forum and just start exchanging ideas." So we created an ad-hoc community of practice, started assembling the leaders from the different teams, trying to understand: how are we structured? How do the different service teams work? What are we trying to do for automation? Where are the bright spots? Who are the smart folks? And at this point, this was way beyond my job scope — I was working in one narrow area of cloud, helping with our data platform.

The next year — with the events of 2020 where I was able to do that last example — the next big thing I had to do was earn trust with the senior organization by demonstrating that not only was I good technically, calm, and fit into the culture, but that I could run a program at the scale of the company. I had one OKR that year, one objective, which is: "Keep this program green, because I'm going to take away the bean counters. I'm going to give you a lot of autonomy, but you have to nail it." That year went really well.

That led, in 2022, to recognizing that the hyperscalers were willing to make significant investments to help us adopt cloud. I had spent two or three years working with the teams, with risk and compliance and security, trying to understand: what's the case for the organization to adopt a platform? And it all came down to automated risk and governance. How do we standardize the way that we practice so that we can instrument it and automatically document and publish the evidence that we need to convince ourselves and the regulators that we are doing things right? We're doing the right thing.

In order to get the agreement to do process re-engineering, I had to talk to an external consultant, because I didn't have enough tenure in the company to really make the point. I remember the meeting when a senior leader was saying, "Well hey, we're going to cloud, that's going to fix all these automation problems, right?" And the consultant says, "Well, you can't automate a process that's written and defined as manual." And I just saw his face fall: "Oh, right."

That's what led to this program — we did a really significant investment, hired a bunch of new teams, and over the last two or three years have been on a journey of rolling out a platform. Some of my former team members are here in the audience today.

So we were able to think about how to change all of the side effects of policies — standards and procedures. We were given a mechanism within the organization to bring all the stakeholders together to identify: hey, in order to get an outcome, how do we change the policy framework?

The motivating example I used: I had a senior engineer who had been at the bank a long time. I said, "How long does it take to get hello world in dev from scratch?" "37 tickets and three weeks later, hello world on a Kubernetes cluster, on-prem." "All right, great. So our goal over the next few years is to get to zero tickets and less than an hour to build up new infrastructure, get hello world in dev — and I want to be able to go to prod in less than a week. So what does it take?" Starting to work backwards, we spent the last two or three years working through: how do we automate the governance, how do we automate all the technology to make that work?

03Strategic selling and decision making

This process of identifying constraints, talking to different stakeholders, understanding their motivation — is just strategic selling. When I worked with the leaders I was trying to grow into my position, one of the things I had underestimated — having been a startup CEO and done a lot of selling to venture capitalists and customers — is how important the practice of selling is to success in large organizations.

Learning how to adapt your message to the audience, understanding their different roles. You might go talk to a security team and they'll say, "Okay, I'm okay," but then another security team will come out of the woodwork and go, "No, I'm not okay with that." So you have to have a mechanism to address that. Understanding those bean counters — the people there to enforce the guardrails — the gatekeepers, those who have an opinion about what you're trying to sell and can say no but can't make a decision.

One of the most fascinating things about really large organizations is that sometimes there is no decision maker. It's just too complicated; there's too many stakeholders. So it ends up being a consensus problem.

The first thing I pulled out of the bank was starting to understand: how did decisions get made? It took me a couple years to figure this out. I wish I'd known this on day one. So hopefully my new colleagues will explain to me how this works in my new place, because every company is different. But here, there are really only four ways to get somebody to do something.

They report to you. You own a budget item. You own a policy and can say no. Or you can pick up the phone and call somebody and they'll listen to you. And that is actually how those decisions that didn't have clear decision makers got made — that's how the company functioned over many years, because U.S. Bank has wonderful long tenure (I had somebody with 50 years of experience on my team, in the same company).

The informal trust relationships are how you build consensus in an efficient manner. So then it goes back to: how do you build trust?

We could talk about this all day, but I want to talk about how do you build trust not with your team or your peers, but with the senior leaders above you who have to get comfortable with handing you a nine-figure program.

Every organization is different. I just want to provide a little bit of an example, because I've worked at Amazon and I've worked at U.S. Bank, and they're different cultures. They prioritize different things. Every company picks its priorities and picks different values. So these may resonate for you, these may not.

If I think about Amazon: Amazon valued deep domain knowledge and delivery, and the 'how' varied a lot, depending on your manager. It wasn't a priority to get the 'how' right — other than cultural conventions. The Amazon way is definitely embedded in the culture.

That cultural-convention thing was the same at U.S. Bank — there's a certain way in which we work, the way we communicate, the way we report, and you have to fit into those conventions. But predictability was how senior leadership judged competence. So if you were going to take a risk, you had to be very thoughtful about how you did it, because you had to create predictability even around the unknowns. Don't have a problem come up that you didn't call out three months ago. Once you understand the importance of that, then you can start thinking about the metrics that you use, so you get early warnings of change — because predictability equals competence.

And then personal integrity was central to success at U.S. Bank and earning trust with senior leadership. That was ultimately what led to long tenure.

04Bridging communication gaps

The last thing I want to go through today is communication. As I've worked with my leaders helping them grow up, everyone has unique challenges engaging with and talking to folks throughout the organization — especially when you come from a tech-company background and you're used to a whole set of supporting mechanisms that no longer exist; you have to create them.

The burden of clear communication is on the person who wants to drive change. It's your job to figure out how to meet the other person where they are — to understand their goals, their communication style, their language, the mental models, the metaphors that work for them.

95% of all the problems I encounter are fundamentally disconnects on communication. Almost every problem I can — it's not like I'm a bad person. I mean that happens now and again, but it's so rare. And fundamental disagreements — are we disagreed about the goals of the company? Sometimes that happens, but it's still very rare.

So I just go through a very simple logical curiosity engagement: Do we agree on the facts, the goals, the principles, the tenets? Are we operating from the same base? If we disagree, either I'm going to learn something — maybe there's something I don't know. And I genuinely approach that with a mind of curiosity, because one, it's the right human engagement. Like, I may be wrong — I'm probably not — but I may be wrong. And that's an important posture to take, because then the opportunity is: well, what is the other person missing that I can lend to them to help them grow and think differently? But I have to figure out how to meet them where they are.

The problem is that we all have different backgrounds, different language, different knowledge. As engineers we have a deep body of knowledge, and we spent most of our career reporting to people who had the same body of knowledge in varying degrees. And now when you get to the senior-most levels, you're talking to somebody whose background is in marketing, finance, accounting, sales, business. "I don't even want to hear about technology." I've been to meetings where people are like, "Why are you talking to me about technology?" I'm like, "Well, your entire product runs on it." "I don't care."

So how do I get a message through? Often what I find with the engineers I've led is they're like, "I'm telling them the truth as I see it, and it goes through that channel and it comes out all distorted." And what they hear is — like, the [modem-handshake] noise.

[Plays modem-handshake sound] So listen to this. [More modem sounds, then the white noise.] Oh, there's the beautiful white noise. So that white noise is when the channel's being maximized, communication's going through, all the spectrum is being used. But all of those up-and-down beeps and boops at the beginning of every modem connection — that is the speaker sending a signal through the channel and then listening to what comes back, and then adapting and building a model of how does the channel distort my message?

I struggle with this to this day, depending on the audience — trying to talk to the CEO of the company, who's a quant genius, or a CFO by background, trying to explain technology trade-offs. Everybody has a different sort of language and a different way. And you can practice this with anyone — you're working with somebody in security, you can practice. You're working with somebody in finance, you can practice.

But what's really interesting about digital modems is they actually build an inverse model. They apply that model to the clear signal and pre-distort it, so that the signal comes out clear at the other end after the channel re-distorts it.

And that is marketing. When I was starting my career, very early on, my engineering founding partners were like, "Why are you lying to the customers? Why are you lying to the investors?" I'm saying, "I'm not lying — I am trying to present a truth that's consistent with all the things we're going to do later, but that's going to make sense to them." So I'm trying to figure out how to distort my message — if you will — from the way I would like to say it, to the way that's going to really work for the audience. And that's part of serving the audience.

05Closing

If you think about supercharging your career: extend your systems thinking superpower to all parts of the organization. Start to map out the constraints of your organization. In my case it was finance and it was risk. So process re-engineering allowed me to unlock that with finance — we made some significant progress. Decision making was the thing I was still working on; there were some complexities in how we made decisions I was never quite able to figure out. So again, the hacking continues.

One of the highest moments in my experience mentoring new talent was trying to teach these things to somebody who'd come out of a long tech-company background and came to U.S. Bank and said, "Why do these companies fail sometimes to make these projects happen? Can I help do it differently?" There was a lot of friction with the rest of the company. So we did coaching and engagement over a long period of time. I remember I got a phone call — I was actually on vacation about to head out into the mountains — and he calls me up and says, "Yeah, I realized that working with the company is kind of like hacking on a technology system. Like, you give an input here and you tweak over there and you earn some trust over here, and all of a sudden things happen, and then you get these outcomes. It's so cool." And I was like: yes, he's going to make it.

When you think about your own career — there's so much opportunity to practice the communication, the modeling, the systems thinking. And all of you have a background to be good at it. It's just a matter of practicing and learning some of these other skills.

I want to thank you for your time today. Gene, thank you for inviting me. Have a good day.