Mindful Engineering with Po Linn Chia (Podcast & Transcript)

“The industry as a whole has become so good about wellness weeks or providing more mental health resources. But in reality, when you're living with [a mental health condition], five free therapy sessions or a week off at the end of the year during Christmas, it's like catching up on an enormous sleep debt.

And if you're already well-managed, that's great, but sometimes stuff just builds up to a point where you need a long period of time to recalibrate, or to improve the care you're receiving and focus on that, or just to know if it's the job that's burning you out.” - Po Linn Chia

Po Linn (Fo) Chia is a Principal Software Engineer at Mindbody/Classpass, working primarily in the intersection of backend and DevOps. She graduated university with a degree in Japanese history, but pivoted to doing a coding bootcamp and the rest is history.

In this episode we discuss:

• Fo’s journey from Humanities major to Staff Engineer

• The importance of mentorship and having a good manager

• Handling stress and mental health in the workplace

• The best way to build new skills

• Advice she’d give her younger self
  

Transcript has been edited for clarity.

Karen Ko: Hey there. Welcome to Engineer Your Career, a podcast brought to you by WEST, a learning community empowering women technologists through mentorship. Join us as we hear from inspiring women tech leaders who are challenging stereotypes and paving the way for future generations. We hope their career journeys inspire you with new ideas to engineer your career. Let's get started.

Heidi Williams: Hello, everybody. Welcome to our latest episode of Engineer Your Career. I'm Heidi, and I'm excited to introduce our guest, Po Linn Chia, who also goes by Fo. She is a principal software engineer at Mindbody ClassPass, working primarily in the intersection of backend and DevOps. She graduated university with a degree in Japanese history, but pivoted to doing a coding bootcamp and the rest is history, no pun intended or maybe fully intended. We shall see. So welcome, Fo. So nice to have you here.

Po Linn Chia (Fo): Hi, so nice to be here. Thank you for having me.

Heidi: Awesome, awesome. Well, tell me a little bit more about what you do today at Mindbody ClassPass.

Fo: Yeah, like I said in the intro, I'm a principal engineer for the ClassPass arm of Mindbody. I sit on the backend team, but I am what they call a guild lead within the org, which means I don't sit with a team that works on product or features. I'm sort of a technical excellence team, and I get to work on kind of foundational backend projects, which is really cool.

We're not a young startup anymore. We're quite mature, and we've been acquired, obviously, by a very mature organization. So it's a really nice place to be because we're maturing the ecosystem, and you can't have people working on nothing but feature work all the time, where things start to fall over in the backend. I like to call myself a janitor in a good way. I go around the back, and I sweep things up, and I make sure everything is clean. So that's what I do on the day-to-day.

Heidi: I love that, and I feel like there's definitely something so rewarding about that. I feel I've heard people talk before about how rewarding it is to delete a bunch of old code or refactor something and whatnot. Maybe a quick question. Does the janitorial instinct show up in your personal life at all? Do you have a super clean house, or do you separate these things? [laughter]

Fo: No, I think I use all of my energy to clean things up at work. I think I have a very different brain when I'm at home versus when I'm at work. Work keeps me really organized, and at home I'm like, nah, I don't need to do that anymore. But yeah, I think it's a trait a lot of principals have. Another principal at ClassPass is very well known for deleting code in a good way. So yeah.

Heidi: That's awesome. Yeah, I think too, I imagine cleaning things up when you're working with a larger team has an impact of all the people who get to work in that code, and it's more rewarding than maybe anything you might do just for yourself. So I love that.

Well, you have a very interesting story of how you actually got into the industry, so do you mind sharing us a little bit more about how you got started?

Fo: Yeah. Technically, with actual industry experience, I actually started with a code bootcamp. I guess that would've been in 2013, 2014, so kind of the era where code bootcamps were really the in thing and starting to get really common.

So I hopped into that, and very fortunately, the person who ran the coding bootcamp had an in, he was an ex-employee of the place I ended up getting my first job at. So they made it easier for bootcamp graduates to interview there, and I managed to trick them into hiring me, and the rest is history.

But more practically, I guess a lot of times people ask me, how the heck did you go from classical Japanese to coding? Fortunately, it's not that different. When you learn a language, it's not that different from a programming language.

But I guess my cheat code is I had two older brothers, both of them became engineers, so I learned a lot of just kind of like how a subnet works, what's a router, here play some video games.

So I was kind of coding Angelfire websites when I was eight or nine. I know you worked at Macromedia, but our schools were also really big about enabling. As I was at a girls' school and we had a really great computer lab session, so I got to use the Macromedia suite and code around in Dreamweaver, and that was amazing, right? You could do this in a WYSIWYG editor, but then you could see the code, and you could learn how to script and to code a little bit, which made it a lot less intimidating.

And then I liked gaming, so I tried to learn C++ so that I could code a Neverwinter Nights module, and that was fun too.

Then, during university, I was pretty quick in my major, so I had some free time during senior year, and I used that to pick a couple of CS or CS-related classes.

