REIN: Welcome to Greater Than Code. I'm your co-host Rein Henrichs. And 'm here with my friend, John Sawers.

JOHN: Thanks, Rein. And I'm here with our guest, Denise Yu. Denise is a senior software engineer who career-switched away from law and policy in 2014. In the last five years, she's worked extensively on a number of different products that aim to improve the application developer's experience in a cloud-native world. She spends her free time on community organizing, speaking at conferences and making tech doodles that try to decompose complex subject matter into fun cat drawings. Welcome to the show, Denise.

DENISE: Thanks so much for having me. I'm super excited to be here.

JOHN: You knew how this is going to kick off. We're going to ask you, what is your superpower and how did you acquire it?

DENISE: I think, I don't know if this is a superpower, but I am a classically trained musician and I'm really, really good at transcribing music in my head. So most songs I listen to on the radio, like pop songs, whatever, anything that's melodic, I can pretty much figure it out on the piano and write into score pretty much right away.

JOHN: That's pretty impressive.

DENISE: Yeah, it's not really a superpower. It's more just an ability that's been trained through many hours of forced piano practicing, courtesy of my mom, growing up.

REIN: [Laughs] I figured out by accident that I have perfect pitch a few years ago.

DENISE: Cool. I'm jealous. I wish I had perfect pitch. I had relative pitch only. Perfect pitch is a cool skill to have.

REIN: So, it's kind of like a superpower.

DENISE: I've heard that it's a superpower and also a curse.

REIN: Mine isn't really very well developed because I haven't been doing a lot of music but I found out because I was like, "Oh, I knew what key this is in," because I was listening to some piece of music.

DENISE: Oh, wow. Okay, that's really cool. One of my friends that I played in orchestras with growing up also had it and it just bothered her to no end when any instrument anywhere in the orchestra was off key because she could tell. She could pick that out from the whole everybody playing.

JOHN: Yeah. I can imagine that would be like a sort of auditory sand in everything you're listening to.

DENISE: Yeah, pretty much.

REIN: I don't know if you know who Jacob Collier is, but he is a sort of music savant who is ridiculously talented. He has perfect pitch and he can do a thing where he can sing the notes to a chord in perfect pitch without any reference point.

DENISE: That's pretty impressive. My brain first interpreted that as he can sing a chord, which is like, whoa.

JOHN: I mean, that's kind of like the throat thing.

DENISE: Yeah. That is a wild ability. I've seen recordings of people doing that and it just blows my mind. I don't know how that's physically possible.

JOHN: I actually saw a band about a month ago called The Hu. They're from Mongolia and they do that throat singing.

DENISE: Was it pretty cool to see it live?

JOHN: It was. And they're basically a metal band but then all their lyrics are in Mongolian and using the singing technique. So, it's a heck of a show.

DENISE: I think I've heard of this band before, like a Mongolian metal band. Yeah, I think I've seen their videos on YouTube.

JOHN: Yeah. They seem to be getting a lot of play. So I know in the past you've talked about glue work and I think it's a really important concept for people to understand. I've shared it with people who have been like, "Oh my God, I understand this whole aspect of things now." So, do you want to talk about that a little bit?

DENISE: Sure. The term glue work was coined by Tanya Reilley maybe two years ago. I first saw a talk by Tanya when I was attending a conference called Write/Speak/Code in New York City in the summer of 2018. And Tanya, when she delivered the talk, I was looking around the room and just seeing people, like the expressions on their faces. Every single person was kind of like, "Oh, so that's what happened to me. So, that's why I didn't get promoted. So, that's why I keep getting this strange feedback that my male peers aren't getting." So glue work is the concept of doing tasks that are adjacent to coding when you're working on an engineering team. But it's the kind of work that people that -- first of all, there are a couple of characteristics of the work. First of that is vitally important for the team. The team functions less effectively as a unit when glue work is not being done. And people who depend on the team, like customers, users, collaborators, they're worse off if certain types of glue work are not done. So it's something that definitely has value, but that value can be very difficult to measure.

Some examples of glue work are scheduling meetings like team health checks. That's an example of a more process-oriented piece of glue work. Or it can also be things like making sure that documentation gets written, making sure that release notes get written. Maybe writing the documentation and writing the release notes yourself if nobody else is doing it. That's an example of externally facing work that I would consider part of your product surface area, but a lot of engineers don't consider it a part of their job. A lot of engineers sort of shrug and say, "Well, I'm responsible for writing code. That's not code," which I think is an unfortunate attitude to have because code is not the entirety of the product. So people who tend to get pushed into doing glue work tend to be people from one or more marginalized identities. A lot of the time, it falls to women on teams. It falls to people of color. The way that someone summarized it for me is that, I thought, was a really, really great way of framing it. Glue work is picking up work. So the people who to do it are people who are already used to picking up for other people in other spheres of their life maybe. So a disproportion that a glue work gets done by people who are not, you know, the white guys on the team. And when you find yourself doing too much glue work, it's very, very common to receive feedback like, "Oh, your performance is really strong this quarter, but we're not going to promote you to senior engineer or we're not going to promote you to the team lead role because the work that you did wasn't technical enough."

REIN: I've heard it described as the work that no one notices until it's not happening anymore.

DENISE: Yup, absolutely. That's a great way of putting it.

REIN: I remember I went to work with a startup a while ago and one of my first experiences was that the person who showed me around the office and where my desk was and made sure I had all the equipment I needed. I didn't know this cause no one told me. But very shortly afterwards, I learned that she was a director who was just like functioning as an office assistant because they thought that was an appropriate thing for her to do, probably without even thinking about what they were doing. Anyway, that experience, that startup wasn't great for me. But that was one of my first experiences with, they're really treating her like the help and she's actually one of the most senior people in the company.

