Hey, Rosalyn. Hey there. How you doing? I'm doing great.

I love your socks, by the way. Hmm. So do I. Yeah, yeah.

I've been wearing 'em all week. Well, all the variants, you know, you gotta have Phoenix Project, unicorn Project and, and the fun ones. Indeed. Yeah.

Indeed. Yeah. Big fan. Yeah, absolutely.

Sock Game is strong. Yes, it is. Okay. So speaking of strong, um, uh, you're doing some strong stuff at I B M, which is what we're here to talk about.

Yeah. I'm having a lot of fun. I can imagine. I can imagine.

I, I Fun. Seems to follow you. Or maybe I go to fun. There You go.

Yeah. Okay. Um, well, so one of the fun things, uh, that I think you're, you're working on now is, uh, is transformation. Mm-hmm.

And a lot of, a lot of organizations struggle with, with transformation. It, it's, it's way harder and takes way longer, uh, than they, than they think at the beginning of this. Uh, what are the, what are the stakes of the transformation effort that, that you're involved in? Most transformation efforts, um, have an option to not be done at certain time periods.

Right. Most transformation takes a long time, and, and it should, because transformation takes a long time. Our current project has a, uh, has a very specific deadline. Um, basically it ended up being two years from, um, and so it's the end of this year.

And so we don't have a choice. We will exit the data centers. We have built a new team. We will transform the ways of working because we can't do anything else.

Yeah. Um, so we don't have a choice. And I have to say, transformation projects under deadlines are the worst way to do it. And, and we will succeed.

Will I be in the state I wanted to be in when I'm done? Absolutely not. Will I have done all the transformation I want to do? Absolutely not.

Will I be out of the data centers? Will I have a new team? Will I have started the transformation to SS r e? Absolutely.

Um, and then the transformation will keep going and we'll spend the next two years moving all of our applications into modern ways of working. So, will I be done yet at the end of this? No, but I will have succeeded in the parts that had deadlines had. Right.

So your definition of done may evolve along the way. Uh, well, you hit on a lot of stuff in there. Uh, in terms of what, what's involved in this, this transformation? What are the, the pieces and parts of the things that you're tackling?

You know, the biggest one really is data center exit. Um, we do have to go from 11 to four, um, and we have to have, we have to be out. Um, we don't have a choice. Um, we have to do the network separation we have to do.

Um, and so it's a real challenge. The added challenge that is driving me a little crazy right now is I have two of the four data centers currently built out, and I must, um, move into four because I need my new data centers in Europe. So I will, we were bu we will be building out two more data centers and moving into them before the end of the year. So Wait, Wait, wait, wait.

By the end of this year, whi which year? This year. This year. Okay.

Just to be clear. Okay. This year. Okay.

Yeah. We don't have a choice. What could Go wrong? Um, supply chain, supply chain, supply chain skills, uh, yeah, lots could go wrong.

Got it. And this is, I mean, realistically we wanted the systems already, but you know, supply chain causes problems now, not supply chain. With my hardware, I can get my systems, I know, I know how to escalate that to get my z boxes. Not a problem.

Um, but that doesn't mean I can get everything. And so there are supply chain issues. And so that is one of the challenges that, and I wouldn't, everybody is doing some kind of data center consolidation. A lot of people are doing it because they really do wanna be more efficient in their data centers.

And so I, I think it is a really important thing to look at. Where are your data centers? Are you the most effective with your data centers? Are you in energy efficient areas?

Are you meeting your sustainability goals? Uh, so it is important and a lot of people go on it this journey. I wouldn't say hard deadlines are great, but we're gonna do it. They are forcing functions.

Mm-hmm. For better or for worse, I suppose. Now, now in your talk, in addition to the data centers, uh, you talked about some other parts of this transformation, uh, so that, yes, there was the data, data center consolidation. Um, there was, uh, tackling modernization of the, of the tool chain.

Um, and then there was, uh, you know, the added benefit of, of changing out your entire team. Mm-hmm. Uh, and I think you also made the point that you would not advise others to take that same approach. Um, say more about that.

