Leaf (Jessica) Roy

All right, let's get the show on the road.

So — oh, I've already gone one slide too far.

When I started at MassMutual — first started at MassMutual about five years ago — somebody asked me, "Leaf, are you an IC?" And I didn't know what that meant. So they explained: an individual contributor. And I still didn't know what that meant. I didn't know there was a term for it. They explained again: "you are not a people manager." Oh, okay. Right. Yes. That's me — I'm not a people manager. I'm a — whatever you said — individual contributor. Sure.

How many in the room are individual contributors? Or it would be if you were working, or have been in the past individual contributors. All right. That's a lot of the room.

So I'm going to be talking about how my journey as an IC prepared me for the monster challenge ahead — the big change that I was asked to lead. And managers in the room, I got you too. We're going to be talking about how my management supported me along the way, and I'll be introducing our monster challenge as I go around a corner in my path at MassMutual.

A few words about my employer. We help people secure their future and protect the ones they love. Founded a long time ago, about 11,000 people worldwide. Great place to work, industry leader, great place to be a customer. We're not going to read the slide, but I want to take you back a little further to where my journey actually starts.

I grew up in the 1980s, and I went to computer camp — that it was not outside. I was a little disappointed by that. It was not outside. I studied the BASIC programming language. Yeah, I'm getting some nods around the room. Yep.

One day I'm goofing around on the computer at home and I decide to see if I can edit a program that's already running on the computer. I bring up the code for the program, and it is all garbage characters. And I'm kind of crushed. I was hoping for BASIC. But I didn't know what compiled code was or anything like that — I was 10, 11, 12 years old.

But I see some hardcoded text that I remembered seeing on the screen of the program. And I thought, you know, if I edit this. And so I did. I saved it. I ran the program again, and yes, there was my edit. I found the wizard spell book — this is it. This is the magic incantations that make the computer go. Oh, this is amazing.

So I'm fascinated by that. However, my path turns out to be kind of a winding path, and I am an English major when I go to college. I wind up in computer networking after I graduate — like you do as an English major. And I get laid off in 2001 when the dot-com bubble bursts. But that lets me go back into computer programming and rediscover that love of that magic.

I, however, feel like I am behind everybody else. 'Cause it seems like everybody else has been coding continuously since they were 10 years old, or they are computer science majors, or both. And I don't have those things. So I'm often feeling like I'm the only person in the room who doesn't know something, and feel like I've been the only one. "Oh gosh, I'm the only one here who doesn't [know], I can't ask."

And I remember this one particular moment. I had been at my previous company about eight years, and I had just started — I was getting to be kind of an experienced developer, but I just started in this group with all the upper echelons of the developers at this company. Guys who had been there 15, 20 years. And me. And it's my first week in this group, and I'm trying to make a good impression. And the boss — we're in a staff meeting, and the boss talks about some technology that I'd never heard of. You could pick any three letters, it doesn't matter. And I just write it down — I'll look it up later. And one of the guys in the room raises his hand and says, "Excuse me, I'm not familiar with this technology that you're talking about. Could you say more about it? I've never heard of this."

Okay. So not only is he teaching me in that moment that it's okay for me to admit in front of my peers that I don't know something and ask — he's also showing me that it's important to model that for others, so that other people know that they're in a safe environment where they can ask questions. So that's really the moment where I decide that not knowing something and asking — admitting that you don't know and asking — beats knowing all the things.

I do go back and get my computer science undergraduate coursework done. I got a master's in software development. But I come to MassMutual in 2019, but I'm still an individual contributor. I start as a developer, have been asked several times by this time if I want to be a manager — just not interested, it's not for me. I like my code.

So I do get noticed for that ability to learn, that willingness to learn. And my tech lead comes to me and says, "How would you like to be our Kubernetes expert?" And I said, "Well, I have never heard of Kubernetes. But if you'll give me that opportunity and space to learn and to make some mistakes as I go, then yeah, let's do this."

And boy, that first month was rough. It really took a lot longer than I was expecting, and a lot longer than my boss was expecting. There were a lot of stumbles. But by the end of month two, I was not only getting our application up on Kubernetes, I was helping other teams get their applications up on Kubernetes.

So around this time, I get noticed again. I become tech lead of the team I'm on — that's still not a people manager position, it's like a principal developer role for us.

And I start to get more leadership coaching from my boss. He says, "Leaf, it's not called 'Tech Do.' It's called 'Tech Lead.' You don't have to do all of the things. You're supposed to lead the team to get the things done. You're supposed to lead the developers to get done what needs to be done."