DENISE: Yeah, I see that pattern a lot. I often see senior women being asked to take notes in meetings or set up the meeting event and things that are kind of this undifferentiated, I don't know, toil that anyone on the team can do, but it keeps landing on like the same profile of person over and over again.

REIN: And I don't think that it was a conscious thing and I think that's why it's so difficult to deal with. I don't think anyone was like, "Let's make this person's life difficult by giving her all this crap to do instead of her real job." I think it was like, "Oh, you need a charger. Go ask her." And that just became the thing that you do. She became known as like the person who could help with that.

JOHN: Yeah. And then she gets interrupted all the time and has to do all these other tasks and isn't as effective being a director of engineering as she would have otherwise.

REIN: There's also the stuff that's more relevant to the work, but it's sort of next to the work. So things like keeping track of what's going on in the issue tracker or making sure that meetings have agendas or, all this stuff that helps the team function but doesn't appear on your performance review.

DENISE: Yeah. Some companies use skills matrices to assess, like if you're a senior engineer, here are five different categories and you should be performing at this level of proficiency for your coding and your leadership and whatever the categories are. There's often no box, like no mention even of the kinds of tasks that fall under the umbrella of glue work.

JACOB: Hi, I'm Jacob. I'm joining in late.

REIN: Oh, hey. We're talking about glue work. Have you been listening for awhile?

JACOB: Yeah, I have, but I'd sort of been waiting to jump in for a second. But no, I was just thinking like maybe you touched on this earlier, it's interesting, it's called glue work and not like, I don't know, scaffolding work. Because when I think of glue, I think of something that is like a broken vase that has to be glued back together because I've definitely worked at places where it was, no one assumed the responsibility of stuff like that. But eventually when things went awry because no one took on that job, someone else had to glue things back together because stuff broke and that glue work took twice as much energy.

DENISE: Yeah, totally. I think there's also the executing the work itself, but there's also the ability to identify that there's work to be done. There's this comic by a French artist that I can't remember her name unfortunately, I'll dig it up afterwards. But the comic basically depicts a couple where the woman is doing all this housework and she's juggling like with the baby and laundry and cooking and everything. And her husband is sitting on the couch and she's saying to her husband, "Hey, can you help me with the baby?" And he's like, "Oh, why didn't you just ask?" But the point is that people should notice that something is broken and that other people on the team need help and that there is this genre of work that's not being picked up by anyone right now.

REIN: And also that there's this assumption about who the default person is that would do that work.

JOHN: Yeah. That comes back to the concept of emotional labor, which is something that I only learned about a couple of years ago and then have since dived into because it's such an interesting thing. And that emotional labor is the work of caring about how things are working and how they're getting done. And because you're doing that, you notice the things that need to happen and aren't happening and that sort of thing. And like you were saying, a big part of that is not just waiting to be told that something needs to get fixed in this way or that way, but actually proactively going out and noticing that and doing the work to fix it. There's a sort of Buzzfeed style video I saw a while ago about a couple living in a house and she's like, "Oh, I'm so tired. I hate doing the laundry all the time." And he's like, "You don't have to do the laundry. This house, this apartment is magical. You just leave your clothes in the corner and the next morning they're folded."

DENISE: [Laughs] Yes, I know the video you're talking about. I've seen similar comedy videos like this.

JOHN: Yeah. The glue code article was, I think someone made either a sketchnote or a video about it. I was mentoring a woman who had just started her first tech job and that was one of the first things I sent her. I was like, "Here, this is a thing. Keep an eye out for it. Don't get stuck with it." I think it's so important to know that that's a thing when you first start, so you don't just end up getting assumed to be the one doing all that stuff. Especially as a junior, you don't have a lot of power to fight back, especially if you don't even know what's happening.

DENISE: Yeah. I think if you send someone a sketchnote, I think I made that sketchnote if it's a really colorful one with like the drawing of the glue, the bottle in the corner.

JOHN: Yes. I'm pretty sure that was the one.

DENISE: Yeah, I made that one while listening to Tanya. She delivered the talk a few times now. So there is a full recording of it online from the lead developer in New York last year, which is where I saw her do it again and that's when I was making it.

JOHN: Nice. Thanks for doing that.

DENISE: Yeah, for sure. Of all the ones that I've just like thrown out onto the internet, that's been the one that's gotten the most engagement by far because I think the topic is one that resonates so, so deeply with people.

REIN: So, glue work isn't appreciated enough. It's not distributed fairly due to structural biases and things like that. How have you personally, what has your experience been with trying to improve that situation? What sort of things have you done and how has it gone?