We did a data structures for non-computer science majors, and there's a funny story where he was an awesome professor, I struggle to remember his name, but super technical guy, and it wasn't kind of physics for poets. It was really pretty deep, but he had to catch you up on a lot of stuff. How does Git work? Or he was really keen on, you're not going to use a GUI, everything's going to be Vim and you're going to upload your assignments by Git pushing to a server. So it was great.

It was a difficult class, but at some point there's maybe be 15 of us. Professors like, all right, I'm going to guess everybody's majors. So who here is in financial operations, and a bunch of people raise their hands, and who here is from a pure science that needs this for research? A couple people raise their hands, and he's starting to wonder why me and a friend aren't raising our hands, and he's like... Industrial operations? And one person, and it's down to just the two of us, and he's like, I give up. I've gone through every non-CS technical major, and my friend raises his hand, he's philosophy, and I'm what we call ELAC, easy Asian languages and cultures, and he's like, what are you guys doing here? But I mean, it's great. So I did that, and I did GIS, and that actually fed into a bunch of internships I did before my bootcamp. I was doing kind of GIS coding. Yeah.

Heidi: That's awesome. Well, it seems like you've been, you were soaking in the world of computer science and programming for a long time, maybe before it felt like maybe it was a career opportunity, but that's really cool.

When you were studying, did you think that you probably would do something with Japanese or with history, or were you pretty sure that you would likely want to go into the program industry somehow?

Fo: I think I was a really clueless university student. I kind of stumbled into Japanese. It was sort of a long-time love. I used to watch a lot of anime, I guess I still do. And I just was like, I want to learn this language.

Went to uni, kind of intending to study economics, but we had an excellent East Asian department, and I think I just really like working around people who love what they work on, and I just kind of got suckered in. And then towards the end of senior year, I was like, oh, it's academia or politics or teaching abroad, and I'm not sure I want to go into academia. So that's where I kind of was like, what else do I sort of enjoy a little bit? And kind went that way. I wasn't a fan of going pure hard CS and doing OS or whatnot, but the idea of doing something that was really constructive, where you learn all the time, which I think everyone in this industry will agree we're learning all the time, was very appealing.

Heidi: Yeah, I remember, I feel like I also got hooked in that first moment where you're type, type, type, and then something works and you can see it, and you'd be like, oh, look at that. I made that thing.

And then also to your point of feeling like there's always something new to learn. It's an ever-evolving field and everything. So yeah, those definitely hooked me early on as well, so that's really cool.

Well, when you first got into your first role, you said you found your first role through the book camp instructor and whatnot. What was something that was surprising in that first role?

Fo: I think how far you can go if you have people who are looking out for you and believe in you. So I got hired, I think, very typical for a code schooler. I got hired to do front-end development, but I had an awesome manager who continues to sort of be a older brother, friend figure, and my manager, I think it was my second year, he was like, go lead this project. We want to convert our VCS system from SVN to Git.

And looking back, that's a slightly insane thing to ask second-year engineer to do for the whole company. We were not a small shop, we were probably, I want to say a hundred to 200 engineers, so that was wild.

But it taught me very early on how to do these non-feature work projects and coordination, which I think is a big part of what I do now, project coordination, and learning how to write good docs, and making sure that adoption, oh my goodness, adoption is so hard.

And that was a big, I think, leap of faith that my manager did for me. And I think I've had a lot of big leap of faiths from my managers ever since. And I think coming into the industry, I thought it would be more like you do something for a long time and you continue to do the same thing. A lot of angst about, am I going to be a front-end engineer forever? How am I going to learn the other stuff?

But in reality, once you're in an organization, I think... I want to say pretty easy, but it is technically sort of easy to branch out, and that surprised me that they let me do that.

Heidi: Yeah, yeah, that's so interesting. I think you're right that once someone knows you and can see maybe your interests or that you're eager to learn or you're quick to learn or that you sort of managed to figure whatever out that's thrown at you, you're right. That goes further than anything you can put on your resume. They're willing to take it on you and know how to support you and whatnot. And it's funny, my first job, I was there for 17 years, and people think that's crazy, but it is the kind of thing when the company's big enough, you get so many opportunities to learn, and you don't have to interview to do it, you just get to do it. So I can see, and you were there for quite a while, your first role, weren't you?

Fo: I was there for six years, yeah.

Heidi: Yeah, that's awesome. And we were talking earlier about you've had a very fast learning path and learning curve, and I bet those first six years sort of meant a lot in terms of being able to really explore.

Fo: Yeah. We were kind of an end-to-end shop, and I think if I had just jumped jobs, which was very common, I'm sure it's still very common at the two-year mark, I would probably just have been a better-paid frontend engineer, but not necessarily.... You'd have to start from the bottom. Every job just kind of regain your street cred, and people have to trust you before they invite you onto the more complex, interesting projects.

So in a lot of ways, it did feel like I stalled out my career, and it probably stalled out my compensation, but in terms of learning, it was incredible. You can get a lot done when you have street credit within a big org.

Heidi: Yeah, for sure, for sure. I dunno why that reminds me. I was talking with some young engineer, maybe two years out of college, and they had decided that they were going to leave, and I took them for a walk, was sort of trying to ask, What can we do to get you to stay, and what are you looking for? And they said, I think I've learned all I can learn here. And I thought, you know what? You're crazy, and good luck.