And he starts giving me more context. He starts giving me more "this is how our application fits in with a larger ecosystem, and here's the history of why we're doing things the way that we're doing them." And — this was kind of weird — but he's protecting me less. I know that might sound strange, but as a developer, I was getting shielded from interference from the inevitable drama and bureaucracy that happens at any company. But as tech lead, I needed to know about those things, so that if there's some conflicts between person A and person B, and I'm going into a meeting with both of them, I don't step in it. So he's giving me much more context.

And I'm also starting to coach other people more. At this point, I'm really enjoying this. And I'm remembering when I was feeling like I was the only person in the room who knew something — and that's not hard to remember 'cause it's continued to this day, so I don't have to think back too far.

I actually started a presentation this way once. It was a presentation about our tech stack. I actually started it with, "you know that developers write code on laptops, and you know that users use web applications. And that somehow the code the developer writes becomes the application the user uses." And yeah, everybody in that room knew things — you know that developers write code, obviously. But if I started with that and I built up from there, then I didn't lose people along the way.

So really enjoying that. I pitch a role doing that to my boss — my then-boss, my current boss, and the big boss. That's the org chart triangle here. And they all like the idea. And we decide to call that "application architect." That's about two and a half years ago. That's still my title.

Around this — whoops, this is a slightly older version of my slides — around this time, there is a sad event at my company, unfortunately. A coworker of mine passes away. She was another tech lead, she was about my age. Her name was Judy. I did not know Judy super well. But the thing that really struck me about it when she passed was that everyone said the same thing about her. They all remembered her kindness. Yes, she was very technically skilled, but they remembered her warmth. They remembered how she would greet new employees and make them feel welcome. How she would always check in with you to see how you were doing — like, really how you were doing. That's what people remembered about her.

And I thought, "Leaf, how do you want to be remembered? How do you want to show up in the world?" And I have a note on my monitor still. It says this: "Is this how you want to show up?" Because the more I am working — you know, as developer I had my team that I worked with mostly, and as tech lead I had a couple teams that I worked with, and you know, the teams that my application integrated with. And as application architect, I have more teams that I'm working with. And the more people that you work with, the more you're likely to encounter some people who are a little more challenging to work with than others. But I keep that note on my monitor that says, "Is this how you want to show up?" Because I always want to show up with kindness. I might not be the ray of sunshine that Judy was, but I do always want to show up with kindness. And those connections are so important.

Another thing that I'm finding is really important is this ability to get from the 10,000-foot view level down to the ground. Now, I was a developer, so this is a familiar concept to me. I would get my requirements from my product owner or whoever, and I would figure out how those requirements look in the actual code. How do I actually do this in the real code? And as an application architect, it's not really all that different. I'm doing some cloud migrations. So now I'm getting my requirements from enterprise architecture or cloud engineering, and figuring out how does that look on a real dev team? And I, as an IC, I know what the realities are on the ground. I know what dev teams are facing on a day-to-day basis. I know what struggles they go through. I know what their pressures are and what their context is. So that ability to get from that 10,000-foot view down to the ground is really helpful as an application architect.

This is all going well for a while — about a year. And then one Friday, there's this meeting that has appeared on my calendar two o'clock on Friday with my boss, called "Observability Strategy." Now, I don't know a whole lot about observability at this point. I've heard the term, but I do know that I'm going to want to talk to my buddy Jay in enterprise architecture right after. So I schedule a meeting with Jay for immediately after that.

And I go into the meeting with my boss, and he says, "We would like you to be in charge of observability strategy for the entire technical organization." Okay. Developer, tech lead, application architect — the entire technical organization is several thousand people at my company. What? And I'm down here on the org chart.

Uh, okay, boss, but sure. Yeah. And I hardly know what observability is. Sure. Give me that opportunity, give me the space to make mistakes — we'll do this. I go into my meeting with Jay. "Jay, what did I get myself into?" And he says, "Well, you're not writing the observability strategy, 'cause I already wrote it. So you're implementing it." And I said, "Okay, that's that 10,000-foot view down to the ground thing again. I can do that. I got this, I got this."

But boy, yeah — down here on the org chart, I'm feeling like my influence is kind of limited.

So I start introducing myself to people. I go for dev team managers, because a lot of the developers know me already, but the dev team managers — not many of them do. So I get my elevator speech ready. "Hi, I'm Leaf. I'm a developer-turned-architect. I work in Web Architecture and Engineering under Terra." So now you know who I am and what I do, where I sit in the organization. 'Cause everybody knows Terra. And I am working on this thing called observability. Not sure if you're familiar with that, but it's like application logging and monitoring — except kind of going beyond that, to get more insight into your application from telemetry. I'd love to talk with you about what you and your team do, talk about what my team does and see if we can be of service to you, and get your thoughts on this observability stuff.

So now I've explained what observability is, in case you didn't know — I want people to not feel bad if they also don't know what that term is. And I've offered to listen and I've offered to help.