DENISE: The thing about glue work that really sucks is while it's unrecognized and things like that, it can also be really fun. I actually do get a lot of joy in debugging team problems and doing work that later it would be part of my job if I was the manager of the team. But I'm not a manager of any team. So right now, it looks like it's stuff that I'm spending time. I should be spending this time on engineering, but instead I'm running a team health check or a process retro or something like that. So, it sucks. It sucks that it's fun but it's not productive in the strict career progression point of view through that lens. I would say that just by giving people that terminology has helped a lot. Once you explain to people that there is this whole category of things that are happening behind the scenes and you don't see it happening. When people become aware of it, a lot of people are horrified. They're kind of like, "Oh wow, I've been making the only woman engineer my team run all of our meetings for the last three months. That's probably not great of me." Building awareness is definitely a big piece of it. I also just sometimes talk about it openly in the office. I do a lot of public speaking. I'm not afraid of getting up in front of people and I try to use that power for good, I guess. But gently calling out in a public forum the ways in which if you are a man for example, and you can support women who are on your team, you'd be the one to schedule the meeting or you'd be the person that sticks around after the retro and takes down the Post-It notes and things like that. Or you'd be the person that books team dinner. And when I have female engineers on my team, especially ones who are in the beginning of their career, I actually pull them aside and say, "Hey, don't book team dinners for the first six months that you're here. Or possibly for the first year. Just be aware that there are some things that if you do it once, you will be the person who does it forever until someone notices it." People tend not to notice, which sucks. I wish I didn't have to do that. I wish I could let people spend their time in the ways that they wanted to spend your time. What if someone just gets a lot of joy out of choosing a restaurant and putting together an event that helps the team bond. It sucks that you can't do that without optical harm when you're a woman at the beginning of her career. And I think, when you become more senior, with men that I've trusted or men who have displayed willingness to be an ally in other ways, I sometimes pull them aside and actively ask them to like, "Hey, if you see our intern, for example, starting to do this work, step in and don't let her do that. Unblock her so she can write more code, so she can focus on learning." So, it's worked out pretty well, the times that I've just directly communicated it. But I think also I've been very, very lucky to work in teams that have pretty high psychological safety so far. And I think that's why it works. I don't think that approach would work in every setting.

JOHN: Certainly not. It strikes me that the work of calling these things out and pulling people aside is sort of the low level activist work against the system to try and make corrections at that level. But the structural change that needs to happen is expanding the definition of the roles of developers to include these other columns of activities such that they can be included in there and evaluated in the promotion capabilities such that then everyone can be doing it and everyone can feel good about doing it and if that's something you're really good at and enjoy, you can excel at it in addition to your coding without it hampering your career.

DENISE: Yeah. I think one interesting thing that sometimes gets lumped into glue work is working on diversity and inclusion efforts, which makes me really sad to hear because I'm kind of like, "That shouldn't be glue work. That should just be part of, especially if you're a team leader and manager, that should be part of your job." But if you are anyone on a team, you should make it a priority to care about this stuff.

JOHN: A hundred percent agree.

REIN: It seems like there are two sort of high level ways that you could try to address this. One is trying to change incentive structures that make it so that this work isn't valued or isn't rewarded. And the other is to acknowledge that the work isn't valued and rewarded and that as a mid level engineer on a software development team, the work to change [inaudible]. The other option to me seems to be to try to distribute that work more fairly and that seems to be the thing that you have been talking about focusing on, not like going to the VP of engineering and trying to convince her that this is a thing. But talking to your teammates about, "Hey, did you notice that this work is happening and that it's not being done equally by everyone?" And, "Hey, you could do more of this and he could do less of that," and things like that. So this seems like a very pragmatic way to approach the problem.

DENISE: Yeah. I think people who are used to doing glue work also are constantly worried about burnout and they maybe have a more calibrated than average sense of like how many spoons do you have left or how much energy do you have left? And so, I love the phrase you got to put on your own oxygen mask first. If you are fighting huge battles and constantly trying to use your political capital and talking to VPs about local problems, then I think you're going to run out of energy before you see change. And I think that seeing change and getting their feedback is incredibly important to continuing the fight.

REIN: Yeah. I always think about thinking globally and acting locally, even if what I ultimately want is for the companies to structurally change. If I can make life better for the people next to me on the team, then I've done something meaningful.

DENISE: Yeah. I 100% agree with that. Like if I can convince my junior engineer to stick around within the company for another year within the industry for five or 10 more years, then that's a successful outcome.

JOHN: Definitely. So you mentioned burnout just now and especially about the people that are particularly tuned into their own emotional labor and possibly because they're in underrepresented minorities which tend to, you have to develop that as a survival skill. So burnout in general is a pretty big topic, but do you have any more thoughts on how that sort of interplays with all of this?

DENISE: I have been pretty burned out this past year and I'm not an expert in burnout. I've seen some talks from people who are like mental health professionals and actually spending some time doing that kind of research and exposing yourself to the data, like the science driven side of it has been really, really useful for me. But in terms of how I've been feeling the past year, one of the reasons why I figured out that I was burning out is because I wasn't letting myself do any glue work. Actually, some of the feedback loops involved in doing glue work were almost like dopamine hits and that was one of the things that made me excited to come into work and excited to do stuff for the team. And so, I realized even though a lot of people talk about doing all this extra work and taking on this extra emotional toil as a recipe for burnout, I agree with that. I think that not saying no or just having a lot of extra work and things to think about pushed on you, it can definitely be very, very unhealthy. But at the same time, there are some tasks.

For example, I mentioned earlier I love facilitation. I love when the team gets in a room and talks about something and truly works through a problem together. That's the kind of thing that makes me excited to come into work. And I wasn't letting myself do any of that because I took this sort of hard line approach of I am not going to do glue work for a year. I'm going to focus on engineering and prove myself as a technical contributor. And then after that, then I will maybe start to do a little bit of glue work again. But that was hard. It was hard to come in and focus on the engineering and bring 100% of myself of my focus to that because the things that made me happy about being at work weren't happening anymore.

JOHN: Yeah, it's like there's a conflict there between bringing your whole self to work and the parts of yourself that really enjoyed doing that sort of thing. There's definitely a tension there. I wonder if part of the key or part of the difference here is unacknowledged glue work or emotional work versus if it's something like you were saying, even if you were doing it even at a micro level, it's being acknowledged and you're getting those dopamine hits from doing the cool thing like that. Again, seeing that success, seeing things work, that is a great end to do, at least in my mind, against the burnout.