Fo: Yeah. Oh man.

Heidi: What a lost opportunity.

Fo: Like at least do a rotation onto a different department. That's wild.

Heidi: I was really surprised, and they were a front-end engineer, and I really thought, okay, if that's really what you think, then good luck. You got to be more open to new ideas than that.

Fo: I kind of sympathize because in the first two years we were doing, oh man, what was that C# front-end templating? I can't remember what the name of that framework was, but I did a lot of that every day as a front-end engineer, you were kind of just tweaking HTML or doing some JavaScript, and it got really, really boring.

So I sort of empathize, but I think it's hard to pull back and realize, oh wow, there's a whole backend system that supports this, and it's not locked away in this black box. You've got to understand that, and you could think you're like, you've read the manual end to end on React and view or whatever, but there's a big world out there.

Heidi: Yeah, and it all continues to evolve. And so what ended up leading to you deciding to leave and look for your second job, which I think is where you are now?

Fo: Yeah, I don't want to say I learned everything there was to learn. I certainly, I don't think I touched a database the entire time I was there, but I think it was a lot of the same feeling of I've reached a kind of glass wall or artificial ceiling. Not in terms of people treating me as like, oh, we don't trust you or whatever. But I was there a long time and it was an older shop. They were already, when I was there, they were maybe 20 years old. We did a lot of white label websites for quotes and research trading stock companies.

And so it was an older C# stack, and I mean old life half of the websites were still running on ASP, and we were doing a lot of modernization efforts, so uplifting stuff onto Docker and into containers at the beginning.

And so that was really exciting, I think around year four, because it felt like I was plugged into what was going on in the rest of the industry, but eventually we stalled out because that's really expensive work. And putting a Microsoft stack into a Docker container back then was nearly impossible. One of the containers was 10 gigabytes or something like that.

And that was kind of the work is we were fighting every day to do these things, and we had very strict requirements of being on-prem. And I love that company. They're family to me. They really gave me so many opportunities. I don't think I ever really ever faced discrimination there. Quite the opposite.

But by the end, the team I was working with was kind of the architecture team, and I think of the eight or 10 of us as the only female in the room, I was younger than everyone by at least seven years, and on average probably 15. And I kind of didn't make a lot of friends. I made more friends after I left the company when they weren't my peers or bosses anymore, than I did when I was there.

So kind of socially, it was getting to the point where it's like I want to go learn what the cloud is doing, and I want to go work at a place that's a bit more diverse and it moves a bit faster. Because we were often sitting there and being like, what can we do to convince people to let us burn this down?

And then I think, speaking realistically, when I joined, I think my first paycheck was on a $65,000 a year salary or something like that. And there's a reason why people hop every two years, because the easiest way to get paid is to apply for your job elsewhere. And they were relatively really good to me, but our salaries as a whole at the company lagged the industry by huge amount. And I was getting paid more than my managers at some point, which is really wild.

And so when the opportunity came, and I was sort of itchy to move, I knew there was a lot I still had to learn, but it was getting harder and harder to learn those things for lack of opportunity in terms of it coming up as a project. So when ClassPass came and called, I was like, okay, why not? Let's just give it a try.

Heidi: Well, good for you. And I do feel like the whole conversation around salary awareness has definitely changed over the years, and I think people are more conversant about it. It doesn't mean that it's comfortable to talk about, but I do think that sometimes you're just in an environment where you are stuck.

And I do remember one of the early wins from the WEST program, which sponsors Engineer Your Career. We had a mentee who found out from her mentor that she was probably being paid $40,000 less than her peers in the industry. And so, well, you can either go negotiate for a raise or you can quit and go work somewhere else, and a gap that big is hard to make up within your organization, but it felt like until you talk about it, you don't know. So good for you for exploring and figuring that out, and as part of the reason, not the whole reason, certainly, but yeah. Well, yeah. So thanks for sharing.

It sounds like you've had a great time since you've been at ClassPass. What would you say has been a highlight of your career so far?

Fo: Yeah, at my old shop, we have so many names, so I'm going to call them by their original name, which is Wall Street on Demand. At some point, they were faxing people financial data. That's how old that company is. They've been acquired a thousand times.

But in the course of making sure they weren't an ancient dinosaur all the time, we did a big data center migration, and it's super nerdy, especially since I was still mostly on the front end at that time. But data center migrations are an all-in effort. Everybody is working on it. Every last person, you've got five people working on product work, everyone is making sure that things don't fall over when you get onto the new DCs.

And it was probably the scariest thing I'd done up until then. I mean, I wasn't doing it, I was just helping. But it was such a great career boost because you went from a front-end engineer to, Hey, we've got to update all of these backend libraries to work on the infrastructure or, here's how the infrastructure works.

It's the first time I got to look at a load balancer config or learn why certain ports needed to be open or it was down to at some point ethernet adapters. We were on the wrong one. It was really everything. And I got exposed to the ops team, actually. That was my first break into infrastructure and ops, and I think that's where I've sort of specialized ever since is having one foot in ops and one foot in product engineering. And it's such a useful bridge that very few people do.