So I'm doing this. I'm shaking hands, I'm meeting all kinds of people, and I'm meeting a lot of folks from enterprise architecture. And it turns out, a couple months into this, that they're having this big meeting in our Springfield, Massachusetts office. And they kindly invite me to go to lunch with them after the meeting. I'm not in EA, so I'm not in this meeting, but they're nice to invite me to lunch with them. So I get to actually meet some of these people in person. Very exciting.

And I show up at the conference room about the same time that pizza's due. And the first thing I notice is that conference room is about a million degrees. The second thing I notice is that I seem to be the only one feeling that. Awkward. So I'm sweating buckets and meeting enterprise architecture people and shaking hands and "hi, I am Leaf and I blah, blah, blah." And they start asking me questions: "Leaf, this observability — is this for all applications? Is this for cloud applications? Or what about on-prem applications? Also, is this for DevOps teams, or how about not-DevOps teams? Is this — what about infrastructure observability? What about security? What about data science? What about AI? It's everything."

So many questions all at once, that everybody says, "the most important thing about observability is blank" — and they all have a different blank that they fill it in with. And I'm freaking out. And I'm like, listen, everybody has a horse in this race. Okay, I'm just trying to figure out where all the horses even are on the field. I'm just trying to figure out what all the horses even are.

So I go home that night and the light bulb comes on for me. I'm like, wait a minute — I don't have to run every horse on this field. I'm supposed to choose the horses. I don't have to do every single thing that everybody tells me is important about observability.

My management — this is weird for me as an IC — my management is turning to me as a subject matter expert to say, "Leaf, what direction should we be going?" And usually management hands you the direction, as an IC. I see this — go forth in this direction. But they actually need me to narrow this down for them, because they don't know enough about this. So I say, okay, hold on. You chose me for this. What my area of expertise is, is application. So we're going to focus on application observability. We're going to start there. Somebody else can take care of infrastructure observability, security observability, all the rest.

So here I am as an IC, facing my monster. I'm learning as much as I can about observability as fast as I can — reading the Observability Engineering book, shout out to the Honeycomb folks. And I'm coaching others, because there's a variety of knowledge about observability out there.

I am remembering that it's about those connections, and remembering that it's about how you show up — and, you know, using my elevator speech. And I'm choosing my horses and getting to that ground level, because my management is asking me not just "what are you going to do, and what's your long-term roadmap, and what's your vision for done?" What does good look like? That's the phrase I'm looking for. What does good look like? They're also asking me, "What are you getting done this month? What did you get done this week?" So I need to have both the short-term thinking and the long-term thinking.

And managers are still supporting me. I'm getting that opportunity to learn and the space to not always have green checkmarks at the end of every single week — or at least we plan for it to be a discoveries week, and we learn some things. And yeah, we green-checkered.

And they're giving me different leadership coaching this time. They're now teaching me — I'm working with more senior-level folks. So they're teaching me how to interact with senior leaders. Senior leaders need things in sound bites a little bit more. And they need things more like — they've got to allocate the resources. They want to know real quick: how do I allocate resources effectively? Where should I be devoting my people, my money, my time?

And I'm getting that context now. It's more about what have we done with observability in the past, and what else is going on for observability in the company, and why is this happening now? Why is this important now for observability?

But is observability the real monster for me?

One day I'm on a call with Jay from enterprise architecture — you remember Jay, my EA buddy. And there's some piece of code that needs to be done for observability, and it sounds like it's coming my way. And I just say, "Jay, I just don't want to code anymore." I can't believe these words came out of my mouth. Me, "I don't want to code." He says, "So don't code anymore."

Really? Okay. Coding for me has been my calling card. This is like 20 [years]. I can go into a room and say, "I've been a developer for 20 years. I'm an application architect, I was a tech lead, a Kubernetes expert, blah, blah, master's in software development." That's my credentials. And I'm going to give that up — to work with people. And I'm enjoying it.

But yeah, as it turns out, the more you're working at that bigger scale, the more it is about working with people and the less it is about the hands on keyboard. Yeah, you have to have that technical knowledge too — that's how people trust me. They know I've got that background. But it's more about working with people than I expected.

So here's the help I need. This was my journey, just one person. Tell me about your journey. Love to hear it, whether you're an IC or a people manager. Share with me your tips on tackling big change.

And you might say, "Hey, Leaf, how's observability going?" About that. My work on the observability stuff got me noticed — that whole 10,000-foot down to the ground, and the connections, and all that long-term and short-term plan. It got me noticed again, and I got pulled off of the observability stuff. And I am now software development lifecycle — SDLC — practice owner. Whatever that means. Bigger scope. So if you know anything about SDLC practice ownership, if you have a similar role at your organization — anything that you'd like to share with me, any tips that you'd like to share with me about that, are definitely welcome also.