DENISE: Yeah, totally agree with that. It's like the advice that people sometimes give for if you have a lot of different loans to pay off, like pay off the small ones first so that you get that forward momentum, that encouragement to keep going. Don't take the biggest loan to pay off even if it's the highest interest one, doesn't matter. Just figuring out your repayment, you can mentally keep going.

JACOB: Something else I'm hearing is maybe a distinction between levels of glue work by which I mean like there's probably a difference between being a note taker and being a facilitator. Because I think one, you sort of have the power to shape the system and one you're sort of just maybe keeping the system running but you don't get a chance to really improve it. And I love that opportunity too. I really like thinking about ways that can make just developer experience easier technically and otherwise, just removing those sort of little frustrating things. Those are the things that don't directly result in my company getting paid, but I just love doing them and I'm sort of starting to wonder if that's glue work, too.

DENISE: Yeah, I would say it probably is. I think I've heard from a few people that their experiences of burnout has been when the feedback they've been receiving at work is out of alignment with the things that they need to do to be successful. And I think if you are, I don't know, there are definitely certain types of glue work, like certain things that can be impactful and can be in alignment with your growth goals. I think taking a general blanket approach of 'I'm not going to do glue work' isn't going to work for everybody. So you've got to make decisions about how you spend your time at work. And I think over the past year, I've been trying to make decisions that let me be happy and also let me feel productive. And sometimes those are completely different tasks and I just try to do different tasks throughout the week.

JOHN: Yeah, I mean, I also feel like that sort of conundrum happens as a manager too. I only recently took on the role and most management work doesn't feel productive because the feedback loops are so long. And so, I still do development work and you get that very quick 'yey, I finished the whole ticket in one day' stuff that makes you feel like you're making progress on things and you're really producing things. And it's really important to get those little hits of 'no, I am actually making a difference making progress' in order to feel like there's any point to it at all.

JACOB: I wonder if one of the factors at play could be, to what extent do top level managers know who's doing glue work? Like to what extent do they see that, so they can incentivize, at least hopefully.

DENISE: That's an interesting one. One thing I forgot to mention earlier is another thing that I try to do, especially for women and people who are from marginalized identities on my team is I try to write more feedback for them than their managers expect to receive. Because I sort of live strong. We buy this assertion that the only way you can combat subconscious bias when it comes to assessing a person's performance is with data. You just need so much data that you can't say no to promoting this person. I have mixed feelings about writing feedback about glue work that someone does because on one hand, if it's not on the skills matrix, a manager might say, "Why is she organizing meetings? She should be writing code." But on the other hand, if you write the feedback in a way that emphasizes the impact of that work rather than the work occurred. So you tie it very, very strongly back to outcomes for the team. And sometimes you can find things to measure. So if someone spent a long time on documentation, for example, you could look at the number of support tickets that were raised for this area of the code and then look at the number of support tickets after the documentation was approved. So there are ways. It's hard work to go and hunt for metrics like that and you may or may not even have access to ticketing systems, for example. But you can at least finger in the air and say, "Well, the whole team, we really needed to have this conversation. There was this systemic problem with the way that we were working because this person facilitated this meeting, got the whole team into a room. We've been more experimental, we've been more iterative. People have been coming in earlier to work." All this stuff.

JOHN: Yeah, that's a really great reframe to tie that into actual objectives rather than just it's the invisible thing that happens so that the whole team just works better, but it's not quantified [inaudible].

DENISE: Yeah, exactly.

REIN: I'm going to have to slightly disagree here. I think that this drive to quantify the results of our work will always devalue something. I think that at any given time, a team is doing all sorts of diverse forms of work, and any set of metrics that you have will quantify only some part of that work. And so, maybe you want to try to quantify some things that are considered glue work, but that doesn't mean that you are actually measuring glue work. It means that you're measuring some specific thing and that thing is only a proxy for the real work that's being done. And so, I think that qualitative ways of evaluating performance can be just as important for teams.

DENISE: Yeah, I think I definitely do agree with that. I think it takes a pretty progressive management team to take a step back and say almost, I don't want to say like take qualitative input seriously because I feel like that's not giving a lot of credit to management teams, but I guess whenever I can, I try to give hard data because we live in such a product driven environment where we, like a lot of the companies that I've worked with have tried to productize everything. It's like how do we make data driven decisions when it comes to forming our teams, when it comes to hiring people and promoting people. And I think at some point, I don't know exactly when my brain just sort of like flipped the switch and said, "All right, [inaudible] play at that game. I'm going to hit you with so much hard data that you can't not promote me or you can't not promote this person." I think that it is a bit reactionary and I think now that we're talking about it, I think it's been an evolved defense mechanism in response to the reality that not all management teams are receptive to qualitative input. Or even comments like, "Hey, have you considered that the way that we assess people is flawed?"

REIN: Yeah, it's very context dependent. If you're working in a team where the only way they know how to measure performance is through quantitative means, through metrics and things like that, then that's the framework you have to work with. I think it is worthwhile to put some effort in, especially as you become more senior into convincing the people who are measuring things that there are other ways to measure things as well.

DENISE: Yeah, definitely agree with that. I remember taking a lot of classes back in my policy days where pretty much every single public policy that's ever been developed is, you're not solving the problem by collecting data. You're getting better at doing the things that you're collecting data on. And so, that's led to some pretty ridiculous policy outcomes in pretty much like everywhere.
 