And so that data center migration, I don't think I would've be where I am and it's probably the only time I would say it's very fun to be in the office at 2:00 AM lying on the carpet while people play—We had, somebody had a data center migration Spotify playlist that we shared with one another so that we could play the same music. It was such a great team effort, a wonderful memory.

Heidi: That's awesome. It's funny when I ask people about the highlight of their career, very often it is a team effort where you felt like you sort of persevered against all odds and achieved it together and really bonded over it. There's a little bit of overcoming something big to come out the other side. I love that. Yeah, that's so fantastic. I feel like I'm now at a point where I couldn't stay up until 2:00 AM in the office anymore, but I do remember that.

Fo: That's why you have minions.

Heidi: Yeah, I'll leave it to the next generation to do that.

Fo: Page me.

Heidi: That is fantastic. Exactly, exactly. I love it. Well, how about— speaking of overcoming challenges or maybe something that was sort of scary or risky for you, is there something that stands out as something that you felt like was the scariest thing or riskiest thing you ever did in your career?

Fo: Yeah, I think that was last year. I was really, really burnt out, and I asked for a month-long sabbatical, which to me seemed like a crazy ask. I've only been at ClassPass, I think this is my fourth year, it would be my fourth year in April.

So it was really scary, but something that I think I needed to do, my mental health, I've got a chronic mental health disorder, and on the day-to-day I'm pretty good at managing it. I talk to my managers about it. We are prepared, but it's super hard to manage. And I think it's something that is not talked about enough.

The industry as a whole has become so good about wellness weeks or providing more mental health resources. But in reality, when you're living with it, five free therapy sessions or a week off at the end of the year during Christmas, it's like catching up on an enormous sleep debt.

And if you're already well-managed, that's great, but sometimes stuff just builds up to a point where you need a long period of time to recalibrate, or to improve the care you're receiving and focus on that, or just to know if it's the job that's burning you out.

And so that was really scary. I don't think in my entire career, which was almost 10 years at that point, I'd taken a break longer than maybe two or three weeks. And I work with a—I think programmers like working. I know close friends of mine don't even take a week off between jobs, and that's really wild.

So I was sort of terrified, but at some point, I was like, after work every day, I was crying. I was like, this is not healthy. And my team was so supportive at the end of the day, but it had built up into such a scary thing in my brain.

I didn't want to look like I was flaking or abusing time off or giving the impression that because you're working with a chronic condition, you're unreliable. I've been really lucky and I think if there was a theme in my career, it's in some ways making sure "choosing your manager" is the most important thing you can do for yourself. So I've been lucky to avoid stigma, but you want to set an example, especially in a senior role. So that was scary. It all ended well, but I think I'm really lucky to work at the org that I do that they let me do that.

Heidi: Yeah, amazing. Thank you for sharing that story. I think it is something, you're right, folks don't talk about enough. And you're right, we sort of talk about it at the high level of wellness and taking a day in May to celebrate or talk about it or normalize it or whatever, and you're right that it is, starting with just even a big moment of trust to engage with your manager early on and say, here's the deal. Sometimes I need some grace. I need some space. I need some empathy, and whatnot.

So good for you for advocating for yourself and hopefully, I know it is hard to manage. You never know maybe when something's going to happen or when you need that space or whatnot, but also I applaud you as a leader to show folks that it's okay if you need time.

Fo: Yeah. And it's really cool, because I can come out into the world and be like, ClassPass really talks the talk. We're all about having a good work-life balance. And we're a company that's about helping people get away from screens and look after their health, and enabling both consumers and providers to live a healthier life. And sometimes that can sound like lip service. So to know that they really do look after their employees and let us do this and not just take a day off and feel better afterwards, after you get some sleep, is really cool.

Heidi: Yeah, I love that. And if you don't mind my asking, I'm sort of curious too, whether the month felt like just a reset or whether it felt like a moment of reflection to make changes when you went back, so that things maybe felt more sustainable or less peaks and valleys.

Fo: A little bit of column A, a little bit of column B. I think in the long scheme of things, a month is really a short period of time, especially... you can get overloaded, right? You're like, I just want to rest. I need to fix my burnout. I want to review how I'm managing my condition. I also want to read a couple of books and just do something normal.

I think a lot of people asked me, oh, are you going to travel somewhere or do something? I was like, mostly I'm going to look after myself. Sometimes that means traveling to see friends and repair your social connections. I'm very far away from a lot of my friends. But it felt really short, and I think I knew it felt really short. In an ideal world, I think I would just have taken a career break altogether and given it as much time as you need to give it.

But I knew going in that there was a maximum number of things I could do in the month. And so I tried to structure around that, okay, I'm going to take the month to really chill, find out my baselines, and if my baselines feel off from what I thought they were without the stress of just that daily work and requirements, then I know how I want to go on and kind of seek better selfcare or how I want to approach stuff at work.

And obviously nobody wants you to go back to work and then get burnt out again in a year's time. So I kind of went back in with both, sort of this is just the beginning of a bigger thing, but also like, huh, I'm going to change the way I do the work to make it more sustainable.