Uh, I would recommend one of the three at a time. Um, doing all three at the same time is crazy. Uh, there, there are some advantages to doing modernization and new team if your old team is not willing to change. So, so in some cases, I have worked in with some organizations that bringing in some new people helped with that transformation.

So an entire team, probably not, but it does help to bring in new people in a transformation if you're really trying to, to really modernize or at least get people who have a different view on the world. Yeah. Getting people who want to modernize is important. Yeah.

And you mentioned that in your talk, that when you, when you were seeking out, uh, people to join your team, that you, you wanted to find people who wanted to change. Mm-hmm. How did, how did you do that? How did you, um, how did you discover or learn, or put your finger on this, this person is, is one who wants to change, Uh, the advantage of 35 years in the industry and having a large network.

Yeah. Uh, so I have been working with some people for a while who I knew were challenged in their organization by not being able to do everything they wanted to do. Hmm. So they were limited in getting to infrastructure's code.

They wanted to do the work. And that's one of the people I hired on. Um, because he, I, I knew he was really challenged. I knew he wanted to do this.

He'd done a lot of work in open source to help with this, but he got stymied by his company. Now he was retiring. And so I went, well, this is simple. I'm not hurting another company 'cause he's retiring anyway.

Mm-hmm. Um, so done. Hey, come work for us and you get to do what you've been trying to do for the last number of years. And many of the people I've gone after have been the same type of personality.

They have been driving change in their organization some cases very successfully, some cases very stemly. Uh, and, you know, they wanna change and, and they're basically coming to have fun. I mean, this isn't, I mean, yes, it's a challenge and yes, it's a huge challenge, but it's also fun getting to do things in a totally different way. I, I'm building a greenfield z o s environment.

I mean, when do you get to build a greenfield environment and then tell applications they have to modernize to get into it. Yeah. Doesn't happen very often, Let alone on Z O Ss. Yeah.

Yeah. Um, so, uh, you know, we were talking about change and people who are, who are, uh, wi willing and maybe even excited about change, fun equals, you know, challenge, uh, for, for those folks. Um, but one of the other aspects of this modernization, uh, that you're running was, uh, modernizing the, the tool chain. And, uh, I think in your talk, you, you said, um, this is about removing tools from developers without having them get angry, uh, share some insight about how exactly to do that.

We Won't totally succeed in doing that. Yeah. Um, but I b m has a fundamental problem in many ways that we have allowed total flexibility. Hmm.

I mean, in, in I B m, we never, we never had rules about you can't use that. I mean, security rules. Yes. You can't just pick something up from open source, you have to vet it from a security standpoint.

But we have all sorts of products and divisions use all sorts of things. And so we really have to not do that. It's not really fair to developers because they're doing a whole bunch of work for security and a whole bunch of extra things that they shouldn't have to do if we had a standardized pipeline and a standardized set of tools. Now, there are places where use whatever you want when it comes to an I D E, those kinds of things.

But we really do need to standardize on the pipeline, and we're gonna try and help make people understand that it's important and there's value in onboarding in the new pipeline, rather than just saying, take it away. Mm-hmm. I mean, yeah, we're gonna have to take it away, but there's value. If you have all the security checks embedded in the pipeline, then it's easier.

You don't have to go do the next mm-hmm. I b m security. I mean, security challenges come up every day. And if the pipeline does that for you, does all the checking, and when some new tool gets decided to be the tool you have to use, if it's done for you, it's a lot easier.

Yeah. It would, it sounds like it would alleviate a lot of the burdensome stuff. Mm-hmm. The, the toil maybe, uh, from, from those folks.

So I think it sounds like you're framing this in the what's in it for them, for you? Yeah. Mm-hmm. Yeah.

Yeah. I really wanna frame it. And what's in it for them removing their toil, removing, I mean, they, they have development teams of resources doing pipeline work, and they don't need that. Yeah.

We don't need to waste that. We have like 120,000 developers. Imagine the amount of waste in our company. Mm-hmm.