JOHN: Yeah. I'm glad you pointed that out. I think the word I was going for much more so than quantify was reify to make it visible and concrete and part of the system rather than just sort of the ether that the system swims in.

REIN: Virginia Satir has a motto that I like a lot. I told you I was going to quote her. And it is make invisible things visible, make abstract things concrete, make implicit things explicit and make covert things overt. And one of the things I think we're talking about here is that glue work is covert. Glue work is sort of below the water level of the iceberg of stuff happening on the team that we're aware of. There's a lot of stuff that's happening down there and there's stuff that we can measure is the stuff that is generally above the water level. It's the stuff that you actually are most aware of. And so a lot of this for me is, this goes back, Denise, to what you were saying pretty early on is how do we make people aware that this work is happening and that it's valuable. And so, maybe a targeted metric that expresses the value of some of that work helps, but I think it should be part of a more comprehensive plan. I think it's a systemic problem that needs a holistic solution.

DENISE: Yeah, I wish that there was a way for teams to, this is kind of a cynical way of thinking about your role on a team, but I'm always thinking about how to off-board myself from teams, first because I like switching teams. I like switching around and working on different projects, but also because it's so easy to have just so much tribal knowledge built up in your head that when you leave it's going to be painful for the rest of the team to figure out where everything is.

REIN: Yeah. And even while you were there, this is knowledge that no one else on the team can benefit from except in the very rare cases where you share it.

DENISE: Yeah, absolutely. Exactly. So, I always try to figure out like if I'm out of here in two weeks, what are the things I would have to hand off and how can I start just documenting them and start handing them off to other people. Because I'm probably doing too much stuff anyway. I probably shouldn't be doing all this background activity without anybody on the team involved. That's just, I think, an anti-pattern for not just process things but on engineering teams in general. You should never have only one person know part of the system.

REIN: Also by the way, if you do this, it's easier to take vacations and you should take vacations.

JOHN: And those can actually be a pretty good way of test running how well you've done at that is the, "I'm gone for two weeks. Let's see what shows up that we need to address."

REIN: Yeah, it is, "I'm going on vacation. Okay, a month out, let's start planning for the hand-off." Or is it, "Okay, so what things are you working on and who's going to work on them? Okay, bye."

JACOB: We've been talking a lot about people, developers, "technical people" that sort of step up to do this glue work or don't step up to do it. But I wonder, should we be also be talking about like it's an expectation from managers that it's like, "Hey, we need somebody that's going to sort of figure out how we're going to improve our ticketing system," or that's just an example. Do we need to be thinking about that too?

DENISE: Yeah, I think so. One of the recommendations that Tanya makes in her talk, like one of the pieces of advice she gives to managers is treat glue work like real work and prioritize it and triage it. Make a backlog for it if that's what you need. But this is exactly like making the invisible visible directly in line with that. The second you start to treat it like real work that can be distributed among the team, if the team pulls from a single backlog, just try to slot some glue worky type cards in there maybe.

REIN: One of the core principles of Kanban is to visualize the work and the reason for that is this: if you see the work then you can see how much there is, where things are, and so on. And if you don't do that with something like glue work that's already harder to see and less valued, then it just gets pushed farther down. It becomes more covert.

DENISE: Yep. And then always certain people are going to spot it and those people will do it.

REIN: Yeah. One of the things that's interesting here is that it's also covert in the sense that some people on the team are aware of it and discussions that happen about it are generally through back channels. So, you were talking about how you will go reach out to a new developer on the team and warn them and things like that. I'm using covert here not to imply anything nefarious, but this is a covert form of communication. This stuff is not happening at the level of -- this is something everyone in the team is talking about.

JOHN: Yeah. It seems like retro is a good time for that.

DENISE: Yeah, that's true. If you feel safe bringing it up in retros, I think people should bring it up. I would say the more senior people on the team should bring up things like this.

JOHN: For sure.

DENISE: I also really like back channels and private communication can be super, super useful, but at the same time, I don't know, if your team is negotiating who's going to do glue work in DMs, then I think that's not good. I think that that's stuff that could potentially be negotiated out in the open, so everyone knows that it's happening.

JOHN: Yeah, and just having the knowledge of what that work is distributed throughout the team also makes the team more resilient so that when the person's gone, it can still happen.

REIN: One of the things that has been somewhat successful for me in trying to get the team to value glue work more is reframing it a bit as helping each other. So Jacob, I think it was you that said, when you think about glue, you think about a vase broke and we need to put it back together. And when you think about it in this sense of glue serves the purpose of taking a bunch of disjoint pieces and bringing them together into a whole. So, glue in this sense is the thing that makes your team a whole rather than just a bunch of people working independently. And so, I think what I've had success with is characterizing glue work as, "Hey, our QA engineer is backed up right now. Who has an idea for how we can help them?"