And realizing people are out there solving really big problems with software that are really scary, like people working in healthcare tech. We obviously are important to our customers, but it's not rocket science. If we go down for an extra 1% this month, nobody is, I mean, people's livelihoods are impacted, no question. But people's lives are not impacted. So, taking a chill pill on that one.

Heidi: Well, thank you for sharing all of that. I feel like there's definitely some lessons we can all learn about that, about advocating for ourselves, taking a meaningful break, resetting how we have a relationship with our work, and we call it work-life balance or harmony or whatever, whether it's the short-term or the long-term and whatnot.

The other thing I wanted to ask about a little bit, is have there been some sort of career obstacles that you've had to overcome or particular challenges that you'd like to share?

Fo: Yeah, I think I preface it with every company I've ever worked with have been so supportive of my career path. I really wouldn't be here today, I think, without those folks in my engineering orgs. I think I've had an absurd progression of something like, on average, I got promoted once every 1.5 years.

So it's not that people, I'm not here to spill that tea, but I think there's the engineering org and then inevitably there's an HR org or P&C org that holds the purse strings and the policy. And the bigger your company is, the more policies there are and the stricter they become about enforcing those policies.

So I guess if there's a piece of advice I would give, it's to folks who are early to mid-career. I mean, I'm mid-career. If you progress fast and you kind of break the curve, the company can sometimes not be able to handle you.

So at some point, I was technically not even a senior yet, but I was doing senior plus, what we called architect work, junior architect, but architect work. And because I hadn't been in the promotion cycle, because you were not supposed to be promoted.... You just weren't supposed to be promoted more than once every two years. My boss was like, this is nuts. Let's get you the title you deserve. You're doing the work already. I'm going to find a way to make it happen.

And he went to HR and he's like, how do we make this happen? And HR came back with, okay, she has to apply for the job, which I thought was kind of fair. So they did the whole thing, job posting, whatnot. I applied, it was very odd submitting my resume to my own peers and bosses who I sat next to and who had seen me work. And you had to do an interview and it was just the strangest thing in the world to apply for your own job. And they gave it to me.

And so technically I was going to, by applying to this internal position, get to do what we call the double jump up two career levels. And so we did it. Everyone was happy. And then when the call came through from HR to go see them in the office, they were like, here's the good news. We're promoting you to senior.

And part of it was trying to get me, like you said, when you have a big gap in compensation, you kind of have to do something spectacular to fix that gap. And on paper, it was an absurd "pay raise," like 20% or whatnot, but it was nowhere near what a junior architect would be earning.

And so I just sat there, and I was like, what, you just made us go through this three-month process for me to apply for junior architect, and now you're trying to tell me this is good news that I'm a senior? And they were like, oh, don't worry. We're sure you'll get promoted in the next review cycle because you're already doing the work, if that's true. Because they had no idea. They were just HR. They had no idea what I did in engineering.

And I remember just nodding, and I closed the door to the room, and I just went into the bathroom, which was right across the hall, and I had a mini breakdown. I was sobbing. I come out, and my manager is there, and he's like, what happened? And this is my favorite memory, is my manager, who's basically my dad at this point. He's seen me through my career. He just storms into HR, and I just hear yelling.

And I mean, I felt really bad, but I also felt really good. I was like, everyone tried their best. It wasn't that they didn't want to do this for me, but sometimes you just run into, you were mentioning earlier, a wall with your organization that you can't cross with your management team. And I think that was the start of me thinking money isn't everything. The team's really important, and I had a great, great team, but at some point, you're like, this is wild. I'm not getting what I should be getting, and this is going to be the rest of my career here is running into these insurmountable HR obstacles.

So yeah, like you said, it's either they change for you or you kind of have to change the circumstances at that point. And, yeah.

Heidi: Let's take a quick break to hear from our sponsor.

Karen: Are you ready to take control of your career? WEST can help. The WEST Career Accelerator is a six-month learning program that combines one-on-one mentorship and group-based career coaching to help women gain clarity, save time, and define success on their own terms. We're here to help you create a path towards the career you'll love. Check out how WEST can help you succeed at joinwest.org.

Heidi: And now back to our discussion.

Wow. Yeah, that's a tough one. And I can imagine how— three months to then, I mean, you're right, that is wild to go through something for three months and then sort of have it turn out to just be a regular promotion.

Fo: You know, to wait for them to make the package. And if they had just come out and said she can't double jump, we would've been sad, but at least we would've saved ourselves effort.

Heidi: Totally. Oh my gosh. Yeah, that's crazy. Well, so I guess we haven't had a chance to really dig in a little bit more into what your current role is.

Actually, just for folks who are listening to the podcast, one of Fo's coworkers actually recommended her for the podcast. So we reached out and connected. And she said that she really admired you as a leader and felt like you are really amazing at what you do. So, can you tell me a little bit more about your current role? What does a typical day or week look like for you?

Fo: Yeah, I have to really thank Brie for nominating me for this. I'm... on paper, I am not a people manager, and I don't think I would like to go there anytime soon. So I'm more of a technical leader.