Because every development team has their own pipeline. Yeah. Yeah. I don't wanna do that.

Math May, maybe there are good and right reasons for that, but probably not, at least at that scale for sure. Uh, so what one of the other, you know, the, the, the modernization and the transformation effort, um, that, that you're leading, uh, was certainly one big theme of, of your talk. I think there was another theme in your talk, which was about individual contributors, uh, which is what you are at, at the executive level. Um, and you were making the case that, um, that, uh, or at least made the statement individuals, individual contributors aren't usually considered quote managers.

And yet that's the role that you find yourself in now. Well, I'm not a manager. Okay. I never have been, and knock on wood, I never will be.

Um, I'm not a manager. I hold no people management responsibilities. I am a leader. Mm-hmm.

Absolutely. I do help find people. I do work with people, I do mentor people, but I don't do people's reviews. I don't decide any of that.

I don't have to do any of the yuck of management. And I gotta be really clear. Managers are really, really, really important. So I'm, I'm not trying to say managers are not useful.

They're very useful. They help people grow their careers. They help make sure all the management stuff is handled either. That is a really important role.

And so we need people who are really good managers, and we need really good technical leaders. And by having that partnership of management and technical leader, it's a lot easier for the technical leader to lead the team from a technology standpoint and not have to spend time dealing with the other things. And so that really is important. And there are a bunch of us like me, who would not make good managers.

I, I, I know that. I know. So I can use my leadership skills, I can help people, I can mentor, I can grow the next generation. I can do all these good things.

Mm-hmm. And I can lead large teams, but I don't have to be a manager. Yeah. And that's important.

I think you, you, you drew an important distinction there between le leader and manager and, uh, how neither one is, uh, better or worse than the other, and both are necessary. Mm-hmm. Yeah. Uh, so what you, you talked about your, your career, your career trajectory.

What led you to, to be in this role that you're in today? Luck. Oh. Um, really and truly I wanted I b m fellow and I, I guess that's been a goal for a very long time.

And so I had to find a role that could be a fellow. Well, so what's a, what's an I B M fellow? Describe that? Uh, An I B M fellow is the highest technical executive we have in the company.

There are very few fellows. Mm-hmm. Um, people are created, you know, I, I, I don't fit this criteria. So, okay.

They've done Nobel Prizes or they've won touring award winners, or, you know, created compilers, um, created the, um, scanning, sc scanning, tunneling, microscope. I'm, you know, those kind of people. Mm-hmm. Those are fellows.

Uh, I guess I made Z O S DevOps able, so that's why I got fellow, um, the person who did quantum. Oh. You know, that's a fellow kind Of big deals. Big deals, including making c o s DevOps.

Yeah. So they're really re really, but they're very few of them for a reason. I mean, we have distinguished engineers and that is also a technical executive position. Um, and there are a lot more distinguished engineers, but fellows are really limited and really as was described, we're made fellow for what we've done, but an expectation of what, what we're going to do.

Mm-hmm. With a fellow title and the fellow title. I mean, it's an appointment. It's appointment by our C E O.

The c e o is the only person that can make somebody a fellow. It really is significant. And it, it does help in helping lead a team to be a fellow. It, it, it, it does, it, it, it causes a lot of benefits.

It causes some negatives too, but it causes benefits. Um, I, I'm not sure which one this is, uh, but you touched on something there, the benefits or the negatives, uh, in your talk, you also said that your team calls you, I believe, the big hammer. Mm-hmm. Mm-hmm.

Okay. Um, and I, and I believe they meant that in the way that you were sharing it with a, with a very positive sentiment. Could you share more about that? Yeah.

So there are times when we get challenged. We're trying to do a whole bunch of things very fast. Mm-hmm. And so sometimes we have to, um, do things in a very expeditious way.

And so you get limited every now and then. And so the team uses me as the hammer to say, why are you getting in the way? Or What's the issue here? Or how can I help you understand that this is really important?

Um, so it's, it is actually kind of funny. Um, the team actually said something about, thank you for the hammer. And I'm like, I just sent a note. Yes.