DENISE: Yeah. One thing that my current team is experimenting with, we noticed that there are a couple of processes that are just so, so painful right now and they keep landing on the same people. So they're are good examples of things. There are still kind of engineering tasks in the sense that you write YAML. Is YAML code? I don't know. Open question for debate. But release engineering is an example I had in mind. So release engineering can be as automated or as manual as you want it to be and it seems that no two teams ever agree on what release engineering even is. So for my team, it means you manage a bunch of different branches, you make sure that all of those branches have passed our automation, our CI pipeline tests. And it also means that you consolidate all the release notes. And it's an open source project, so we try to give a shout out to everybody who contributed code, like writing tons and tons of documentation, making sure that the documentation is versioned correctly with the semantic versioning that we ended up assigning to the release artifact and making sure that it gets posted in like five different places for people to consume. So, sometimes they are very manual. The writing bits in particular can be very, very manual and it was super painful. One thing that I've been pushing the team to do is let's put our foot down and say, "Okay, Jamie, who's been doing this release engineering informal ownership is not going to do it anymore. This is a problem that the whole team needs to solve. Jamie already front loaded the pain by figuring out how all this stuff works. It's everybody else's turn to do that." So, we're appointing a different person who's in charge of release anchoring for every milestone now, which has been really good. I did it a few weeks ago and it was so painful. I didn't know where anything was. And of course I interrupted Jamie every 30 seconds to say, "Okay, what does this task do? Where do I find this thing?" But it was good. And one thing that I'm trying to model with the team is if you had to interrupt someone to get an answer to a question, write that down for someone else for the next time. So, we have this massive document, it's like six pages long, which is embarrassing for a release engineer. Also another smell, smell that the process is too complicated right now.

JOHN: I always enjoyed the anecdote that in finance related domains, you're often forced to take two weeks of vacation together once a year such that if you're committing fraud and covering your tracks on a regular basis, that stops happening in a peak and that becomes visible also.

DENISE: That's amazing. I have heard that before too.

JACOB: Yeah. Like the books suddenly just magically have different numbers on those two weeks. Yeah, I've heard that.

REIN: So what you do is you just stop committing fraud on random two week intervals throughout the year.

[Laughter]

DENISE: Resilient fraud.

JOHN: You mentioned a little while ago about how it's a trend for companies to come very, very product-focused and sort of turn everything into a product. And you spent actually a little bit of time as a product manager and I think learned some things from doing that. Do you want to talk about those a little bit?

DENISE: Sure. In the office that I was working in last year, at some point, we more or less ran out of product managers because people either got promoted or left the company. And too many people did that at the same time. So there were a couple of vacancies and they couldn't fill them fast enough. So I sort of looked around, I was an engineer at the time, I raised my hand and said, "I'll do it." People looked at me like I was crazy, but I was like, "No, seriously. I want to try. Give me one of the teams that's a little bit more formed and a backlog that's in good shape, but I think I can do it." So they decided to give me a chance, which is very generous of my managers at the time. And it was such an interesting experience being -- so, I work at a company where engineers work in pairs by default. So it was interesting going back to solo work. It was pretty lonely for a while, but I think a lot of product managers feel lonely because you have a completely different way. Like you spend time totally differently than how engineers spend time. Engineering time, in a lot of ways, is very structured. It's regimented but not in -- I'm trying not to use that in a negative light. It's well structured, it's well defined, so you know between these hours you're probably going to be doing feature work. You know that at this time on Friday, we have our team retro and at this other time during the week, we have daily stand ups or whatever it is. As a product manager, all of that structure just goes out the window because your job more or less is to be interrupted.

And I also hope that this doesn't come across too negatively, but you're the first line of defense for when anyone needs any context from the team. Your job is sort of to remove blockers and make the team high functioning so that engineers can focus on doing engineering work. And if they don't need to be interrupted, if it's a question you can answer, for example, from the support teams, then your job as the PM is to be that resource. So, it was fun. I went on to a completely different team which is a team I never worked with before. So having to learn a brand new product domain, [inaudible] was interesting. It was fun though. But I think the part of the job that I enjoyed the most actually was talking to stakeholders, like getting out into the wild and talking to customers and getting to know who they are and getting to know who my team's collaborators are, and just having like direct conversations about like, "What's painful for you? What are you currently doing today? How are you using our product?" And just getting that sort of very, very high level inciting going back to the team and synthesizing it together. I think once I realized that that was a thing that you could do at this company, I never wanted to go back to a pattern where all I did was put on headphones and punch out code. Because having that, I think that established my -- that sort of answered the why question for me in such a deep way. I always kind of wondered, "Oh, the work that I'm doing is technically very interesting but I don't really know why I'm doing it. I don't know who this benefits." And the second I stepped into the product manager role, all of it started to make sense because I had access to that information.

JOHN: I might argue that your existing product managers weren't doing a great job of explaining the benefits of the work that you were doing in the context in which it's happening.

DENISE: Yeah. That was also another thing that I became aware of.

REIN: I sort of think of product managers as -- one of the jobs of a product manager is to sort of be a membrane around the team that decides what information gets to pass through. So, for example, [fly-ins] asking the team to go work on this big thing, the product manager gets to step in and say, "Okay, here's how we're going to handle that." But then they also get to decide what information gets to flow from customers to the team, to the people working on the team. And a lot of teams at least think that they're being agile, but if the people on the team aren't getting information flowing to them from customers, you can't be agile. So not only the product managers decide what information to shield the team from, to protect the team from, but they also need to decide what information they want to amplify.

DENISE: Yeah, for sure. One of my closest friends in the company who is a very, very talented product manager told me once, she was a really good mentor for me when I went into the role. But she told me that the thing that she's always trying do is she aggressively tries to build alignment within the teams so much so that she could leave for four weeks and the team would keep going without her. I was kind of like, "Wait, are you saying that you want to make your job obsolete? That's not how business works." And she was like, "No, if product managers are doing a good job, you free up yourself from the day to day stuff so you can start to do the interesting stuff which is strategy setting and trying to figure it out. Bigger things like how do I evolve my product to do something totally new and 10 times more impactful." And that's the kind of thing that you kind of need to be able to step away from the day to day to have long unbroken stretches of time to think about.