So my day-to-day role is, my team is really small because we don't have a lot of resources to have a technical excellence team that's large. We are a super lean org. But I sit on a team that is sort of, what do we need to make sure that our backend infrastructure and our backend teams are enabled, essentially, enabled, supported, and that we are in a place to serve our biggest technical goals, which, probably like every company, are the stability, uptime, and maintainability and scalability of the company.

We're hoping to grow. So we're in this really lucky position where, every year in January, we have what's called a high season because people love to make New Year's resolutions and start to work out.

Heidi: I love that.

Fo: And our traffic stair-steps up, which is not something, I think, in a mature org you'll see, something like 20 to 30%, so your systems have to be ready on January the second to basically take that load.

And when you have feature teams that are so bent on fulfilling the product roadmap, which is obviously really important for growth, that kind of prep can lag or— you can't really ask people to code switch between today, I'm working on this feature, this API call needs to return the number of credits. And then suddenly you're like, what can you do to make your service more scalable?

So my team and my role is to do some of that stewardship for the technical excellence role. Some of it comes down to paperwork. So on a sort of every six-week basis, I sit down with the team and I'm like, okay, here are the pillars of what we're trying to achieve this cycle and this year, what are the big projects that we want to do?

So there's a lot of roadmap planning, a lot of leading from the behind.

I think that's why I use janitor is that our job is sort of service to the rest of the engineering team that we're supporting of helping prioritize what everyone wants prioritized. A bit like mind-reading in some ways. It's a little tough, but getting those things onto the roadmap and breaking it down and saying, okay, these are things that we do as a standalone team, but ultimately there's probably going to be impacts to the rest of the team, and how do we support them there and roll it out.

So a chunk of it is going to be doing that roadmap planning, talking with engineering leadership, working with them, corralling the other teams, getting people in the same room, going to those technical meetings, and then the rest of it is just doing the work that we've decided to do.

I have a rotating engineer that comes to my team, and within doing that work, it's helping those engineers. We try and rotate everyone that's working on the backend onto this team at some point. And you can get anyone from early career to higher-level career because it is supposed to be a stair step, a career booster to be like, you've never worked with infrastructure before, or you've never led a big technical project before. Here's your opportunity.

So I don't want to call it mentorship per se, because I'm not that high up in, I haven't been there that long, but I have seen some stuff and led some projects. So that kind of mentorship and project work.

And then finally, where often the team that comes into the knock slash, we call them nine one ones, the incidents. So I spent a lot of time being on fire duty because we're really well-positioned for it unless it's very specifically a problem with someone's feature. Very often, the big fires have some weird structural thing going on there, and I really like putting out fires. So we do a lot of that.

Heidi: That's awesome. I love that idea by the way of the rotation, and I've seen that pattern in a couple of places, and I just think it is so great to give people a broader understanding of kind of what's going on. And even you were sort of talking about a little earlier, there was a moment, this was a few years ago, but someone sort of noted that a lot of what you learn in college, there are so many sort of libraries and systems built for you. You don't actually need to know how to debug all the way down in the stack.

And so it's sort of a lost art unless you choose to go that way and get exposed to it. I love that you actually have a rotation where people can get exposed to the next level down in the stack and understand how things are put together. So that's really smart.

Fo: I like to think of it also as disaster recovery. I often like to say, what happens if somebody gets hit by a bus? The last thing we want is hero culture, I think, where there's one person in the org is a linchpin because they know, they've command B or F 10 or whatever into the implementation, and they're the only one who knows how that works. So if they go on leave or whatnot, I think part of why I was able to go on the sabbatical is I advocated really strongly for this team.

You can't have only a couple of people knowing how some of the nitty-gritty stuff works, because the nitty-gritty stuff holds up the risk of the system. And by having people rotate in, we spread that knowledge around, and they get the foot in through the door and they may not understand everything, but they're already a hundred percent more equipped to learn it. And it's also cool because it's really challenging to figure out how to run projects when you have an engineer that's not going to be there in six weeks. It's a very short rotation. So very cool, but also it's own very challenging, but very rewarding.

Heidi: Yeah, I love that. I love that. Yeah. Yeah. That's so cool. I'm sure I have so many more questions about that. Because I hear sometimes people don't want to rotate, like, oh, the cost for them to ramp up is not worth it. And so six weeks is a lot for them to ramp up, participate, and sort of know what they did so that the next person can rotate in. But that's fascinating that you're able to do it. That's really cool.

Fo: Yeah, it's a growth project for the whole company, I think, right? We're kind of pioneering this rotation system, and it'll probably evolve over the next couple of years. Maybe we'll realize that it's too short of a time or maybe we'll realize that we can do it efficiently, and we just need to size projects right. But yeah, it's fun. It's stressful, but it's fun to help do these things.

Heidi: I love it. I love it. So maybe just a few more questions. We've covered so much ground already, but maybe just one last thing. What do you like best about your role? Or maybe what do you least? You can answer either.

Fo: Oh, yeah, it's a good segue because those two things are the same thing. It's amazing to be given, basically, I don't say it's infinite, but it's pretty much infinite technical leash to run on, because I am here because they trust me to make the right decisions for the company. I wouldn't have been put in this position if they didn't think I could prioritize, but I could technically choose to work on nearly anything.