You sent a note. You said this was important. Mm-hmm. So it became important.

Mm-hmm. And so that's helpful. Do, do you have maybe a, uh, a favorite story or an example of, of being the big hammer that unstuck your team? Uh, well, it, it's happened a lot.

It's a lot of things we need to temporarily break rules. Yeah. I really hate that. But we need to temporarily break rules in order to get something done.

Uh, and a lot of times people will push back on those, breaking the rules. And so people will remind people, Hey, Rosalyn's on copy. In other words, she approved this. Okay.

You're breaking a rule for a reason. I get it. And it's mostly to do with IDs and security. Um, we have a very controlled environment for a reason.

Yeah. Yeah, For sure. Um, and sometimes getting something done needs an authority level just to get it done. And so that's one thing they used me for.

The other thing is I actually have a broad network of connections. And so, um, when I need help, uh, I just send a note to the team that's gonna help And they know you And they know me. Mm-hmm. And they know what I'm doing mostly.

Yeah. And so they're like, sure, we're happy to help because they get experience, they get to see how we're using it inside I B m. And we're a friendly user of our technology. Um, as Client Zero, we are using I B M products in a lot of cases.

And I'm more friendly than a, an external client. Maybe one because I know 'EM all, but two, because we are more friendly. We are, I mean, in a sev one, we're still a sev one and we still have to get it fixed. But we, we will provide more data because we can, because it's internal.

Mm-hmm. We can give them access to our systems because we can, 'cause it's internal. So there are things that are a little different. So, you know, we're a, a friendly help to teams.

Yeah. What, what is that? You mentioned the client Zero concept. What, what is that about?

Client Zero is to say, we are going to use IBM's technology first, uhhuh in many ways, so that we can showcase that it can scale to a real enterprise in a real environment doing real business work. Now, we won't run every I B M price. It's not that we're gonna run everything just to run everything. We're gonna run what we need for our business.

And we're not in every business, so we won't run everything, but we will run a large chunk of our systems and demonstrate what's possible. Mm-hmm. It is kind of like eight nines. My, um, my favorite goal right now, other than just flipping every six months, is to run at eight nines.

Uh, yes. Eight, I mean, eight nines. I want to demonstrate and show and be a showcase for eight nines. Uh, I'm not gonna do the math in my head 'cause that would either be a really big number or really small number.

Uh, so Seven nines is three seconds a year of downtime. Okay. So eight nines is smaller than that. And I never remember what it is, but basically it's all Three tenths of a second.

Yeah. It's always on. Yeah. I gotcha.

Um, and we won't, we won't cover this now 'cause people can look, watch the video of your talk, but when you're talking about Client Zero and using I B M technology, um, in advance of other customers, uh, you, you're not trying these things out in a trivial environment. The scale and complexity of the I B M environment is, uh, huge. Is is is notable. Mm-hmm.

Yeah. Yeah. So people can watch your talk, get an idea and sense for, for what that, what that's all about. Um, back to the career trajectory, you, you mentioned that, um, your career trajectory resembled a snake rather than a, than what people usually think of in a career trajectory is more of a ladder, uh, share more about that.

Right. So realistically, no career is really a straight line. Hmm. And if you assume it's a straight line or a ladder, then you're gonna be solely disappointed.

Hmm. Because real reality is you need to learn, you need experiences, you need to grow. And so a lot of times that means you take lateral shifts, you, you move to something else. Um, one of the teams was joking, um, because when I get bored, I find another job.

So it's really important that I don't get bored. So I keep working on a subject and I've got enough challenge for a while right now, and I'm having lots of fun. But it, it really is you, you need to assume that you're there to grow, learn, and have fun. And so your career should be milestones on the journey of doing the right thing for you.

Mm-hmm. Uh, and then you have, you know, life outside of work too. And so there are times when you need to make decisions that are based on home life, not work life. Right.

And so change jobs because it's not the right thing at the right time for home life. So it's gonna be a, a snake or a, a curvy way, you know, whatever. Everybody's journey's gonna be different. No two journeys are the same, and everybody needs to recognize that.

