Daniel Boaitey: Hi, I'm Daniel Boite. Welcome to the Staff Plus journey. I'm a product engineer at a startup and I'd love to become a Staffs engineer one day. I learned best from career stories, so I'm recording conversations with engineers who've made it to Staff Plus levels and sharing them here. I'm excited for you to hear episode three. Today I'm chatting with Joy Eberts, Principal Engineer at Inprint. And we got into everything from Staff Plus archetypes and tentacle migrations to ultra running and the parallels it has with engineers. What I really appreciated the most about this conversation is Thank you for listening to episode three of the Staff Plus journey. That was a really great chat with Joy. We got into so much. She is just a fountain of knowledge around what it takes to become a Staff Plus engineer. So go check out her. Joy, thank you so much for coming onto the Staffless Journey. It's really great to have you here. ⁓ How's it going for you over there?
Joy: It's going great. I'm really happy to be here.
Daniel Boaitey: Wonderful, wonderful. Really glad we could get connected. I'm excited to learn more about your journey and share that with our listeners. ⁓ So looking at your background, you started at MIT ⁓ and studied computer science there, but I also noticed that you did a music minor. I was just curious to learn more about what led to you doing that minor. Do you play any instruments or anything? And ⁓ yeah, we'll kind of just learn a little bit more about that. articles that she has on Medium, her other talks and interviews. She does so much to learn from her. If you're on YouTube, please like, comment and subscribe. If you're on Apple or Spotify podcasts, please leave a five star review and just in general, share this with a friend. It really helps to get the word out and I'll see you in episode four. Bye bye. how direct and practical joy was about the realities of growing as an engineer and the intricacies of learning to think bigger.
Joy: Yeah, so MIT has this very interesting ⁓ requirement for a lot of like non-engineering type things, and you have to do a focus in one particular area. And I had already done quite a bit of ⁓ music stuff in high school. So that's kind of why I went into the music part. But in terms of what I've played, I don't really play anything anymore, to be honest. But I played viola and piano through high school. ⁓ And the other interesting thing about MIT, so I started out as a math major. And at some point, I realized that I liked my computer science classes a little bit better than my math classes. But I was at this point where I almost had all the requirements for math done. So I decided to do a dual degree. But as a part of that, I needed more credits overall. So that's why I was like, ⁓ instead of just doing the concentration in music, let's make it a full minor. So that's how I ended up with a music minor.
Daniel Boaitey: Oh, a little bit of a whining Jenny there. That's cool, that's cool. And then another thing I noticed that you do outside of engineering is ultra running You're like huge on that, which is crazy to me because running in of itself is like a lot, but then to be an ultra runner is a unique sort of disposition to have. So I was curious about like, yeah, how'd you get into that?
Joy: Yeah. Um, yeah, that's a, that's an interesting story too. I guess I started running in like middle school. I was terrible at it. Um, and I sort of was on and off through college, through some of my first jobs. And then when I joined Box, there were a few other people who are also running and we started, we started doing some marathons together, stuff like that. And there was like a couple of people in particular that I worked with there that we sort of just peer pressured each other into the ultras and it sort of this became this like,
Daniel Boaitey: Hmm ⁓ Hahaha
Joy: Can I do it? I wonder where the limit is. What is my body capable of? And so, yeah, we ended up at the really long stuff at some point.
Daniel Boaitey: Wow, that's pretty cool. Did you do other fitness stuff before that or was this the first time you really got deep on a thing like that?
Joy: That was my first deep fitness thing. Yeah, I would say in terms of athletic stuff, running has, I joke that I'm a one trick pony. I only run. don't do other stuff.
Daniel Boaitey: Nice, nice. Well, that's super cool. I was curious, know, ultra running, I imagine, is very, like, has a lot of complexity behind it and doing that well. So I was just interested in seeing, like, are there any parallels you've seen between the experience of ultra running and being a software engineer and the craft of software engineering?
Joy: I love that you asked this because I've thought about writing a blog post about some of the overlap and I'm never quite sure if people will be interested or not. but I think there's a variety of things, but I think the thing that strikes me the most is with the really long races. So I guess the longest race I've done is a hundred miles. And in a race like that, like you can't think about doing the whole hundred miles at once. It's just like totally overwhelming. Like you,
Daniel Boaitey: ⁓ nice. I one.
Joy: You want to plan for it and think high level and stuff like that, but like you, can't focus on that. You focus on like the next milestone and the next milestone. So like the next aid station and that's how you get through it. And suddenly you realize you've done the whole thing. And I think with projects like, yeah, you want to, you want to think about the whole thing. You want to plan the whole thing, but like, you can't like get too worried about how big it might be because that that's how you get.
Daniel Boaitey: you
Joy: overwhelmed there too. You also need to focus on the next milestone and little victories, little wins, and eventually you find you've done the whole thing.
Daniel Boaitey: That's really cool. Yeah, yeah. Was there anything else you wanted to highlight there or like that's kind of the main thing.
Joy: I think that's the biggest thing I've thought about. ⁓ Yeah, I don't know. I want to spend some more time thinking about this in general at some point, because I think there's probably other stuff too, but at the moment I don't have any others.
Daniel Boaitey: Yeah. Yeah. All good, all good. Yeah, I definitely have seen in my career so far that, yeah, being able to like have those shorter mouth stools makes a big difference for just like... knowing what you're going to get to soon and not slogging as well as communicating I feel to people beyond you know like your team and them getting a sense of like what's actually going on with this work that's happening. ⁓ So that's really good to hear. ⁓ So you know during MIT you interned at Microsoft and then you went back for you your first full-time job. I'd love to learn a little bit more about the team you joined what you're working on there and what if anything still is kind of present in the way you work that
Joy: Mm-hmm. Yeah.
Daniel Boaitey: comes out of your time at Microsoft with it being such a sort of central player in our industry for many, many years. Yeah.
Joy: Yeah, Microsoft is interesting. So I interned on two different teams and then the team I joined was a third team entirely. So, and like, I think what that taught me alone was any big company, each team is very different. They had completely different flavors. One of them was an, like a office team and like kind of the old stodgy office. One of them was a Microsoft live team, which like that was when they were first getting into the online stuff. And so like that, that was a little bit more scrappy, a little bit more like,
Daniel Boaitey: Hmm.
Joy: trying to figure out the new technologies and stuff. And then the team I actually joined was Office Labs was what it was called. So it was again an office team, but in this case, they were really focused on how do we test the risky ideas for the rest of Office? Because you're never gonna put a feature into Office that you have no idea if it's gonna be hit or flop because they, at the time at least, it had such long like...
Daniel Boaitey: Yeah. Mm-hmm.
Joy: development cycles that you don't want to put a bunch of time and effort into something that turns out to be nothing. then they weren't being innovative. So our team, the whole point of our team was to like build prototypes that were like add-ons to Office so that then we could test out these features with real users. What was fascinating about this team, so I would say it's very non-traditional Microsoft. I didn't...
Daniel Boaitey: Yeah.
Joy: My next job, like I remember one of my first pieces of feedback at Box was you need to learn how to test stuff because like we weren't building to last. So despite it being Microsoft, I wasn't testing. ⁓ But yeah, I think some interesting things that came out of that was really learning. Like we were taught how to do usability studies and stuff like that and how to conduct some of that stuff. ⁓ And I haven't ever had to do that again, but like,
Daniel Boaitey: Right, right. Hmm.
Joy: some of this stuff has stuck in the back of my head. Like we learned pretty quickly and there's nothing like doing this with live people to really reinforce it, but we learned pretty quickly that if you put like a help message pop up, the first thing everyone does is just close it. Like nobody reads that stuff. So like there's no point in doing it that way, right? And like, I still see this in so much software and I'm like, I don't like, this is useless. Nobody does this. So just like some of those things that like,
Daniel Boaitey: Hahaha. Yeah.
Joy: It's one thing to kind of think, people probably won't, but like, we'll put it there anyway, just in case. And it's another thing to like test this out with 12 people and every single one of them just immediately closes it. And it was like, I don't know what I'm doing. Yeah. Yeah. Another, another thing that sticks with me from that one is we, talked a lot about data, but one of the things they talked about was to look for where there wasn't data. Like sometimes that's almost as telling.
Daniel Boaitey: Yeah, yeah, super visceral, yeah. Hmm.
Joy: as the other side. like the example they give is ⁓ you have like an air, I think this is a pretty standard example, but you have like airplane and like on it, shows all of the places that airplanes came back with like bullet holes in them, right? And like, but then you think about the places where there aren't any bullet holes is actually where those planes crashed and they're not coming back. So that's actually what you need to worry about.
Daniel Boaitey: Yeah.
Joy: So just kind of thinking about data and it's not just the points you're getting, but it's also the points you're not getting and like, what is that telling you to, which is, yeah, that's something I think about quite a bit.
Daniel Boaitey: Yeah, yeah, yeah. Those are really two really interesting like learnings to take from a time. With the usability side, do you feel like what you learned there has helped you work better with like product and design over your career or did it, I don't compared to other engineers or not that much of an impact?
Joy: I like to think, I mean, I don't know, probably not a lot, but I like to think that it has at least made me a little bit more aware of customers and a little bit more attuned to like that side of things and thinking about that side of things. At this point, I'm a backend engineer, so I'm not necessarily ⁓ touching the front end stuff all that much. So I'm not working as closely with especially design, but yeah, I mean, I still think it's important though, even like the backend stuff, you're still thinking about full user flows and flow.
Daniel Boaitey: Yeah, that's right.
Joy: full user journeys and like what that looks like and what they're probably thinking and how to make this easy, that kind of stuff. So yeah, I'd like to think it helped a little bit.
Daniel Boaitey: Yeah, yeah, probably some. ⁓ Well. Recently, you wrote an article on thinking bigger as an engineer. I thought it was really great. And your thoughts on the various ways to think about impact were pretty illuminating for me. It was really like sort of a precise framing of like how to think about impact. I wondering if you could break down some of the key ideas from that article and maybe an example or two of creating like valuable impact in your career, especially while maybe you were at Box because that's where it seems like you really had the transition from, you know, senior getting to the staff range.
Joy: Yeah, this, that whole article stemmed out of like just seeing engineer after engineer, like hitting up against that staff boundary and like really struggling with like, how do I get to the next level? And I feel like I sort of laid this out, but I feel like there's this common problem of people starting with the focus in their team and then like trying to figure out, like they're told you need to have a bigger influence or like, especially, yeah, especially you need to influence more. But they start with the perspective of the small thing and then they try to push that wider instead of trying to start with the big picture and then figure out how to, how what they're doing applies to that big picture and how to find the intersection there. And I, there's a few different aspects. So there's, there's kind of how you, guess, I guess like a lot of people, I guess another related thing is a lot of people will say, okay, I'm influencing multiple teams because I'm working with multiple teams, but that doesn't really imply influence. That just implies that you're working with multiple teams, right? Like if somebody else told you, need to go make sure this thing works with team B, like that's not really showing influence or showing that like you have a bigger impact. That just means that your feature required some work with team B and you were able to do that. ⁓ I think the difference is more like, were you the one who identified like,
Daniel Boaitey: Mmm. Mm-hmm. Mm-hmm. Hmm.
Joy: sure I'm doing this, but this is also applicable to something they're thinking about. And I'm going to go talk to them proactively to figure out like, how can I build something in a way that'll also be useful for them and not just me? And like, it's a subtle difference. It's very subtle difference, but I do think there's a difference there. ⁓ So that's, there's an aspect there. Then there's like just kind of, sort of related to that. I think the next section I talk about, ⁓
Daniel Boaitey: Hmm. Yeah. Mm-hmm.
Joy: People think about solving an engineering-wide problem, so they take a best practice in their area, and then they try to get other people to adopt it. sometimes that works well. Sometimes it works really well. But other times, it's like they're trying to push something on another team, where it's not even important to the other team. So if you want to get something adopted by all of engineering, if that's your end goal.
Daniel Boaitey: Yeah.
Joy: you kind of need to think about like, what are the top priorities for all of engineering? And like, what do they care about? What will be most helpful for them? And then how do I build the tool that not only helps my team, because you don't want to forget your team. Like in all of this, you don't want to like completely forget your own team. But how do I build something that's useful for my team as well as the other teams and come at it from that perspective. ⁓ In that post, I also talk a little bit about time horizons and how to make sure that
Daniel Boaitey: Yeah, yeah. Yeah. Mm-hmm.
Joy: ⁓ Even assuming something, I actually did a talk on kind of a related subject recently too about like, that talk was about prioritizing tech debt, but it's a similar idea of like, you need to be thinking like both long-term and short-term and like, is the thing I'm gonna work on, like if it doesn't complete, is it still worth doing? And like kind of like,
Daniel Boaitey: Mm-hmm.
Joy: intermediate stages, are they still better than where we are now? Because I've commonly seen like big projects get taken on and then they get like shut down halfway through and like half the time the code is in a worse place than where you started, right? So like how do you make sure that it's actually in an at least equal place from where you started or ideally better place? And if it's not going to be and you think there's a decent chance it's going to get shut down, maybe don't start that one, right?
Daniel Boaitey: Yeah. Mm-hmm. Yeah. Yeah, yeah.
Joy: ⁓ and for a solid example on that one, like one of my first, I'm probably not first. ⁓ it was probably about, I was a senior, senior engineer at that point. ⁓ but it was a little bit before I got promoted and we, we advocated for, I don't even remember the exact direction this one, but we had an integration with Salesforce and either we were pushing data to them or we were pulling data from them one direction or the other. But, ⁓
Daniel Boaitey: Mm-hmm
Joy: Ultimately, we decided that it was going to work better if it was the other direction. So we did all this work to like switch the direction and we got stuff about halfway done and then we got pulled from the project. like, I'm pretty sure that code is still like that. And that was, you know, many years ago now. And I'm also positive it's way worse than it was when we started. And like, that's one of those things that like, I don't think anyone would have told us like this is a bad idea because it was probably a better idea if we had finished the project. But like, I...
Daniel Boaitey: Yeah.
Joy: I still regret it. It still like hurts me a little bit every time I think about that project because I know it's in a much worse state than when I started. yeah. ⁓
Daniel Boaitey: Yeah.
Joy: And I, ⁓ yeah, that sort of, this all ties together into that thinking bigger concept in terms of how do you think about like where something might go? How do you think about what's best for the company as a whole, not just right now, not just this particular piece of whatever you're working on. ⁓ Another example I given there was, this was at my last company actually, we had,
Daniel Boaitey: Yeah. Mm-hmm.
Joy: a database that was running really hot. And we could have just paid for a bigger database, but we didn't really want to do that. So instead we built a cuckoo filter and a cache. And cuckoo filter is actually a pretty cool technology and it was like really applicable to our use case. It's basically like very sure of the negative case. And then there's like a few cases where it's unsure and then you have to do the full check basically. But for our use,
Daniel Boaitey: Mm-hmm. Mm-hmm.
Joy: the negative case was almost always gonna be the case. So it ended up being like very effective. The problem was, so we implemented this and then the cuckoo filter went down and took down our database. So kind of unsurprising, like that kind of thing will happen. So then we stood up a second one and we built in all this redundancy. And at the end of the day, like we started to realize that
Daniel Boaitey: Yeah.
Joy: I don't know that it actually costs more, but it probably costs similar to what it would have been if we just done the bigger database. And unfortunately, now we had a much more complex solution on our hands too. Last I knew they hadn't gotten rid of it, but it's one of those things that like, you know, we were just like fixing little things, fixing little things, getting the thing to work, getting it to work. And then at the end it's like, we're no longer meeting the original goals. And at some point we probably should have reevaluated like.
Daniel Boaitey: Hmm. That's how it goes sometimes. Yeah.
Joy: Do we just ditch this whole thing rather than making it work as we keep going?
Daniel Boaitey: Hmm. Yeah, no, that's an awesome example. I think it makes you think about what you said earlier about the milestones of ultra running. Having those steps in between is so significant. No more into your point around like... ⁓ like delivering a thing that has value better than what you were at before and doing that intentionally. ⁓ And also you're able to leave that thing if something has to, the resources have to be cut, like there's actually something better essentially ⁓ instead of like leaving it in a worse spot than it was before. And then it's like, you also need to, like you're saying, make sure those milestones are defined in...
Joy: Mm-hmm. Yeah.
Daniel Boaitey: while being cognizant of the bigger picture. You're not gonna do your race, like a run and be like, I'm gonna have these milestones and they're just gonna go in any direction I want. There's a finish line that you have to get to. ⁓ And if you don't get there, then your milestones aren't quite helpful.
Joy: Yep. Yes, yes. Yeah, exactly. Yeah.
Daniel Boaitey: Awesome, awesome. Well, yeah, thank you for breaking that down. That's, think, a really, really good article that's gonna be linked below for people to go and read and learn more about how to have bigger impact. Because I really do think, as engineers, often hear, yeah, increase impact, work across teams, but the way you framed it is so much more specific about how do you actually do that in a way that's genuinely valuable, genuinely useful intent. Yeah.
Joy: Mm-hmm. Yeah.
Daniel Boaitey: I was curious, you've been Staff Plus for a good bit of time now. What archetype, know, in Will Larson's four archetypes, do you define yourself as and has that shifted at all over time?
Joy: Yeah, it's funny. I'm actually in that book ⁓ by Mollarsen. And he defined me as an architect. ⁓ so I... No, ⁓ no, that's I don't
Daniel Boaitey: I should have better research on my head.
Joy: mind. ⁓ So, yeah, I guess would say I've spent most my time as an although ⁓ recently, ⁓ my most recent I would say it's... a little bit more right hand. It's a little bit in the middle between the two. Yeah, no, it's, and to be honest, I feel like the four archetypes are a good way of framing things and thinking about things, but I've never been like exactly one at any given time, I would say. Like I've been mostly architect with like, you know, a few fingers into the other directions. And now I would say I'm like mostly right hand, but a little bit.
Daniel Boaitey: Hmm. Hmm. Yeah.
Joy: architects still. ⁓
Daniel Boaitey: Yeah, yeah, I see, see. Do you think that ⁓ the, like, yeah, your principle now, does that influence which archetype is you're leaning towards or that's kind of detached, you think, from the level?
Joy: I think that's a little bit detached, although I suspect there are certain archetypes that they're, I don't want to say easier to get to, but like maybe harder to get to at the lower levels. And like, so like, I think the right hand falls into that a little bit. also think, ⁓ I think a solver is the other one. I think solver also falls into that a little one. Like I think solver actually is,
Daniel Boaitey: Hmm. Mm-hmm.
Joy: is a kind of interesting one because that's the one that I've noticed that senior sues naturally are like, that's the one I want to do because that's the one that's like most like senior suey except just like more technical, just a little bit more. And so they're like, that's the one I can do. But realistically, like, I think that's one of the hardest ones to get to. If you if you're going for that promotion, ⁓ just because most companies
Daniel Boaitey: Yeah. Hmm.
Joy: don't have a lot of space for them. They need a lot more like architects and tech leads. And so there's like just less of a need for them. And they're also looking for like the really, really, really good people. like, unless you are that like quarter percent, you're probably not going to get there. And again, like most senior and senior sues want to be that one. like it's most competitive in a weird way too. ⁓
Daniel Boaitey: Mm-hmm. Exceptional.
Joy: I remember the original question, yeah.
Daniel Boaitey: ⁓ no, you're all good. Yeah, like the level to archetype kind of match or mismatch. So yeah, yeah, no, that's informative.
Joy: Oh, yeah, yeah. But yeah, I think I think you can kind of swap between them a little bit. I guess I have. like, maybe it's a little bit easier to get in more as an architect. And then like over time, you can like switch to one or the other. Yeah, I think they they build off each other. You learn things. It's useful.
Daniel Boaitey: Mm-hmm. Yeah, so it's almost like a toolkit you have as a staffless engineer to lean on one or the other.
Joy: Yeah, yeah.
Daniel Boaitey: So right now you're at imprint Actually before I continue I'd love to if you could share a little bit more about imprint and what they do and what kind of on the technology and engineering side You know, what's what's going on there? I know it's like co-branded cards ⁓ and we get into you fintech There's a lot there. So if you give it over to you that that'd be really cool
Joy: Yeah, I haven't been there super long, so I'm still trying to figure out what we do to some extent. But yeah, we do we do co-branded credit cards. ⁓ And so a lot of it is like we partner with another company and then we work with them to build out a credit card for them. ⁓ So we run the rewards. We do a lot of all of the servicing stuff. ⁓ It's actually interesting. We have a ton of partners behind the scenes. So we're not actually a bank. There's a bank. There's actually two banks that we work with depending on the program. Um, we don't actually run, like we don't actually run a lot of these things. Like we have integrations with Stripe. have integrations with like, um, Lithic, Marketo, like all of these other FinTech, FinTech people doing the other stuff. we're, sort of like the ledger for the stuff. We, we keep track of the rewards. We have all the user experience.
Daniel Boaitey: Hmm. Mm-hmm.
Joy: For the whole thing, ⁓ we help you pay your balance of, I guess we carry the balances or the risk for those. We have an entire risk engineering team, for example. Yeah, I'm probably explaining this badly. Specifically, it's my first FinTech, so I'm like, there's a ton of acronyms in this space. I'm still trying to learn some of that stuff too, to be honest. ⁓
Daniel Boaitey: Yeah, yeah.
Joy: Yeah, so what I'm specifically focusing on is a lot of the more user-focused end of things. like the, two teams specifically. ⁓ One is focused on the application process and then the other one is focused on the servicing part of it, but like mostly the rewards. So that's what I've kind of been digging into recently is how does the reward system work and how do we make it better?
Daniel Boaitey: Nice, nice. Yeah, thanks for creating that overview and kind of what's going on behind the scenes there. ⁓ So at imprint, know Will Weissen is the CTO there. ⁓ And obviously he wrote the book that you're in on staff at Flesch Engineers. I was curious, do you find that your...
Joy: Hahaha
Daniel Boaitey: know, expectations, the way you're managed or kind of how Staff Left Soon works at imprint is in any way unique or different from what you've experienced in the past or compared to like peers in industry. Being in this environment where at the top you've got somebody that really understands kind of how this whole thing is supposed to work in a way. Yeah.
Joy: Yeah, so funny side story. When I first joined Imprint, it had been a little while since I switched companies. So I watched some video that was like, as a staff plus engineer, how to transit, what to do when you first join your job. And one of the things in there was talking about the four archetypes. And I was like, yeah, here's a link to send to your manager if your manager is not aware of who they are. And I report directly to Will Larson. I just started cracking up because I was like...
Daniel Boaitey: hahahahah
Joy: I was like, I wonder what he would do if I just sent him this link. But anyway, ⁓ yeah, it's, it's interesting. I've had, I've had good experiences and bad experiences over the years. ⁓ I guess like, because I've been at this role for a while, and especially when I was at Box, my manager changed a lot at Box. some ⁓ of But I guess like my time at Split and Harness, I had a few different direct managers, but my skip level, like sometimes I reported directly to him, but he was kind of a constant throughout, even if I wasn't directly reporting to him. So he was like, sometimes there was a layer in between and sometimes there wasn't. But ⁓ I would say his style is somewhat similar to Will's generally. So in that sense, that was also well managed. But I have seen failure modes with some of my especially at Box and my managers. it was typically, ⁓ I would say it's almost when I was reporting in too low in the structure that there were the most problems because I have one case in my mind specifically and I was a senior staff at the time and like he was probably a great manager in general. Like this is not to like throw shade on him, but he, ⁓
Daniel Boaitey: Hmm. Yeah, yeah.
Joy: His incentives were very much on the team succeeding and like all of his performance was based around like if the team had its goals and I was reporting to him, but like my goals should have been at a much higher level. And, but he was trying to make me work on stuff that like a senior suite could have done. And so there was sort of just this natural tension of like, I was being really underutilized. ⁓ and I didn't quite have the space to like do more. And part of that was that.
Daniel Boaitey: Yeah.
Joy: my manager at the time was just not incentivized to let that happen. I would say that's definitely one failure mode.
Daniel Boaitey: Yeah.
Joy: I'm sure there's others. guess I've seen this work well. Like when it's worked well, my manager is typically sort of given me a bunch of space, pointing me in a direction, like, and they're a good partner to talk through, like, what are the problem areas? ⁓ Like with Will, I typically, when I meet with him, I would say it's more like half the conversation is just like technical topics where we're like kind of like.
Daniel Boaitey: Mm-hmm.
Joy: I'll be like, ⁓ I think there's this problem with this thing. And he'll be like, ⁓ yeah, I was thinking about like, maybe we should do it this way. And then we sort of talked through the technical solution and then I'm like, ⁓ okay. And then I go off and like implement something. like sometimes he like, especially with AI these days, he'll go off and implement it half the time too. But ⁓ it's more like collaborative in terms of like, where are the problems? And sometimes he'll bring a problem to me and be like, ⁓ I think you need to focus on this area. ⁓ My last manager. Kind of similar. He would probably do slightly larger problems. Maybe large is the wrong word. It was more common that he would throw me at stuff like, you need to figure out how to make the whole back end team more cohesive. I'm like, so more people problems, like organizational, structural.
Daniel Boaitey: Hmm. Hmm.
Joy: like how do we get aligned on a technical vision and like some of that stuff, which might, I think is the difference between the architect and the right hand to some extent. Like now it's more like, like I have a foot in some teams and I'm like working with the teams to some extent and like still setting like direction and stuff, but it's more about like, this is where the biggest fire is. I'm going to go help solve that fire. And then I'm going to like, go find another fire to help solve versus the other one was more about like,
Daniel Boaitey: Yeah. Mm-hmm. Yeah.
Joy: How do we oversee the whole back end?
Daniel Boaitey: Yeah, yeah, yeah, yeah, a little bit different. Yeah, no, thanks for digging into that some. That's interesting to hear and especially around the failure modes and how having a manager that was incentivized in a direction different from what your role was required or called to do, how that affected what you were able to do. ⁓
Joy: Yeah. Yeah.
Daniel Boaitey: So, you know. ⁓ We've kind of talked about this a little bit already, but you've experienced that plus now across four different companies and the acquisition in there. I was curious, like what holds true in that general role, like over those different environments and what has like sort of shifted from company to company?
Joy: Yeah, I'm sure there's environments I haven't experienced because like in some ways, like I was mentioning that skip level manager, I actually followed him from Box. So I like sort of worked with him at Box. I worked with him at ⁓ Split and then we got acquired by Harness. So I continued to work with him there. And then like in some ways I think he's kind of similar to Will Larson in terms of like how he thinks about stuff. But ⁓ that said like,
Daniel Boaitey: Hmm.
Joy: I think there's still a lot of differences in terms of like the company size, the team size, like where you fit into the larger organization, stuff like that. When I was at Box, we had, I don't want to throw out numbers because I'm going to be massively wrong, but it was, it was like a very large startup sort of size. And then when I joined Split, it was about 30 or 40 engineers. And then
Daniel Boaitey: Hmm.
Joy: We grew from there and then Harness was much larger. I don't really remember how big they were, but I was like part of one business unit within this much larger company that spanned like, I guess we had global engineering offices. Like they had a big India office, for example, which has its own set of challenges. ⁓ But I would say the thing that's constant, ⁓ and then like imprint were smaller again, probably like 40. 50 engineers, something like that. ⁓ And yeah, I would say the thing that's constant is kind of what I was talking about in that article in terms of like thinking bigger and like, I think there's an aspect of ownership that's really important ⁓ in terms of, and I guess responsibility, which is kind of two sides of the same coin. But in terms of the more senior you get, like you,
Daniel Boaitey: Okay. Hmm. Mm-hmm.
Joy: On paper, you might be responsible for something ⁓ or like you, there's kind of the software engineering job, but at some level you're also responsible for the company succeeding. And like, if not you, then who, right? Like that part becomes a thing. And so it's like not thinking about just making my team succeed or like.
Daniel Boaitey: Hmm. Yeah, yeah.
Joy: how do I climb the ladder personally, but also like, how do we make sure this company continues to work well? And like, how do I think about solving this problem in the way that's best for the company and then back that out and like, okay, with my engineering lens, how do I apply that? Instead of just being like, this is the best engineering solution, full stop, and then like negotiating. It's a little bit more like, what's the best company solution? And then like, how do I work that with?
Daniel Boaitey: Yeah.
Joy: what the best engineering solution is and like, where do we maybe find the ground that makes the most sense? ⁓ I think I, I know I've said this a bunch of times, but like there's, there's an aspect of like, if I'm, if I build the absolute perfect architecture that can handle, you know, billions of requests when my company doesn't even manage to get to hundreds of requests because you know, we didn't build the features that the customers needed. It doesn't matter. Right. So you need to kind of get.
Daniel Boaitey: Yeah. Hehehe. Right, right.
Joy: figure out what your company needs most right now and how do you build that? And the idea is like, not that you necessarily do something hackily, like, but maybe you do, but, and if you do, then like maybe how do you build it in a way that it's easy to undo later or easy to improve later or something like that, even though it's not the perfect thing now.
Daniel Boaitey: Yeah, yeah. I'm curious in understanding what matters for the company ⁓ and even earlier talking about having impact across teams and understanding what those bigger problems are, what are the ways that you found over time to have that awareness? What the problems that are not just in a specific team but are affecting whole work, what do you kind of do to maintain your awareness of that?
Joy: I would say when I was at Box, I'm thinking back to then since that's when I made the leap originally, but ⁓ there were a few things that helped me out. ⁓ We had a very strong women in tech group at Box, which I was a member of, which it was a good way to have a few connections already on a lot of different teams. like it was through that group, was...
Daniel Boaitey: Right. Mm-hmm.
Joy: like low stakes to just have a conversation with somebody and be like, ⁓ what are you working on? Like, how's it going? Like, what are your problems? What are you facing? So there was that group. ⁓ There was also, like I mentioned, I ran with some other engineers. So like on those runs, we also would talk about stuff. And like, again, it was cross-cutting group. So I guess looking for like even things that look like social things, sometimes I can feel like superfluous or like, why do I need to do this at work? But like, it's actually pretty good for building connections.
Daniel Boaitey: Yeah.
Joy: with people you never would otherwise and sort of learn what they're working on and like learn about the problems. Even like it, like you might not do anything with any of them, but at least you have a little bit more awareness of what's happening. ⁓ In terms of something a little bit more directly job related, I also was a member of the API committee at Box. We had like one group that was responsible for like API standards.
Daniel Boaitey: Yeah. Hmm.
Joy: public API specifically, standards across the entire company to try to make sure that we had a very consistent API going forward. ⁓ And that was also a really good way to get some insight into what a bunch of different teams were working on, as well as get connections with people from a bunch of different teams. ⁓ I remember when I first joined, I was like, I don't know if I'm qualified. I don't know if I should do this. But in retrospect, I'm like, that was one of the smartest things I ever agreed to do.
Daniel Boaitey: Yeah Wow.
Joy: So yeah, it's like one of those things that like, if I could go back and tell myself like, yeah, definitely do that because I mean, APIs themselves are useful. I learned a lot, but also yeah, those connections like I was mentioning and the ability to like learn from people and like be able to influence people on other teams is super valuable.
Daniel Boaitey: Yeah, yeah, that's, it's cool to see how like, there's a bit of a range there, like the casual, social, and then like more like official, like work capacity. Jumping, like a little technical, like you talked about APIs. I know you also talked lot about like future flags and what's it called? Microservices versus monoliths. Sort of a general. theme maybe of change management. I'm just curious like what your thoughts are around migrations and like shifting systems from, you know, we're here and we want to get here and being able to like really do that well I think, because obviously it can be a lot of like failure states and a lot of fear even around like making big changes when you have like an API. It's like, okay, we're gonna, you know, people are gonna not be able to do XYZ thing or yeah, you know, there's gonna lot of motions around monoliths and microservices.
Joy: You
Daniel Boaitey: So I'm just curious around ⁓ just thoughts you have around migrating and making change technically.
Joy: It's funny, I feel like the more of these I've seen, the more I'm like, ⁓ do we really have to? I'm like half joking, ⁓ but not totally because I feel like I've seen a lot of these like not fully get there. Like I've been a part of a number of like, especially the big migrations where it's like, we're gonna do this thing and we get partway and then that's that. Which in some cases is totally fine, I think. Like monolith to microservices, that shift. I, well, there's a whole movement the other direction, but we're going to ignore that for a minute. Assuming, assuming you want to make that shift. ⁓ Typically like at Box, we, we've got it. I don't know. We got it down partway. They're still working on it technically, but when I left, ⁓ we had, we had decreased it by a chunk and like all new services were being built outside the monolith. And like, in some ways that was kind of good enough. Like monolith was no longer a major problem.
Daniel Boaitey: Yeah. Hmm.
Joy: in the way that it had been, like there was no longer the like problem with a billion engineers working in one code base and all of the like merge conflicts and like deployment problems that we were having. like in many ways, monolith was still annoying to work with. It was still spaghetti code, like blah, blah, blah. But like there were just a lot fewer people working in it and like it kind of mattered less. And so like on some level that was a success even though it didn't totally finish. So. I think there's an interesting question there too of like, what do you consider good enough? What do you consider done? And yeah, it's accepting partially done stuff is sometimes important even though it feels wrong. ⁓
Daniel Boaitey: Yeah. Yeah, yeah, you might have gotten enough value out of the thing that's not all the way there, like all the way as the initial goal intended.
Joy: Yeah, yeah. Yeah. When I was at Split, started this big effort, well, a couple big efforts that never really got anywhere. But one of them was trying to build a new public version of our APIs. And we actually got like, I don't know, three quarters of the way done. And then...
Daniel Boaitey: Mm-hmm.
Joy: And then we got acquired and like priority shifted. But ⁓ that was interesting. Like that one was interesting in terms of you have to get like basically the entire engineering on board and you have to like lay out how this is helpful to the company, why this is important. And then like thinking about the migration itself. ⁓ Yeah, like I guess we were,
Daniel Boaitey: Hmm.
Joy: we laid out the new standards and then you start designing all of the new stuff and then you start building the new endpoints and then you put in place policies such as new features are only built on the new endpoints and then we're gonna slowly start to deprecate the old stuff and all of that piece.
Daniel Boaitey: brain.
Joy: Yeah, I guess it's less useful since we didn't actually get there, but... Yeah.
Daniel Boaitey: Outside Forces came and played, yeah, yeah, yeah. ⁓ But no, that's kind of helpful. I appreciate the thought around like, sometimes not getting there is actually okay. ⁓ I feel like that's ⁓ maybe a really big thing because it's true, I feel like with a lot of those types of things, there's usually, there's some painful thing that is triggering the desire to do whatever. So if that pain has lessened, even though you're not all the way there, like.
Joy: Yeah.
Daniel Boaitey: for all intents and purposes, maybe you've accomplished your goal, ⁓ just not in the way intended. ⁓ Cool, I wanted to ask, ⁓ you mentioned women in tech a box. ⁓ I was curious, being a woman in tech, and I can relate as being a black person tech.
Joy: Yeah, yeah.
Daniel Boaitey: Having an identity that's not as common in the industry, right, ⁓ makes for potentially a unique experience. I'm wondering if you feel like that influenced or affected your journey in any way and kind of how you have responded to that over time and ⁓ any thoughts you have for others that have an identity that isn't as common in tech.
Joy: Yeah, in many ways I think I got really lucky at Box because like I mentioned, we had a really good group there. And honestly, a lot of those women I'm still friends with, like pretty close friends with in some cases. And I was talking to a mentee of mine and she was asking about like, do you see a lot of people leaving technical positions, leaving tech? I...
Daniel Boaitey: Hmm.
Joy: I sort of anecdotally know that a bunch of women drop out, but like amongst that group, none of us have. And I think part of it is because we have each other and we like sort of know that there are people out there for us. So I think building up those connections was super important for me. ⁓ I mean, I think there's aspects of being willing to stand up for yourself, like recognizing.
Daniel Boaitey: Yeah.
Joy: I don't know, there's like this delicate bounce, right? Of like recognizing when stuff is happening that shouldn't be happening, but also not like over-focusing on it because like, then you just get angry and there's not a lot you can do. But like, I think there's some things like that same API group I was talking about, I noticed ⁓ in one meeting that I would mention, there were a few meetings that this happened that I really specifically noticed. Like I would mention something, suggest something and just like,
Daniel Boaitey: Hmm. Hehehehehe
Joy: silence and then somebody else in the room would suggest the exact same thing and then everybody's suddenly like, ⁓ yeah, that's a great idea. We should do that. And like, I was like, this is like textbook guys. Like, come on. And I mentioned it to my manager and he just got so pissed off, which actually was helpful because it was sort of validating in this weird way of like, okay, I'm not just being annoying and like whatever, but I ended up not really doing anything with that. But
Daniel Boaitey: Yeah.
Joy: I did really appreciate his support in that moment and like knowing that this is kind of wrong, but this is the way it is occasionally. ⁓ But yeah, I guess like it has affected some of the stuff I've done. Like when I joined Split, they didn't have titles and there's this argument of like, you want ideas to come from anywhere in the org, blah, blah, blah. Like you don't want this like strict focus on hierarchy, but
Daniel Boaitey: Hmm. Yeah. Hmm.
Joy: As a senior woman, I've noticed I don't get taken seriously very well until people either like learn or like, you know, get to know me or if I can throw the title in there, it usually like earns a little bit of respect upfront. So one of my, one of the things I requested was that I would still be able to use a title externally because like it was a small team. So internally I was like, I can get to know these people. No big deal. I don't care. But
Daniel Boaitey: Yeah.
Joy: Externally, like if I'm speaking or something, like being able to put that title there, like causes other people to take me more seriously just upfront. And I find that important. So I think titles, especially are one of those things that help underrepresented folks like get taken seriously upfront a little bit more. And like being able to be like, ⁓ titles don't matter. I don't want a title is like sort of coming from a very, I don't know, like
Daniel Boaitey: Hmm.
Joy: privileged position, right? Yeah, I mean, there's a variety of other things. Part of why I left Tarnas, honestly, was the lack of diversity. So it's not the only thing anywhere, yeah, it's one thing to be, I don't know, on the low end of women. And it's another thing, I was...
Daniel Boaitey: Mmm, that's tough.
Joy: Speaking at a manager's meeting there and there were probably 30 or 40 people in the room and I was the only woman apart from the HR representative and like yeah that was that moment especially I was just like ⁓ I don't know if I can do this like I'm okay with there being like only a couple but like ⁓ being the only one that's especially in a room that large like that's that's too much.
Daniel Boaitey: Oof. Yeah. That's really tough. Yeah, yeah, yeah. Thank you for sharing those different things. I think it's cool to hear that you have that community from Box that sort of, all, in being in each other's world and domain, probably helped you all stay in the industry despite any of those crazy things that can show up. yeah, the title thing, I've definitely, yeah, I heard both sides of that argument, but I think it is so true that it can really...
Joy: Yeah.
Daniel Boaitey: have caused people to have a different perception of you and like legitimize even though it's like unfortunately you shouldn't maybe need that like anyone shouldn't necessarily need that and there should be like haeless talk ideas and free or freely sort of consider whatever people are saying but there can really be an impact on ⁓ you know that that subheading under your name that affects how people see things ⁓ but
Joy: Yeah.
Daniel Boaitey: ⁓ But yeah, thanks for diving into that a little bit. think it's really cool for people to hear from somebody who has made it so far in the industry, ⁓ who navigates those waters, even though like obviously outside of that, like your career is truly incredible. But it is a piece of the puzzle that you had to navigate. So it's really great to hear more about that. I'm going to wrap it up here with two closing questions.
Joy: Hahaha Mm-hmm.
Daniel Boaitey: ⁓ The first question I have, you know, we work in tech, crazy stuff happens all the time. ⁓ I'm curious, what's a memorable maybe production bug or incident that you've dealt with at some point in your career?
Joy: What came to mind for this question was, I actually don't really remember doing much to solve it. I caused it. But this is when I was at Split. So we were a feature flagging company. So we built the on-off switches to emergency turn stuff off, whatever. And I had made, I don't remember, it was like a...
Daniel Boaitey: It works.
Joy: database change or like a query change or something. And I thought I was being super smart because I wrapped the whole thing in a feature flag. So this was not going to take anything down. We could just turn off that flag and be fine. The thing I didn't think about was that ⁓ I took down the database, which meant that we couldn't turn off the feature flag because we were using our own product. there was absolutely no way to turn it back off even though in theory there was, which is this funny moment of like,
Daniel Boaitey: Mm-hmm. Hahaha Yeah Yeah, yeah.
Joy: I don't know, I learned a lesson about like dog food, like yeah, of course you dog food, but you also have to think about if like that's gonna actually impact your ability to respond to incidents at the same time.
Daniel Boaitey: Yeah, that's pretty funny. Actually, I had a question. just thought of, you haven't noticed, that's fine. Like while you were at Split, what's maybe the craziest feature flag use case you heard about from a customer?
Joy: They were trying to do all kinds of stuff and we were like, our sales team was so creative. They were like pushing weird stuff that like as engineers were like, ⁓ why would you do that? But they were like, we had some stuff like dynamic configs where you could like include instead of just being yes, no, it would be like, if this, would return like some arbitrary piece of code or something. Yeah.
Daniel Boaitey: Mm-hmm. guess stringer
Joy: So there was a use case around like you could just put like a banner in your thing and just change the message using a feature flag for certain customers. So like if there was I don't know if you're a delivery company and there was like snow in Boston you could just like put up a banner for the people in Boston being like your delivery might be slow today. Sorry or whatever. ⁓ It might be. ⁓ That's obviously not the craziest. I'm having a hard time remembering the craziest but
Daniel Boaitey: Yeah, yeah, yeah. ⁓ all good. All good. I know the what's it called? Extreme adjective there. ⁓ But yeah, we can move on. So last question here. ⁓ If you had every engineer, you know, that's trying to be stuff plus in a room, what would you say to them?
Joy: You Probably sort of similar to what I mentioned before in terms of a lot of it's about ownership, like trying to trans, like switch your thinking from like me and my career and how do I, I get better into more of like, I own this product, I own this or maybe product area and like, I am responsible for this thing and it. Given that I am like responsible and maybe even the whole company, if I'm responsible for the whole company, what is the best thing that needs to happen for that? And how do I help us all get there? Honestly, it's not just about lifting your own boat. It's about lifting others as well. have, there's a few folks that I've worked with over the years who like want to get to the staff level or like when I worked with them, they were trying to get there. And like, that's a pretty common piece of feedback too is like,
Daniel Boaitey: Mm-hmm.
Joy: they're doing great themselves, but they're not really lifting their team with them. So it's kind of not just about you, but how are you enabling, or maybe it's mentorship, maybe it's like building tools that everyone can use, but like, how are you enabling your entire team and area to improve, not just yourself?
Daniel Boaitey: Hmm. Yeah, yeah, that's a great piece of advice ⁓ that I'll be taking for myself too. ⁓ But yeah, thank you so much, Troy. This is a great conversation. We got to dive into a lot of stuff and there's more we could have talked about. ⁓ You've done really cool things, but I really, really appreciate it. And yeah, we'll wrap it up there.
Joy: Yeah, yep, thanks for having
Joy: It's going great. I'm really happy to be here.
Daniel Boaitey: Wonderful, wonderful. Really glad we could get connected. I'm excited to learn more about your journey and share that with our listeners. ⁓ So looking at your background, you started at MIT ⁓ and studied computer science there, but I also noticed that you did a music minor. I was just curious to learn more about what led to you doing that minor. Do you play any instruments or anything? And ⁓ yeah, we'll kind of just learn a little bit more about that. articles that she has on Medium, her other talks and interviews. She does so much to learn from her. If you're on YouTube, please like, comment and subscribe. If you're on Apple or Spotify podcasts, please leave a five star review and just in general, share this with a friend. It really helps to get the word out and I'll see you in episode four. Bye bye. how direct and practical joy was about the realities of growing as an engineer and the intricacies of learning to think bigger.
Joy: Yeah, so MIT has this very interesting ⁓ requirement for a lot of like non-engineering type things, and you have to do a focus in one particular area. And I had already done quite a bit of ⁓ music stuff in high school. So that's kind of why I went into the music part. But in terms of what I've played, I don't really play anything anymore, to be honest. But I played viola and piano through high school. ⁓ And the other interesting thing about MIT, so I started out as a math major. And at some point, I realized that I liked my computer science classes a little bit better than my math classes. But I was at this point where I almost had all the requirements for math done. So I decided to do a dual degree. But as a part of that, I needed more credits overall. So that's why I was like, ⁓ instead of just doing the concentration in music, let's make it a full minor. So that's how I ended up with a music minor.
Daniel Boaitey: Oh, a little bit of a whining Jenny there. That's cool, that's cool. And then another thing I noticed that you do outside of engineering is ultra running You're like huge on that, which is crazy to me because running in of itself is like a lot, but then to be an ultra runner is a unique sort of disposition to have. So I was curious about like, yeah, how'd you get into that?
Joy: Yeah. Um, yeah, that's a, that's an interesting story too. I guess I started running in like middle school. I was terrible at it. Um, and I sort of was on and off through college, through some of my first jobs. And then when I joined Box, there were a few other people who are also running and we started, we started doing some marathons together, stuff like that. And there was like a couple of people in particular that I worked with there that we sort of just peer pressured each other into the ultras and it sort of this became this like,
Daniel Boaitey: Hmm ⁓ Hahaha
Joy: Can I do it? I wonder where the limit is. What is my body capable of? And so, yeah, we ended up at the really long stuff at some point.
Daniel Boaitey: Wow, that's pretty cool. Did you do other fitness stuff before that or was this the first time you really got deep on a thing like that?
Joy: That was my first deep fitness thing. Yeah, I would say in terms of athletic stuff, running has, I joke that I'm a one trick pony. I only run. don't do other stuff.
Daniel Boaitey: Nice, nice. Well, that's super cool. I was curious, know, ultra running, I imagine, is very, like, has a lot of complexity behind it and doing that well. So I was just interested in seeing, like, are there any parallels you've seen between the experience of ultra running and being a software engineer and the craft of software engineering?
Joy: I love that you asked this because I've thought about writing a blog post about some of the overlap and I'm never quite sure if people will be interested or not. but I think there's a variety of things, but I think the thing that strikes me the most is with the really long races. So I guess the longest race I've done is a hundred miles. And in a race like that, like you can't think about doing the whole hundred miles at once. It's just like totally overwhelming. Like you,
Daniel Boaitey: ⁓ nice. I one.
Joy: You want to plan for it and think high level and stuff like that, but like you, can't focus on that. You focus on like the next milestone and the next milestone. So like the next aid station and that's how you get through it. And suddenly you realize you've done the whole thing. And I think with projects like, yeah, you want to, you want to think about the whole thing. You want to plan the whole thing, but like, you can't like get too worried about how big it might be because that that's how you get.
Daniel Boaitey: you
Joy: overwhelmed there too. You also need to focus on the next milestone and little victories, little wins, and eventually you find you've done the whole thing.
Daniel Boaitey: That's really cool. Yeah, yeah. Was there anything else you wanted to highlight there or like that's kind of the main thing.
Joy: I think that's the biggest thing I've thought about. ⁓ Yeah, I don't know. I want to spend some more time thinking about this in general at some point, because I think there's probably other stuff too, but at the moment I don't have any others.
Daniel Boaitey: Yeah. Yeah. All good, all good. Yeah, I definitely have seen in my career so far that, yeah, being able to like have those shorter mouth stools makes a big difference for just like... knowing what you're going to get to soon and not slogging as well as communicating I feel to people beyond you know like your team and them getting a sense of like what's actually going on with this work that's happening. ⁓ So that's really good to hear. ⁓ So you know during MIT you interned at Microsoft and then you went back for you your first full-time job. I'd love to learn a little bit more about the team you joined what you're working on there and what if anything still is kind of present in the way you work that
Joy: Mm-hmm. Yeah.
Daniel Boaitey: comes out of your time at Microsoft with it being such a sort of central player in our industry for many, many years. Yeah.
Joy: Yeah, Microsoft is interesting. So I interned on two different teams and then the team I joined was a third team entirely. So, and like, I think what that taught me alone was any big company, each team is very different. They had completely different flavors. One of them was an, like a office team and like kind of the old stodgy office. One of them was a Microsoft live team, which like that was when they were first getting into the online stuff. And so like that, that was a little bit more scrappy, a little bit more like,
Daniel Boaitey: Hmm.
Joy: trying to figure out the new technologies and stuff. And then the team I actually joined was Office Labs was what it was called. So it was again an office team, but in this case, they were really focused on how do we test the risky ideas for the rest of Office? Because you're never gonna put a feature into Office that you have no idea if it's gonna be hit or flop because they, at the time at least, it had such long like...
Daniel Boaitey: Yeah. Mm-hmm.
Joy: development cycles that you don't want to put a bunch of time and effort into something that turns out to be nothing. then they weren't being innovative. So our team, the whole point of our team was to like build prototypes that were like add-ons to Office so that then we could test out these features with real users. What was fascinating about this team, so I would say it's very non-traditional Microsoft. I didn't...
Daniel Boaitey: Yeah.
Joy: My next job, like I remember one of my first pieces of feedback at Box was you need to learn how to test stuff because like we weren't building to last. So despite it being Microsoft, I wasn't testing. ⁓ But yeah, I think some interesting things that came out of that was really learning. Like we were taught how to do usability studies and stuff like that and how to conduct some of that stuff. ⁓ And I haven't ever had to do that again, but like,
Daniel Boaitey: Right, right. Hmm.
Joy: some of this stuff has stuck in the back of my head. Like we learned pretty quickly and there's nothing like doing this with live people to really reinforce it, but we learned pretty quickly that if you put like a help message pop up, the first thing everyone does is just close it. Like nobody reads that stuff. So like there's no point in doing it that way, right? And like, I still see this in so much software and I'm like, I don't like, this is useless. Nobody does this. So just like some of those things that like,
Daniel Boaitey: Hahaha. Yeah.
Joy: It's one thing to kind of think, people probably won't, but like, we'll put it there anyway, just in case. And it's another thing to like test this out with 12 people and every single one of them just immediately closes it. And it was like, I don't know what I'm doing. Yeah. Yeah. Another, another thing that sticks with me from that one is we, talked a lot about data, but one of the things they talked about was to look for where there wasn't data. Like sometimes that's almost as telling.
Daniel Boaitey: Yeah, yeah, super visceral, yeah. Hmm.
Joy: as the other side. like the example they give is ⁓ you have like an air, I think this is a pretty standard example, but you have like airplane and like on it, shows all of the places that airplanes came back with like bullet holes in them, right? And like, but then you think about the places where there aren't any bullet holes is actually where those planes crashed and they're not coming back. So that's actually what you need to worry about.
Daniel Boaitey: Yeah.
Joy: So just kind of thinking about data and it's not just the points you're getting, but it's also the points you're not getting and like, what is that telling you to, which is, yeah, that's something I think about quite a bit.
Daniel Boaitey: Yeah, yeah, yeah. Those are really two really interesting like learnings to take from a time. With the usability side, do you feel like what you learned there has helped you work better with like product and design over your career or did it, I don't compared to other engineers or not that much of an impact?
Joy: I like to think, I mean, I don't know, probably not a lot, but I like to think that it has at least made me a little bit more aware of customers and a little bit more attuned to like that side of things and thinking about that side of things. At this point, I'm a backend engineer, so I'm not necessarily ⁓ touching the front end stuff all that much. So I'm not working as closely with especially design, but yeah, I mean, I still think it's important though, even like the backend stuff, you're still thinking about full user flows and flow.
Daniel Boaitey: Yeah, that's right.
Joy: full user journeys and like what that looks like and what they're probably thinking and how to make this easy, that kind of stuff. So yeah, I'd like to think it helped a little bit.
Daniel Boaitey: Yeah, yeah, probably some. ⁓ Well. Recently, you wrote an article on thinking bigger as an engineer. I thought it was really great. And your thoughts on the various ways to think about impact were pretty illuminating for me. It was really like sort of a precise framing of like how to think about impact. I wondering if you could break down some of the key ideas from that article and maybe an example or two of creating like valuable impact in your career, especially while maybe you were at Box because that's where it seems like you really had the transition from, you know, senior getting to the staff range.
Joy: Yeah, this, that whole article stemmed out of like just seeing engineer after engineer, like hitting up against that staff boundary and like really struggling with like, how do I get to the next level? And I feel like I sort of laid this out, but I feel like there's this common problem of people starting with the focus in their team and then like trying to figure out, like they're told you need to have a bigger influence or like, especially, yeah, especially you need to influence more. But they start with the perspective of the small thing and then they try to push that wider instead of trying to start with the big picture and then figure out how to, how what they're doing applies to that big picture and how to find the intersection there. And I, there's a few different aspects. So there's, there's kind of how you, guess, I guess like a lot of people, I guess another related thing is a lot of people will say, okay, I'm influencing multiple teams because I'm working with multiple teams, but that doesn't really imply influence. That just implies that you're working with multiple teams, right? Like if somebody else told you, need to go make sure this thing works with team B, like that's not really showing influence or showing that like you have a bigger impact. That just means that your feature required some work with team B and you were able to do that. ⁓ I think the difference is more like, were you the one who identified like,
Daniel Boaitey: Mmm. Mm-hmm. Mm-hmm. Hmm.
Joy: sure I'm doing this, but this is also applicable to something they're thinking about. And I'm going to go talk to them proactively to figure out like, how can I build something in a way that'll also be useful for them and not just me? And like, it's a subtle difference. It's very subtle difference, but I do think there's a difference there. ⁓ So that's, there's an aspect there. Then there's like just kind of, sort of related to that. I think the next section I talk about, ⁓
Daniel Boaitey: Hmm. Yeah. Mm-hmm.
Joy: People think about solving an engineering-wide problem, so they take a best practice in their area, and then they try to get other people to adopt it. sometimes that works well. Sometimes it works really well. But other times, it's like they're trying to push something on another team, where it's not even important to the other team. So if you want to get something adopted by all of engineering, if that's your end goal.
Daniel Boaitey: Yeah.
Joy: you kind of need to think about like, what are the top priorities for all of engineering? And like, what do they care about? What will be most helpful for them? And then how do I build the tool that not only helps my team, because you don't want to forget your team. Like in all of this, you don't want to like completely forget your own team. But how do I build something that's useful for my team as well as the other teams and come at it from that perspective. ⁓ In that post, I also talk a little bit about time horizons and how to make sure that
Daniel Boaitey: Yeah, yeah. Yeah. Mm-hmm.
Joy: ⁓ Even assuming something, I actually did a talk on kind of a related subject recently too about like, that talk was about prioritizing tech debt, but it's a similar idea of like, you need to be thinking like both long-term and short-term and like, is the thing I'm gonna work on, like if it doesn't complete, is it still worth doing? And like kind of like,
Daniel Boaitey: Mm-hmm.
Joy: intermediate stages, are they still better than where we are now? Because I've commonly seen like big projects get taken on and then they get like shut down halfway through and like half the time the code is in a worse place than where you started, right? So like how do you make sure that it's actually in an at least equal place from where you started or ideally better place? And if it's not going to be and you think there's a decent chance it's going to get shut down, maybe don't start that one, right?
Daniel Boaitey: Yeah. Mm-hmm. Yeah. Yeah, yeah.
Joy: ⁓ and for a solid example on that one, like one of my first, I'm probably not first. ⁓ it was probably about, I was a senior, senior engineer at that point. ⁓ but it was a little bit before I got promoted and we, we advocated for, I don't even remember the exact direction this one, but we had an integration with Salesforce and either we were pushing data to them or we were pulling data from them one direction or the other. But, ⁓
Daniel Boaitey: Mm-hmm
Joy: Ultimately, we decided that it was going to work better if it was the other direction. So we did all this work to like switch the direction and we got stuff about halfway done and then we got pulled from the project. like, I'm pretty sure that code is still like that. And that was, you know, many years ago now. And I'm also positive it's way worse than it was when we started. And like, that's one of those things that like, I don't think anyone would have told us like this is a bad idea because it was probably a better idea if we had finished the project. But like, I...
Daniel Boaitey: Yeah.
Joy: I still regret it. It still like hurts me a little bit every time I think about that project because I know it's in a much worse state than when I started. yeah. ⁓
Daniel Boaitey: Yeah.
Joy: And I, ⁓ yeah, that sort of, this all ties together into that thinking bigger concept in terms of how do you think about like where something might go? How do you think about what's best for the company as a whole, not just right now, not just this particular piece of whatever you're working on. ⁓ Another example I given there was, this was at my last company actually, we had,
Daniel Boaitey: Yeah. Mm-hmm.
Joy: a database that was running really hot. And we could have just paid for a bigger database, but we didn't really want to do that. So instead we built a cuckoo filter and a cache. And cuckoo filter is actually a pretty cool technology and it was like really applicable to our use case. It's basically like very sure of the negative case. And then there's like a few cases where it's unsure and then you have to do the full check basically. But for our use,
Daniel Boaitey: Mm-hmm. Mm-hmm.
Joy: the negative case was almost always gonna be the case. So it ended up being like very effective. The problem was, so we implemented this and then the cuckoo filter went down and took down our database. So kind of unsurprising, like that kind of thing will happen. So then we stood up a second one and we built in all this redundancy. And at the end of the day, like we started to realize that
Daniel Boaitey: Yeah.
Joy: I don't know that it actually costs more, but it probably costs similar to what it would have been if we just done the bigger database. And unfortunately, now we had a much more complex solution on our hands too. Last I knew they hadn't gotten rid of it, but it's one of those things that like, you know, we were just like fixing little things, fixing little things, getting the thing to work, getting it to work. And then at the end it's like, we're no longer meeting the original goals. And at some point we probably should have reevaluated like.
Daniel Boaitey: Hmm. That's how it goes sometimes. Yeah.
Joy: Do we just ditch this whole thing rather than making it work as we keep going?
Daniel Boaitey: Hmm. Yeah, no, that's an awesome example. I think it makes you think about what you said earlier about the milestones of ultra running. Having those steps in between is so significant. No more into your point around like... ⁓ like delivering a thing that has value better than what you were at before and doing that intentionally. ⁓ And also you're able to leave that thing if something has to, the resources have to be cut, like there's actually something better essentially ⁓ instead of like leaving it in a worse spot than it was before. And then it's like, you also need to, like you're saying, make sure those milestones are defined in...
Joy: Mm-hmm. Yeah.
Daniel Boaitey: while being cognizant of the bigger picture. You're not gonna do your race, like a run and be like, I'm gonna have these milestones and they're just gonna go in any direction I want. There's a finish line that you have to get to. ⁓ And if you don't get there, then your milestones aren't quite helpful.
Joy: Yep. Yes, yes. Yeah, exactly. Yeah.
Daniel Boaitey: Awesome, awesome. Well, yeah, thank you for breaking that down. That's, think, a really, really good article that's gonna be linked below for people to go and read and learn more about how to have bigger impact. Because I really do think, as engineers, often hear, yeah, increase impact, work across teams, but the way you framed it is so much more specific about how do you actually do that in a way that's genuinely valuable, genuinely useful intent. Yeah.
Joy: Mm-hmm. Yeah.
Daniel Boaitey: I was curious, you've been Staff Plus for a good bit of time now. What archetype, know, in Will Larson's four archetypes, do you define yourself as and has that shifted at all over time?
Joy: Yeah, it's funny. I'm actually in that book ⁓ by Mollarsen. And he defined me as an architect. ⁓ so I... No, ⁓ no, that's I don't
Daniel Boaitey: I should have better research on my head.
Joy: mind. ⁓ So, yeah, I guess would say I've spent most my time as an although ⁓ recently, ⁓ my most recent I would say it's... a little bit more right hand. It's a little bit in the middle between the two. Yeah, no, it's, and to be honest, I feel like the four archetypes are a good way of framing things and thinking about things, but I've never been like exactly one at any given time, I would say. Like I've been mostly architect with like, you know, a few fingers into the other directions. And now I would say I'm like mostly right hand, but a little bit.
Daniel Boaitey: Hmm. Hmm. Yeah.
Joy: architects still. ⁓
Daniel Boaitey: Yeah, yeah, I see, see. Do you think that ⁓ the, like, yeah, your principle now, does that influence which archetype is you're leaning towards or that's kind of detached, you think, from the level?
Joy: I think that's a little bit detached, although I suspect there are certain archetypes that they're, I don't want to say easier to get to, but like maybe harder to get to at the lower levels. And like, so like, I think the right hand falls into that a little bit. also think, ⁓ I think a solver is the other one. I think solver also falls into that a little one. Like I think solver actually is,
Daniel Boaitey: Hmm. Mm-hmm.
Joy: is a kind of interesting one because that's the one that I've noticed that senior sues naturally are like, that's the one I want to do because that's the one that's like most like senior suey except just like more technical, just a little bit more. And so they're like, that's the one I can do. But realistically, like, I think that's one of the hardest ones to get to. If you if you're going for that promotion, ⁓ just because most companies
Daniel Boaitey: Yeah. Hmm.
Joy: don't have a lot of space for them. They need a lot more like architects and tech leads. And so there's like just less of a need for them. And they're also looking for like the really, really, really good people. like, unless you are that like quarter percent, you're probably not going to get there. And again, like most senior and senior sues want to be that one. like it's most competitive in a weird way too. ⁓
Daniel Boaitey: Mm-hmm. Exceptional.
Joy: I remember the original question, yeah.
Daniel Boaitey: ⁓ no, you're all good. Yeah, like the level to archetype kind of match or mismatch. So yeah, yeah, no, that's informative.
Joy: Oh, yeah, yeah. But yeah, I think I think you can kind of swap between them a little bit. I guess I have. like, maybe it's a little bit easier to get in more as an architect. And then like over time, you can like switch to one or the other. Yeah, I think they they build off each other. You learn things. It's useful.
Daniel Boaitey: Mm-hmm. Yeah, so it's almost like a toolkit you have as a staffless engineer to lean on one or the other.
Joy: Yeah, yeah.
Daniel Boaitey: So right now you're at imprint Actually before I continue I'd love to if you could share a little bit more about imprint and what they do and what kind of on the technology and engineering side You know, what's what's going on there? I know it's like co-branded cards ⁓ and we get into you fintech There's a lot there. So if you give it over to you that that'd be really cool
Joy: Yeah, I haven't been there super long, so I'm still trying to figure out what we do to some extent. But yeah, we do we do co-branded credit cards. ⁓ And so a lot of it is like we partner with another company and then we work with them to build out a credit card for them. ⁓ So we run the rewards. We do a lot of all of the servicing stuff. ⁓ It's actually interesting. We have a ton of partners behind the scenes. So we're not actually a bank. There's a bank. There's actually two banks that we work with depending on the program. Um, we don't actually run, like we don't actually run a lot of these things. Like we have integrations with Stripe. have integrations with like, um, Lithic, Marketo, like all of these other FinTech, FinTech people doing the other stuff. we're, sort of like the ledger for the stuff. We, we keep track of the rewards. We have all the user experience.
Daniel Boaitey: Hmm. Mm-hmm.
Joy: For the whole thing, ⁓ we help you pay your balance of, I guess we carry the balances or the risk for those. We have an entire risk engineering team, for example. Yeah, I'm probably explaining this badly. Specifically, it's my first FinTech, so I'm like, there's a ton of acronyms in this space. I'm still trying to learn some of that stuff too, to be honest. ⁓
Daniel Boaitey: Yeah, yeah.
Joy: Yeah, so what I'm specifically focusing on is a lot of the more user-focused end of things. like the, two teams specifically. ⁓ One is focused on the application process and then the other one is focused on the servicing part of it, but like mostly the rewards. So that's what I've kind of been digging into recently is how does the reward system work and how do we make it better?
Daniel Boaitey: Nice, nice. Yeah, thanks for creating that overview and kind of what's going on behind the scenes there. ⁓ So at imprint, know Will Weissen is the CTO there. ⁓ And obviously he wrote the book that you're in on staff at Flesch Engineers. I was curious, do you find that your...
Joy: Hahaha
Daniel Boaitey: know, expectations, the way you're managed or kind of how Staff Left Soon works at imprint is in any way unique or different from what you've experienced in the past or compared to like peers in industry. Being in this environment where at the top you've got somebody that really understands kind of how this whole thing is supposed to work in a way. Yeah.
Joy: Yeah, so funny side story. When I first joined Imprint, it had been a little while since I switched companies. So I watched some video that was like, as a staff plus engineer, how to transit, what to do when you first join your job. And one of the things in there was talking about the four archetypes. And I was like, yeah, here's a link to send to your manager if your manager is not aware of who they are. And I report directly to Will Larson. I just started cracking up because I was like...
Daniel Boaitey: hahahahah
Joy: I was like, I wonder what he would do if I just sent him this link. But anyway, ⁓ yeah, it's, it's interesting. I've had, I've had good experiences and bad experiences over the years. ⁓ I guess like, because I've been at this role for a while, and especially when I was at Box, my manager changed a lot at Box. some ⁓ of But I guess like my time at Split and Harness, I had a few different direct managers, but my skip level, like sometimes I reported directly to him, but he was kind of a constant throughout, even if I wasn't directly reporting to him. So he was like, sometimes there was a layer in between and sometimes there wasn't. But ⁓ I would say his style is somewhat similar to Will's generally. So in that sense, that was also well managed. But I have seen failure modes with some of my especially at Box and my managers. it was typically, ⁓ I would say it's almost when I was reporting in too low in the structure that there were the most problems because I have one case in my mind specifically and I was a senior staff at the time and like he was probably a great manager in general. Like this is not to like throw shade on him, but he, ⁓
Daniel Boaitey: Hmm. Yeah, yeah.
Joy: His incentives were very much on the team succeeding and like all of his performance was based around like if the team had its goals and I was reporting to him, but like my goals should have been at a much higher level. And, but he was trying to make me work on stuff that like a senior suite could have done. And so there was sort of just this natural tension of like, I was being really underutilized. ⁓ and I didn't quite have the space to like do more. And part of that was that.
Daniel Boaitey: Yeah.
Joy: my manager at the time was just not incentivized to let that happen. I would say that's definitely one failure mode.
Daniel Boaitey: Yeah.
Joy: I'm sure there's others. guess I've seen this work well. Like when it's worked well, my manager is typically sort of given me a bunch of space, pointing me in a direction, like, and they're a good partner to talk through, like, what are the problem areas? ⁓ Like with Will, I typically, when I meet with him, I would say it's more like half the conversation is just like technical topics where we're like kind of like.
Daniel Boaitey: Mm-hmm.
Joy: I'll be like, ⁓ I think there's this problem with this thing. And he'll be like, ⁓ yeah, I was thinking about like, maybe we should do it this way. And then we sort of talked through the technical solution and then I'm like, ⁓ okay. And then I go off and like implement something. like sometimes he like, especially with AI these days, he'll go off and implement it half the time too. But ⁓ it's more like collaborative in terms of like, where are the problems? And sometimes he'll bring a problem to me and be like, ⁓ I think you need to focus on this area. ⁓ My last manager. Kind of similar. He would probably do slightly larger problems. Maybe large is the wrong word. It was more common that he would throw me at stuff like, you need to figure out how to make the whole back end team more cohesive. I'm like, so more people problems, like organizational, structural.
Daniel Boaitey: Hmm. Hmm.
Joy: like how do we get aligned on a technical vision and like some of that stuff, which might, I think is the difference between the architect and the right hand to some extent. Like now it's more like, like I have a foot in some teams and I'm like working with the teams to some extent and like still setting like direction and stuff, but it's more about like, this is where the biggest fire is. I'm going to go help solve that fire. And then I'm going to like, go find another fire to help solve versus the other one was more about like,
Daniel Boaitey: Yeah. Mm-hmm. Yeah.
Joy: How do we oversee the whole back end?
Daniel Boaitey: Yeah, yeah, yeah, yeah, a little bit different. Yeah, no, thanks for digging into that some. That's interesting to hear and especially around the failure modes and how having a manager that was incentivized in a direction different from what your role was required or called to do, how that affected what you were able to do. ⁓
Joy: Yeah. Yeah.
Daniel Boaitey: So, you know. ⁓ We've kind of talked about this a little bit already, but you've experienced that plus now across four different companies and the acquisition in there. I was curious, like what holds true in that general role, like over those different environments and what has like sort of shifted from company to company?
Joy: Yeah, I'm sure there's environments I haven't experienced because like in some ways, like I was mentioning that skip level manager, I actually followed him from Box. So I like sort of worked with him at Box. I worked with him at ⁓ Split and then we got acquired by Harness. So I continued to work with him there. And then like in some ways I think he's kind of similar to Will Larson in terms of like how he thinks about stuff. But ⁓ that said like,
Daniel Boaitey: Hmm.
Joy: I think there's still a lot of differences in terms of like the company size, the team size, like where you fit into the larger organization, stuff like that. When I was at Box, we had, I don't want to throw out numbers because I'm going to be massively wrong, but it was, it was like a very large startup sort of size. And then when I joined Split, it was about 30 or 40 engineers. And then
Daniel Boaitey: Hmm.
Joy: We grew from there and then Harness was much larger. I don't really remember how big they were, but I was like part of one business unit within this much larger company that spanned like, I guess we had global engineering offices. Like they had a big India office, for example, which has its own set of challenges. ⁓ But I would say the thing that's constant, ⁓ and then like imprint were smaller again, probably like 40. 50 engineers, something like that. ⁓ And yeah, I would say the thing that's constant is kind of what I was talking about in that article in terms of like thinking bigger and like, I think there's an aspect of ownership that's really important ⁓ in terms of, and I guess responsibility, which is kind of two sides of the same coin. But in terms of the more senior you get, like you,
Daniel Boaitey: Okay. Hmm. Mm-hmm.
Joy: On paper, you might be responsible for something ⁓ or like you, there's kind of the software engineering job, but at some level you're also responsible for the company succeeding. And like, if not you, then who, right? Like that part becomes a thing. And so it's like not thinking about just making my team succeed or like.
Daniel Boaitey: Hmm. Yeah, yeah.
Joy: how do I climb the ladder personally, but also like, how do we make sure this company continues to work well? And like, how do I think about solving this problem in the way that's best for the company and then back that out and like, okay, with my engineering lens, how do I apply that? Instead of just being like, this is the best engineering solution, full stop, and then like negotiating. It's a little bit more like, what's the best company solution? And then like, how do I work that with?
Daniel Boaitey: Yeah.
Joy: what the best engineering solution is and like, where do we maybe find the ground that makes the most sense? ⁓ I think I, I know I've said this a bunch of times, but like there's, there's an aspect of like, if I'm, if I build the absolute perfect architecture that can handle, you know, billions of requests when my company doesn't even manage to get to hundreds of requests because you know, we didn't build the features that the customers needed. It doesn't matter. Right. So you need to kind of get.
Daniel Boaitey: Yeah. Hehehe. Right, right.
Joy: figure out what your company needs most right now and how do you build that? And the idea is like, not that you necessarily do something hackily, like, but maybe you do, but, and if you do, then like maybe how do you build it in a way that it's easy to undo later or easy to improve later or something like that, even though it's not the perfect thing now.
Daniel Boaitey: Yeah, yeah. I'm curious in understanding what matters for the company ⁓ and even earlier talking about having impact across teams and understanding what those bigger problems are, what are the ways that you found over time to have that awareness? What the problems that are not just in a specific team but are affecting whole work, what do you kind of do to maintain your awareness of that?
Joy: I would say when I was at Box, I'm thinking back to then since that's when I made the leap originally, but ⁓ there were a few things that helped me out. ⁓ We had a very strong women in tech group at Box, which I was a member of, which it was a good way to have a few connections already on a lot of different teams. like it was through that group, was...
Daniel Boaitey: Right. Mm-hmm.
Joy: like low stakes to just have a conversation with somebody and be like, ⁓ what are you working on? Like, how's it going? Like, what are your problems? What are you facing? So there was that group. ⁓ There was also, like I mentioned, I ran with some other engineers. So like on those runs, we also would talk about stuff. And like, again, it was cross-cutting group. So I guess looking for like even things that look like social things, sometimes I can feel like superfluous or like, why do I need to do this at work? But like, it's actually pretty good for building connections.
Daniel Boaitey: Yeah.
Joy: with people you never would otherwise and sort of learn what they're working on and like learn about the problems. Even like it, like you might not do anything with any of them, but at least you have a little bit more awareness of what's happening. ⁓ In terms of something a little bit more directly job related, I also was a member of the API committee at Box. We had like one group that was responsible for like API standards.
Daniel Boaitey: Yeah. Hmm.
Joy: public API specifically, standards across the entire company to try to make sure that we had a very consistent API going forward. ⁓ And that was also a really good way to get some insight into what a bunch of different teams were working on, as well as get connections with people from a bunch of different teams. ⁓ I remember when I first joined, I was like, I don't know if I'm qualified. I don't know if I should do this. But in retrospect, I'm like, that was one of the smartest things I ever agreed to do.
Daniel Boaitey: Yeah Wow.
Joy: So yeah, it's like one of those things that like, if I could go back and tell myself like, yeah, definitely do that because I mean, APIs themselves are useful. I learned a lot, but also yeah, those connections like I was mentioning and the ability to like learn from people and like be able to influence people on other teams is super valuable.
Daniel Boaitey: Yeah, yeah, that's, it's cool to see how like, there's a bit of a range there, like the casual, social, and then like more like official, like work capacity. Jumping, like a little technical, like you talked about APIs. I know you also talked lot about like future flags and what's it called? Microservices versus monoliths. Sort of a general. theme maybe of change management. I'm just curious like what your thoughts are around migrations and like shifting systems from, you know, we're here and we want to get here and being able to like really do that well I think, because obviously it can be a lot of like failure states and a lot of fear even around like making big changes when you have like an API. It's like, okay, we're gonna, you know, people are gonna not be able to do XYZ thing or yeah, you know, there's gonna lot of motions around monoliths and microservices.
Joy: You
Daniel Boaitey: So I'm just curious around ⁓ just thoughts you have around migrating and making change technically.
Joy: It's funny, I feel like the more of these I've seen, the more I'm like, ⁓ do we really have to? I'm like half joking, ⁓ but not totally because I feel like I've seen a lot of these like not fully get there. Like I've been a part of a number of like, especially the big migrations where it's like, we're gonna do this thing and we get partway and then that's that. Which in some cases is totally fine, I think. Like monolith to microservices, that shift. I, well, there's a whole movement the other direction, but we're going to ignore that for a minute. Assuming, assuming you want to make that shift. ⁓ Typically like at Box, we, we've got it. I don't know. We got it down partway. They're still working on it technically, but when I left, ⁓ we had, we had decreased it by a chunk and like all new services were being built outside the monolith. And like, in some ways that was kind of good enough. Like monolith was no longer a major problem.
Daniel Boaitey: Yeah. Hmm.
Joy: in the way that it had been, like there was no longer the like problem with a billion engineers working in one code base and all of the like merge conflicts and like deployment problems that we were having. like in many ways, monolith was still annoying to work with. It was still spaghetti code, like blah, blah, blah. But like there were just a lot fewer people working in it and like it kind of mattered less. And so like on some level that was a success even though it didn't totally finish. So. I think there's an interesting question there too of like, what do you consider good enough? What do you consider done? And yeah, it's accepting partially done stuff is sometimes important even though it feels wrong. ⁓
Daniel Boaitey: Yeah. Yeah, yeah, you might have gotten enough value out of the thing that's not all the way there, like all the way as the initial goal intended.
Joy: Yeah, yeah. Yeah. When I was at Split, started this big effort, well, a couple big efforts that never really got anywhere. But one of them was trying to build a new public version of our APIs. And we actually got like, I don't know, three quarters of the way done. And then...
Daniel Boaitey: Mm-hmm.
Joy: And then we got acquired and like priority shifted. But ⁓ that was interesting. Like that one was interesting in terms of you have to get like basically the entire engineering on board and you have to like lay out how this is helpful to the company, why this is important. And then like thinking about the migration itself. ⁓ Yeah, like I guess we were,
Daniel Boaitey: Hmm.
Joy: we laid out the new standards and then you start designing all of the new stuff and then you start building the new endpoints and then you put in place policies such as new features are only built on the new endpoints and then we're gonna slowly start to deprecate the old stuff and all of that piece.
Daniel Boaitey: brain.
Joy: Yeah, I guess it's less useful since we didn't actually get there, but... Yeah.
Daniel Boaitey: Outside Forces came and played, yeah, yeah, yeah. ⁓ But no, that's kind of helpful. I appreciate the thought around like, sometimes not getting there is actually okay. ⁓ I feel like that's ⁓ maybe a really big thing because it's true, I feel like with a lot of those types of things, there's usually, there's some painful thing that is triggering the desire to do whatever. So if that pain has lessened, even though you're not all the way there, like.
Joy: Yeah.
Daniel Boaitey: for all intents and purposes, maybe you've accomplished your goal, ⁓ just not in the way intended. ⁓ Cool, I wanted to ask, ⁓ you mentioned women in tech a box. ⁓ I was curious, being a woman in tech, and I can relate as being a black person tech.
Joy: Yeah, yeah.
Daniel Boaitey: Having an identity that's not as common in the industry, right, ⁓ makes for potentially a unique experience. I'm wondering if you feel like that influenced or affected your journey in any way and kind of how you have responded to that over time and ⁓ any thoughts you have for others that have an identity that isn't as common in tech.
Joy: Yeah, in many ways I think I got really lucky at Box because like I mentioned, we had a really good group there. And honestly, a lot of those women I'm still friends with, like pretty close friends with in some cases. And I was talking to a mentee of mine and she was asking about like, do you see a lot of people leaving technical positions, leaving tech? I...
Daniel Boaitey: Hmm.
Joy: I sort of anecdotally know that a bunch of women drop out, but like amongst that group, none of us have. And I think part of it is because we have each other and we like sort of know that there are people out there for us. So I think building up those connections was super important for me. ⁓ I mean, I think there's aspects of being willing to stand up for yourself, like recognizing.
Daniel Boaitey: Yeah.
Joy: I don't know, there's like this delicate bounce, right? Of like recognizing when stuff is happening that shouldn't be happening, but also not like over-focusing on it because like, then you just get angry and there's not a lot you can do. But like, I think there's some things like that same API group I was talking about, I noticed ⁓ in one meeting that I would mention, there were a few meetings that this happened that I really specifically noticed. Like I would mention something, suggest something and just like,
Daniel Boaitey: Hmm. Hehehehehe
Joy: silence and then somebody else in the room would suggest the exact same thing and then everybody's suddenly like, ⁓ yeah, that's a great idea. We should do that. And like, I was like, this is like textbook guys. Like, come on. And I mentioned it to my manager and he just got so pissed off, which actually was helpful because it was sort of validating in this weird way of like, okay, I'm not just being annoying and like whatever, but I ended up not really doing anything with that. But
Daniel Boaitey: Yeah.
Joy: I did really appreciate his support in that moment and like knowing that this is kind of wrong, but this is the way it is occasionally. ⁓ But yeah, I guess like it has affected some of the stuff I've done. Like when I joined Split, they didn't have titles and there's this argument of like, you want ideas to come from anywhere in the org, blah, blah, blah. Like you don't want this like strict focus on hierarchy, but
Daniel Boaitey: Hmm. Yeah. Hmm.
Joy: As a senior woman, I've noticed I don't get taken seriously very well until people either like learn or like, you know, get to know me or if I can throw the title in there, it usually like earns a little bit of respect upfront. So one of my, one of the things I requested was that I would still be able to use a title externally because like it was a small team. So internally I was like, I can get to know these people. No big deal. I don't care. But
Daniel Boaitey: Yeah.
Joy: Externally, like if I'm speaking or something, like being able to put that title there, like causes other people to take me more seriously just upfront. And I find that important. So I think titles, especially are one of those things that help underrepresented folks like get taken seriously upfront a little bit more. And like being able to be like, ⁓ titles don't matter. I don't want a title is like sort of coming from a very, I don't know, like
Daniel Boaitey: Hmm.
Joy: privileged position, right? Yeah, I mean, there's a variety of other things. Part of why I left Tarnas, honestly, was the lack of diversity. So it's not the only thing anywhere, yeah, it's one thing to be, I don't know, on the low end of women. And it's another thing, I was...
Daniel Boaitey: Mmm, that's tough.
Joy: Speaking at a manager's meeting there and there were probably 30 or 40 people in the room and I was the only woman apart from the HR representative and like yeah that was that moment especially I was just like ⁓ I don't know if I can do this like I'm okay with there being like only a couple but like ⁓ being the only one that's especially in a room that large like that's that's too much.
Daniel Boaitey: Oof. Yeah. That's really tough. Yeah, yeah, yeah. Thank you for sharing those different things. I think it's cool to hear that you have that community from Box that sort of, all, in being in each other's world and domain, probably helped you all stay in the industry despite any of those crazy things that can show up. yeah, the title thing, I've definitely, yeah, I heard both sides of that argument, but I think it is so true that it can really...
Joy: Yeah.
Daniel Boaitey: have caused people to have a different perception of you and like legitimize even though it's like unfortunately you shouldn't maybe need that like anyone shouldn't necessarily need that and there should be like haeless talk ideas and free or freely sort of consider whatever people are saying but there can really be an impact on ⁓ you know that that subheading under your name that affects how people see things ⁓ but
Joy: Yeah.
Daniel Boaitey: ⁓ But yeah, thanks for diving into that a little bit. think it's really cool for people to hear from somebody who has made it so far in the industry, ⁓ who navigates those waters, even though like obviously outside of that, like your career is truly incredible. But it is a piece of the puzzle that you had to navigate. So it's really great to hear more about that. I'm going to wrap it up here with two closing questions.
Joy: Hahaha Mm-hmm.
Daniel Boaitey: ⁓ The first question I have, you know, we work in tech, crazy stuff happens all the time. ⁓ I'm curious, what's a memorable maybe production bug or incident that you've dealt with at some point in your career?
Joy: What came to mind for this question was, I actually don't really remember doing much to solve it. I caused it. But this is when I was at Split. So we were a feature flagging company. So we built the on-off switches to emergency turn stuff off, whatever. And I had made, I don't remember, it was like a...
Daniel Boaitey: It works.
Joy: database change or like a query change or something. And I thought I was being super smart because I wrapped the whole thing in a feature flag. So this was not going to take anything down. We could just turn off that flag and be fine. The thing I didn't think about was that ⁓ I took down the database, which meant that we couldn't turn off the feature flag because we were using our own product. there was absolutely no way to turn it back off even though in theory there was, which is this funny moment of like,
Daniel Boaitey: Mm-hmm. Hahaha Yeah Yeah, yeah.
Joy: I don't know, I learned a lesson about like dog food, like yeah, of course you dog food, but you also have to think about if like that's gonna actually impact your ability to respond to incidents at the same time.
Daniel Boaitey: Yeah, that's pretty funny. Actually, I had a question. just thought of, you haven't noticed, that's fine. Like while you were at Split, what's maybe the craziest feature flag use case you heard about from a customer?
Joy: They were trying to do all kinds of stuff and we were like, our sales team was so creative. They were like pushing weird stuff that like as engineers were like, ⁓ why would you do that? But they were like, we had some stuff like dynamic configs where you could like include instead of just being yes, no, it would be like, if this, would return like some arbitrary piece of code or something. Yeah.
Daniel Boaitey: Mm-hmm. guess stringer
Joy: So there was a use case around like you could just put like a banner in your thing and just change the message using a feature flag for certain customers. So like if there was I don't know if you're a delivery company and there was like snow in Boston you could just like put up a banner for the people in Boston being like your delivery might be slow today. Sorry or whatever. ⁓ It might be. ⁓ That's obviously not the craziest. I'm having a hard time remembering the craziest but
Daniel Boaitey: Yeah, yeah, yeah. ⁓ all good. All good. I know the what's it called? Extreme adjective there. ⁓ But yeah, we can move on. So last question here. ⁓ If you had every engineer, you know, that's trying to be stuff plus in a room, what would you say to them?
Joy: You Probably sort of similar to what I mentioned before in terms of a lot of it's about ownership, like trying to trans, like switch your thinking from like me and my career and how do I, I get better into more of like, I own this product, I own this or maybe product area and like, I am responsible for this thing and it. Given that I am like responsible and maybe even the whole company, if I'm responsible for the whole company, what is the best thing that needs to happen for that? And how do I help us all get there? Honestly, it's not just about lifting your own boat. It's about lifting others as well. have, there's a few folks that I've worked with over the years who like want to get to the staff level or like when I worked with them, they were trying to get there. And like, that's a pretty common piece of feedback too is like,
Daniel Boaitey: Mm-hmm.
Joy: they're doing great themselves, but they're not really lifting their team with them. So it's kind of not just about you, but how are you enabling, or maybe it's mentorship, maybe it's like building tools that everyone can use, but like, how are you enabling your entire team and area to improve, not just yourself?
Daniel Boaitey: Hmm. Yeah, yeah, that's a great piece of advice ⁓ that I'll be taking for myself too. ⁓ But yeah, thank you so much, Troy. This is a great conversation. We got to dive into a lot of stuff and there's more we could have talked about. ⁓ You've done really cool things, but I really, really appreciate it. And yeah, we'll wrap it up there.
Joy: Yeah, yep, thanks for having