REIN: Yeah. The other full time job that a product manager has is translating the here and now of what the team is doing and the then and there of what the company's plans are and goals and how the environment it's operating in is changing and so on, and being the conduit between those two things. It is a full time job to protect your team from interruptions and remove blockages and things like that. It's another full time job and honestly it's the most important and hardest job in any organization large enough to need it to happen, which is translating between the then and there and the here.

DENISE: Yeah, definitely agree with that.

REIN: And a lot of product managers that I've worked with, the dysfunction in the organization makes it so that they spend a lot of their time in JIRA and they don't have the time to do their job. And so, the team as a whole suffers for this.

DENISE: Yeah, I've definitely worked on teams in the past where, I think at the point where you're nitpicking over JIRA tickets as a team, your team is already so unhealthy that you can't -- having a conversation that nobody actually wants to be having. People want to be doing work. Yeah, it's terrible.

JOHN: So now that you're back into the development role, how does that influence your day to day or the way you think about what your role is and how you're working?

DENISE: I think one big thing I learned from doing the product management rotation is that most product managers just have way too much on their plate because on most teams, the PM is responsible for doing all the tactical work, the sort of JIRA, like munching if they need to do that, thinking about strategy. And also they were the defacto person for facilitating every meeting ever, which I kind of looked at them as like one person can't do all that. So, since I've been back in engineering, I've been trying to help out PMs with the facilitation bit and some activities involved protecting the team's time. I'll volunteer to be the interim person for a week or so here and there. Or maybe like push for processes that more deliberately distribute that load. Because my goal basically now as an engineer is to help my PM do the strategic stuff, to try to buy my PM that space because that's the really impactful work that nobody else on the team can do. But everybody can facilitate a meeting. Like everybody can write stories. Everybody can perform acceptance. So, I guess it's that. And the other thing that I haven't been able to unsee is this realization that the system that we work in is so data driven. I've been trying to be a chameleon and play more by this implicit rule book that data is gold. So if I want something to happen culturally differently in the company or within the team, I just go hunting for data and try to make the case. That's the defense mechanism that we already talked about earlier.

REIN: Yeah. It's interesting to imagine what it would be like if you could affect change without having to do that. It's difficult. There's an irony here, which is the sort of organizations where that's possible are the ones that are already doing a pretty good job because I have to be for that to be possible. And the organizations where it's hardest to affect change are exactly the ones where like backing yourself up with data is a way to sort of pragmatically get people on your side even though it has unintended consequences and knock on effects that aren't always great.

DENISE: Yeah, definitely. Oh, another thing that I've changed about how I work is I tried to model to other engineers that you're allowed to go to meetings with your PM. You're allowed to go to customer conversations and go visit customers and things like that. So that was like a thing that I didn't know this is a thing I could ask for before I started PM-ing. And out of necessity, I keep asking the engineers on the team to come because, in the beginning, I didn't know enough about the product and I literally just needed them in the room to answer questions so I didn't sound completely clueless about the thing I was supposed to be managing. And over time, we realized that everyone on the team actually really liked that open door policy. I stopped pulling specific people and just telling the whole team at standup, "Hey, I have this customer meeting today, open door if you want to come. If you're in the groove and you want to keep pairing, that's fine. But if you're curious, you're welcome to come."

REIN: Yeah, I love that because one thing that I've noticed is that, and this gets back a little bit to the gluer conversation we were having, a lot of the work that product managers do is invisible to the rest of the team. Like if you look at, for example, the way most people use Kanban boards or whatever, the thing on the left side, the first thing that [inaudible]. But there's a whole thing that happens before that, that isn't tracked generally. It just 'work appears in the board, can't explain that'. And that's actually a significant part of the product manager's job is living in that area that is invisible to the rest of the team.

JOHN: Yeah. And again, making that process more visible to everybody.

REIN: I've even suggested to teams that they either add some stuff on the left of the board or make a new board that can feed into the board that's like ideas, epic stories. That's maybe not the greatest way to characterize the work, but it is a thing that you can see. Larger, poorly defined concepts turn into stories somehow. And that's part of what a product manager is doing. That is like some of the most concrete work that a product manager does is getting things to the point where we can write stories.

DENISE: Yeah. I think some teams that I've worked on and other teams within the company are experimenting with an RFC process to try to surface some of that. And teams are encouraging people to have focused conversations. [Inaudible] in RFC that might exist as an issue on GitHub or use the platforms you're already using. It might be a JIRA story, whatever it is. And it's just like for a period of time, everyone gets input on whether this is a good idea, any ideas around implementation, what's feasible and not feasible about it. And I think that's kind of cool, it's an invitation to participate sooner in the engineering process and I guess at the product development process.

REIN: A lot of the time when I work with teams and I'll do one on one interviews to try to surface some of the feelings that people on the team have about the way the team is working. One of the things I get a lot is we don't really know hat the team is working on past this sprint or how that connects to higher level goals or these questions about, basically product questions and, "Oh, we have a roadmap but no one looks at it. And I think it's out of date." And I asked them, "Okay, do you know what the product manager is working on today?" And they never say yes.

[Chuckles]

DENISE: I wonder if the product manager says yes. [Chuckles]

REIN: Sometimes. But the engineers that don't understand the product direction also don't know what the product manager is doing. And I think there's probably a correlation there.

DENISE: Yeah, that's a very interesting, I think, almost health measurement, health check for a team to do as well, I think.