And that is really cool. You're not restricted by a product roadmap. You get to go learn and think about what is really good for everyone's dev experience and the resiliency of your engineering infrastructure, which is really cool. I get to work on things like, are we scalable? How are we meeting our SLA requirements? How do we even calculate our SLA requirements? How do we set up our telemetry? How do we budget for the telemetry? Because telemetry costs money.

So it's this real big buffet of anything you could do. Super fun, super, it keeps you engaged every single day. But it's also really hard, and it's something I'm still learning how to do, which is how do you focus, how do you do the tough stuff, which is getting it onto the technical roadmap, convincing your stakeholders. It's a lot of learning how to present ideas part more than reading the manual and sitting down to do it.

So that kind of work is really hard on the brain. You can only do so much of it before you burn out. Part of why I took that break is to realize I needed to do fewer things in order to do better things. So yeah, learning how to do that and doing that job in a sustainable way is the hardest part.

Heidi: Yeah. Yeah. I love it. Yeah, it's sort of one of those things where you sort of careful what you wish for. You have infinite—

Fo: Precisely.

Heidi: — freedom, and then the challenge is you have infinite freedom, right?

Fo: It's really fun to say, Hey, let's try this new library, or let's upgrade from dot net two to dot net four or whatever. And then realizing you've got to push that out to a hundred people on 45 teams, fix all their bugs because they're going to complain to you when something goes wrong. Factor in the fact that any one of these things could go down because of the big upgrade. And that's the sort of thing we think about every day. People probably think we're spoilsports. Why are we going to the latest JVM? I'm like, because double jumping three major versions could be really bad.

Heidi: I hear you. Oh my gosh. Well, I have to ask you a question because I feel like every eng org has struggled with this when you have a centralized team doing this. Do you believe in creating the pattern and convincing everyone to replicate it, or doing all the work in their code bases for them, or somewhere like you do one project to show the example, and then have everybody replicate? What's your preferred?

Fo: It's always a spectrum. Teams and orgs will always go between centralized and distributed. There's no perfect answer, I think. But you have to have a team or some leadership to say, in this case, we're going to do that.

And I think there are some things where just doing it for people makes sense because they're not really going to learn anything by it. So if I'm updating a lib, I'm not going to distribute that to 50 teams a lot of the times, because it's just like a string update. So it doesn't hurt me to spend a few hours of my day opening all of those.

But if we're going to do something like a major framework upgrade or whatnot, they're going to have to learn how to do that. It's really important that they understand and know how to make that change. And they're the project experts. So if it's a change where you could end up in bugs that only a certain team will know how to solve, they are the best equipped to do that. And the only thing that you can do as the centralized team is to make sure that you've tested it on a beta group as well as you could test it. You have it documented. You've got the soft stuff set up. You've got the project channel. You've got the check-in meetings. You've got the temp checks. You've got the pull this cord as a screen test if this looks terribly wrong, and making sure people do that.

So I think it's really dependent on the scope of what you're doing, and at some point, it's going to be unhealthy to do everything centralized, just as it's going to be very inefficient and unhealthy to do everything distributed.

Heidi: Yeah. Yeah. I love that. That's fantastic. I feel like that soundbite right there would love for everyone to hear it. That's fantastic. Awesome.

So let's see. I guess along the way, I feel like I kind of already know the answer from this, maybe a lot of curiosity on your part, but how have you acquired all of these technical skills and experience to help you be successful in your current role? Which, as you said, is pretty broad.

Fo: Shameless volunteering every time. I think when you join an org, you see pretty quickly who the people are that are working on the big projects or the teams. Sometimes, oftentimes, the teams are the people where you're going to learn something new, or they're working on something cool, or they're working on something that's a gap for you.

And so once you've established that you can be trusted to wander off the beaten path. Because, I mean, at the end of the day, it's true that some people will wander off the beaten path and then go down this rabbit hole. So you kind of have spent some time showing your leadership that you can do it and come back and have gone off for a reason. And I think I'm good at doing that, at advocating for, this detour is worth doing, or letting me go detour and learn from this team is going to pay dividends.

So I volunteer a lot. Or like I said, I'm in a lot of fire.... Even early on in my career, I loved hanging out in incidents. You learn so much during incidents, that's where you're going to learn the archeology of all the proprietary tools and whatnot.

And there's always big projects like data center migration. At some point, somebody's going to do a database upgrade, and you might never have worked with database upgrades before, but if you volunteer to help test it. You're going to learn how to test databases along the way. So I am not an engineer's engineer in the sense that there are engineers whose pride and joy and joy in life is to know C++ from the ground up. They're on Linus mailing lists, learning how the kernel works. I am not that engineer.

I always play a bard in Dungeons and Dragons, kind of a jack of all trades, master of none. And so, just shamelessly volunteering, kind of try and learn the landscape as far as possible. And I think that's often.

And so I wouldn't say that I'm surface-level. I want to say I'm probably at the mid-level of a lot of things. I am not the person to be like, where did the pointer go? Why are we leaking memory for something proprietary? But I will absolutely be the person who's like, I've gone to the GitHub source repo of a library that's seven things deep and found the bug over there that I'm now asking them to fix.