Yeah. That, that right there is probably another whole discussion in and of itself, maybe two or three. Um, but I will ask you this. Was there a, was there a common thread in those, in those job job changes?

I think there was one I heard, which is you got bored with the job that you were in. Mm-hmm. How, how did you know, was there a common common thread or a theme or factor in, in the job that you jumped to? Uh, well, it, it really was either I was bored or it Yeah.

I wasn't learning anything. Mm-hmm. I was still having fun, but I wasn't learning. Well, that's not good.

Um, so that was why I would jump, the common thread in my career has been always working with customers. Hmm. And so, uh, I have always starting two years into my career, worked with customers to understand how customers use technology. And so I've always wanted a way to stay connected to the customer.

Um, and, but, but really and truly, no, there hasn't been commonality. I, I did assembler development with I S P F, and then I did user interface design and human factors, and I've done services and I've done, yeah. So no, there wasn't a lot of commonality, but there was something about that new role that would give me an opportunity to learn something new. Yeah.

But there was something in that role that I could bring existing skill to. Hmm. So there was something about it. The, the biggest jump everybody said I was crazy was when I went from systems management into application development tooling.

So I was building systems management products, and I went into application development tooling. And this was when I was an S T S M trying to get to de they're like, you're crazy. They had nothing to do with each other. And I'm like, wait a minute.

I'm building systems management tools. So I'm an app developer, so now I'm gonna go into tools for app developers. Of course there's something I know about this space, but it was different. Yeah.

And it was a totally different division and I b m and it was a jump, but it worked out. It, um, yes. It sounds, it sounds like it, it was part of that, uh mm-hmm. Part of the snake.

Yep. Um, was there a, uh, was there a, a, a jump that you made, um, maybe a story, uh, around one of those where, you know, you were, you, you encountered a big surprise, like this was, this was not what I expected, or you got something out of it that you didn't, you didn't, you didn't think you would? So when I came into the CIO's office, I didn't actually know the situation around the data center exit. Hmm.

I, okay. Uh, I knew it existed, but I didn't know its current state. Um, You mean the one that you're tackling about getting by the end of this year? Yeah.

Okay. That one. Okay. That one, I didn't actually know what situation it was in.

Um, and I hadn't totally realized that the real answer was to build a whole new system. And so that was probably a, a, a challenge that I didn't totally expect, but it, it's fine. Um, it's fine. It's fine.

Um, I, I think there were other places where I went into, uh, services. I went into Tivoli services, so systems management services. And when I got there, the organization didn't quite know what to do with me. I mean, I was highly technical, but, but I was coming from an SS and d role.

And so they were like, well, she's probably not really technically, so we'll put her in the project management, product management area. And it took about a day and a half before they learned that that probably wasn't the right sentence. And it took a little bit, but not very long. And I was the leader of the TE team, technical team doing a set of things.

So that one was an interesting transition in and, and flop, um, because they, they knew me, but didn't know me well enough. Yeah. And so that was interesting. But, you know, I still did what I wanted to do.

That, that, that Problem sounds like it resolved itself relatively quickly. Yeah. Yeah. Very good.

Um, well, one more, one more question for you. Um, and it's, and it's the, uh, you know, the gene magic wand question. Um, if I could give you the magic wand, wave, the magic wand, if you could deliver one message to all those individual contributors out there, uh, and have them hear it and act on it, what would that, what would that one message be? That individual contributors really matter and that you need to lead, lead, mentor, and grow the next generation.

We have to be supportive of people and growing other people and lead by example. We need to help people grow and learn. And so don't get in the way. Give people an opportunity, help them along the way and take responsibility, but give credit so you know, when things go great.

Great. My team did wonderfully. If there's a problem, okay, I'll deal with it. Yeah.

So it, it really is important as a technical leader to make sure you are leading, but sharing and growing your community Wise words. Rosalyn, Thank you. Thanks for, uh, spending the time and sharing your thoughts. Happy to do it.