REIN: One of the things that I try with teams is including the product manager and stand-ups, so then they can say, "Oh, I'm interviewing these customers today and then I'm finishing this work on this epic," and so on. And I'm always surprised by how many teams don't do that. There are a lot of just little nudges that you can find in the direction of making the things that we're talking about more visible. It doesn't have to be some like go to the director of your department and then convince them to X and Y and then show them the data. Sometimes that can work, but sometimes it's just, "Hey, here's a thing that would add two minutes to our stand up. Do you want to try it?"

JOHN: Yeah. So at the end of each episode, we'd like to talk about reflections of the ideas or discussions that have really jumped out at us, things that we're going to be thinking about afterwards. And for me, it's two things. The first one is the distinction that you made, Denise, between glue work that is just work that you're doing, that nobody's paying attention to and glue work that you actually really enjoy and get a lot of satisfaction out of that you're doing. And I think that's an important one because like as you were saying, if you lose that job satisfaction by removing that part of it, that's a really important thing to be aware of as far as figuring out what you're supposed to be doing everyday and how you want to shape your career. But I think the thing that I'm going to take away is I feel like I'm in a position where I can influence our technology ladder competency matrix kind of thing. And I'm going to see what I can do to try and add some of these glue work tasks into the engineer evaluations so that we can make them visible and just part of everybody's job. I don't know what that process is going to take. It'll probably be years. But I'm curious to see where it would go because I think it would be really valuable.

JACOB: I was thinking about just that last thing you were saying about how what if project managers try to be more transparent about what they were doing on a day to day sort of make clear for their team just how many plates they have to keep spinning. I was thinking about one of the PM's that I worked with and she definitely does that. And I was reflecting on, you know what, I think there's probably points where sometimes my VM is listing all this stuff and my eyes sort of just like glaze over and I can't even keep track of all of it, and it makes me sort of want to just check my phone or something. [Chuckles] But I think reflecting on this, like I think there's something I could be getting out of that information and I think it probably starts with really just trying to listen a little bit more and at the very least try to understand more of that minutia about what my PM does and how that probably relates to my ability to be distracted less.

Oh, there's one other thing that I think this is somewhat related. I've noticed that on my team recently, it's become a habit that we've been sharing things in our day that are not related to work at all, but they are self care related. So one of my team members has to get an allergy shot once a week and she will share that not just for scheduling purposes, I mean it does help with scheduling purposes, but I think it helps everyone remember that they have things to do that aren't about work, but just things they have to do to get done during the work day just so they can stay healthy and be a good member of the team. And I think it's good to sort of help each other remember those things, especially when we're on a remote team.

REIN: I want to add on really quickly to what Jacob said and then give my reflection. I think when I was talking about how product managers work is not as visible, I sort of focused on things product managers could do to affect that. But that's not the whole story. So another question that I ask engineers who say this to me is, have you ever asked your product manager to schedule a one on one meeting for 15 minutes to ask these questions to them? Because everyone on the team has the power to connect more with the other people on the team. So I just want to make that clear that everyone has an opportunity there. It's not just that the product manager needs to work even harder.

DENISE: Yeah, that's a great point.

REIN: The other thing I wanted to mention is I have had this theory for awhile and it's really starting to crystallize that I think I've seen you talk about this elsewhere, like maybe on Twitter, but that burnout isn't just working long hours and things like that. It's not just being pressurized by managers to work harder. My theory is that those things are damaging and bad, but where burnout becomes a real danger is when that stuff is combined with what I would call acute alienation. So it's not just that we're working really hard, it's that we're working really hard on things we don't care about. It's not just that we have to do glue work, it's that the glue work that is meaningful to us that in some cases sustains us at work. I love finding ways for teams to come together and connect and help each other. I love that. It's my favorite thing to do. But it's generally not valued in the same way the technical work is. So the work that I have to do, I don't want to do when the work that I want to do [inaudible] disconnect from my work and the products of my work. And it's also me like, I was just talking about how like, why don't the engineers connect to the product managers and just ask their questions. It's because they don't know that's a thing they can do because we're all so alienated from each other. And so, I think when these things combine under this sort of pressure cooker of long hours and [inaudible] from managers to work harder and get more done in less time, then that's where it becomes really dangerous.

DENISE: Yeah. I think I remember Jaana Dogan from Google, JBD first talking about that. I think that's where I first came across that reframing of burnout. And I've been thinking about it ever since as well too. This is a really great conversation. I learned a lot in the last hour and a half. I think the thing I'm going to be chewing on for the next couple of weeks is, and I think it was John who said it, to think globally but solve locally. And I think that that's the most concise version of the way that I've been trying to work, just like summarized. And that's the most concise formulation of my current mindset that I've heard so far. And sort of recognizing that your sphere of influence is only a certain size at a given point in time, and you put yourself at risk in a lot of different ways if you try to reach too far out or if you are trying to solve the right problem but in the wrong place or using the wrong tools. So yeah, that's super interesting. I'm really glad that you summarized it that way.

And the other thing I'm going to be thinking about is just like, I know this is just a blip in the middle of a conversation about off-boarding, but I might end up writing a Twitter thread about this, about the idea to always be off-boarding yourself, because I think that's quite a cool way to force yourself to start thinking about the things you're not externalizing and the things that other people can't help you with because they haven't been visualized and they haven't been made concrete. So yeah, I'm going to be noodling on that one also for a little while.

JOHN: And that was Rein that actually came up with that phrasing.

DENISE: Oh, okay. [Crosstalk]

JOHN: Denise, thank you so much for talking to us today. It was a really fascinating conversation.

DENISE: Yeah, for me as well. Thank you all so much for inviting me on the show.