And so having that curiosity, I think, and just a little bit of shamelessness, I've met a lot of junior engineers who are like, Fo, I can't do this because it's not on my product roadmap. And I'm like, just do it, man. I will advocate to your manager for you. Because this is going to improve you as an engineer to go figure out why this thing isn't working, and not just throw it over the wall to the other team or to the open source maintainer.

Heidi: I love that.

Fo: So yeah, shameless volunteering.

Heidi: I love it. I love it. That's fantastic. Very cool.

And so, beyond technical skills, what are some other skills you rely on in your role?

Fo: Oh, MS Paint. I think I'm most famous for MS Paint at all of my jobs. I kind of always joke that being a humanities major is the ultimate secret weapon in my career. It's very facetious. I often say very self-deprecatingly is like, why am I good at my jobs? Because I speak English.

But I think a lot of the training I had in university was, we ingested a huge amount of material. We would have hundreds of pages of reading every day, and you had to figure out how to boil that down. And I'm sure, people say this all the time, right? The best way to learn your stuff really well is to teach it to other people. And I draw a lot of MS Paint diagrams instead of using mind-mapping software, firstly, because nobody has ever loved mind-mapping software in the history of the world.

But secondly, if you are forced to draw using a mouse on a program that doesn't have layers, you've got to be able to... Like Reddit 'Explain it like I'm five.' You've got to be able to explain something really complicated to stakeholders and to other engineers really efficiently. And MS Paint forces you to do that.

So at the end of the day, it's not my technical skills, I think, that have really been the foundation of my career progression. It's been the ability to see what people want that they don't know how to vocalize themselves, and then to help them vocalize those things, or to get into, when it is a really technical project, to be able to understand that tech and break it down so that the people who are helping you fix it can learn it well. So humanities major, secret, secret weapon.

Heidi: And you're actually literally doing translation from technical to non-technical and different domains and stuff.

Fo: Yeah. So it's amazing how much crossover there is between learning a language in a linguistic language and learning how to code, and then also learning how to translate things. Yeah, it's a very accidentally useful skill.

Heidi: That's awesome.

Fo: When you have to read the dictionary all the time, everyone's like RTFM or Google. You're like, yeah, I'm very well trained in RTF, reading the manual.

Heidi: That's awesome. That's awesome. Yeah, no, I think that's so true. I do think, and especially as you become a leader in an organization, I do think the thing that can hold people back is communication skills, and be able to do that translation and whatnot. And so you can get pretty far, but there will be a point where people cap out if they can't figure out how to, like you said, read people, understand what they're asking for, the question behind the question, those kinds of things.

Fo: Yeah. I think a lot of times the job as a technical leader is to be able to provide a sense of safety, a sense of coordination, and for people to know that someone out there is helping steer the boat on a big-picture level.

And I really hope that people who come onto teams like mine realize that 60 to 80% of the effort is not technical. It's planning, and it's making sure that it's the safe thing to, or not the safe thing to do, but the right thing to do in as safe a manner as you can execute it.

Heidi: I love that. I love that. Well, I think we're almost ready to wrap up. I have two quick last questions for you. One is, I love to ask this with everyone. What's a piece of advice you would give to your younger self?

Fo: Don't worry so much. I think at the end of the day, opportunities are random. So they come and they go. At some point, if you keep sticking it out, one will come by. And even if you miss the boat on a couple of things, don't worry.

But most importantly, choose your people as far as you can, be good to them, and be helpful, and they will be helpful to you in turn. And if you can't be in an environment where you're manager, your teammates support you more than anything, maybe that's what should make you try a different team or leave and just read the manual. Google solves a lot of problems.

Heidi: I always like to tell my dad when he asks me something, I'll say, you know what? I have the Google. Hold on a second, and I'll look up the answer for him. And he knows how to use it somehow, but he always forgets. That's awesome. Well, all great advice.

And then just last note, spotlight opportunity, anything upcoming that you would like to highlight?

Fo: Yeah, I'm probably going to be speaking for the first time at the InfoQ Dev Summit in Boston in June this year. So hopefully I'll be able to sneak some either MS Paint or verbal MS Paint into my presentation.

Heidi: Awesome. Well, good luck with that. I'm sure you will do amazing. Just want to say thank you so much for sharing everything today. I really, really loved our conversation and just, it was a delight, and I feel like I learned so much and have so many tips and tricks, and hope other folks have learned the same. So thank you for joining us today.

Fo: Yeah, thank you for having me and for having this podcast, which is such a great resource that you and I probably didn't have at the start of our careers. So really exciting to help contribute to that repository. Yeah, git commit, fun interview, git push.

Heidi: Git push. I love it. Awesome. Thank you so much.

Karen: Engineer Your Career is produced by WEST, a learning community that empowers women technologists through mentorship. Special thanks to our audio production team, Heidi Williams, Amanda Beaty, and yours truly, Karen Ko. If you enjoy our work, we encourage you to share this episode with a friend. Want to hear more from Engineer Your Career? Subscribe on your favorite podcasting app. We look forward to having you back for our next episode. Thanks for tuning in.