 I am so happy to share this next talk with you. Alexandra will talk about deploying code without actually sharing any code. Instead, Alexandra will share a set of stories. Both seem successful at first, but when you dig a bit deeper, you realize that the outcomes are actually quite different. Through these two examples, we will learn about the core needs of our teammates and the importance of communication and empathy to address those needs. We will be challenged to rethink our processes and rituals, and ultimately, we will be better prepared to be a trusted colleague to those around us. The beauty of this talk is that while the examples are focused on deploying code, the takeaways apply to all types of work. Whether you write code or not, whether you're a manager or an individual contributor, this talk is full of valuable lessons that will make you a better leader and teammate. Enjoy. Hi, everyone. Thanks for joining me today at GitLab Commit for my talk, The Emotional Chaos of Deploying Code. I'm really excited to talk about this today because I think that code deploys are things that a lot of people talk about from a very technical perspective. I know lots of talks about this, lots of articles, but it's not something that you really hear about from the people side of things and the emotional side specifically. So I'm excited to talk more about what there is around people and emotions for deploys. And to start off, I wanted to address the fact that you might be here watching this talk because you saw this title and thought, like, since when is deploying code is emotional? Like, this is not a thing. And maybe you have a CI CD pipeline where you're releasing code hundreds of times a day. Maybe you have a QA process in place. You have a release manager. I have a release notes. You kind of have this setup that makes deploys very predictable in the technical sense. And you're wondering where does the emotion come in? Like, we have this process. And so if that's the case, I do think that there is room for emotions in your deploys. I think it is there already and it's maybe not something that you're picking up on. And so I'm excited to show you exactly what I mean by how deploys can be emotional and then how to fix things and make things a little bit for the better. So my name is Alexandra Sunderland. I'm an engineering manager at fellow.app in Ottawa, Canada. You can reach me on Twitter at alexandras underscore dev or on my website where I have other resources about this and other technical management types of things at alexandras.dev. I do work at fellow.app where we are doing multiple releases per week. I have worked in the tech industry for the last decade or so and worked at lots of large companies where we do larger, less frequent releases, worked at startups where we do many, many frequent releases. I've worked with a lot of different stakeholders for releases, so worked with enterprise sales teams and direct to customer products. And so I have a big kind of background in lots of different types of releases and lots of different types of doing them. And at the meantime though, I am at fellow.app which is a platform for teams and their managers to take meeting notes, track actions, collect feedback and overall make meetings delightful for everyone. And I highly encourage you to check it out if you're the type of person who has meetings. So the plan is actually not to talk about anything related to code because I think that the emotional side of code is maybe a little bit obvious. I think that if a deploy goes wrong, something fails, you have to stay up all night fixing things. I think the emotional side of that might be a little bit more clear cut and obvious to see because obviously people are gonna be upset and a little bit nervous and kind of scared and I'm sure we've all been there. It's not fun. It does happen to everyone. But I did want to walk through the story of a deploy that has gone wrong, but it's not gonna look like it's necessarily wrong from the outset. Then go over the story of that same deploy gone right and then talk about how we can get from one to the other. So that said, once upon a time, there was some code to deploy. Chapter one, preparing the build. So the engineering team has been working on a new feature in their enterprise SaaS application and it has been decided that it will be ready for clients at some point this week. So very typical situation nowadays. This talk, by the way, is filled with many, many stick art drawings, conveys the emotion a little bit better than any clip art or stock imagery could. So these are all done by me and I hope you enjoy them. Anyway though, so the first person that we meet is Emily, the QA engineer. And Emily is ramping up testing to make sure that the build is ready on time and the engineers push back saying, this is not critical, we'll fix this later for a bunch of the issues she brings up. I am guilty of this too. I think everybody once in a while has this especially in crunch time, but this is what has been happening with Emily. The deploy is also going to be the first time that a feature Maria built is going out and Maria is the newest member of the engineering team. She's tested a lot, but she's a little bit nervous about the process. Maybe nobody's walked her through it. Nobody's told her what to expect. And so this is going to be her first deploy that she's a part of. Chapter two, planning the deploy. Another engineering team in addition to the one that you're on has built a feature for this deploy too and it is now in a broken state. And so we have to sit tight and wait for it to be fixed before we can continue testing and before we can really do that countdown to get ready for the deploy. A mirror for the marketing team also needs to try out the features that are going out so that they can create marketing content for it. But at this point, there's no exact date for the release and so it's a little bit hard to plan for the deadline and schedule posts and get a mirror's work done and test it out on a stable environment. It is then decided at 9 a.m. of whatever day is that the deploy is going to happen at 3 p.m. And Kierthi, who lives in a time zone eight hours ahead and built an important part for this deploy, is hoping to be asleep at that point because it will be 11 p.m. her time, chosen arbitrary number I'm normally in bed by 11 p.m. I know that's not necessarily common, but anyway, so Kierthi is hoping to be asleep by 11 and is wondering if the people who were in that time zone really thought of that when they chose that time for the deploy. The deploy happens, everything goes well in this scenario. I mean, the server stays up, no code goes down, like everything's good, no bugs, everyone celebrates, ta-da. Chapter three, the day after, because the deploy is not over when the code is live on production. There is a lot that comes after that, which is very important. And notably in this case, because we're an enterprise SaaS application in this scenario, we have Dave from the sales team who has their first prospect demo of the day and Dave did not know about the changes and so it throws off their demo The sales people tend to have a script that they follow, like a tried and true and tested path through the app and because the new feature changed that, they don't know where to click, they don't know what's going on, and so it messes them up. Clients are also asking Antonio on the support team questions about the new features and nobody had shown it to them beforehand and so they missed their target SLAs while spending time trying to figure it out while they write documentation. And target SLAs, it's when you have a customer success team or support team, usually you try to keep your response time under a certain period of time, so it might be five minutes, it might be an hour, it might be 24 hours, totally depends on the organization, but if there's something going out that the person who's writing these responses doesn't know about yet, then that increases the amount of time that they spend replying and that's not so good because usually things like your bonuses or OKRs and goals depend on keeping these times down. So the end of the deploy, kind of, sort of, seems mostly okay maybe the day after it seemed to be a little bit more messed up, but otherwise it looks like everything with the deploy went wrong. So what actually happened here? Well, the thing that's going wrong here is that the core needs of the people on the team were not being met and in these situations, like maybe nothing was staring out, obviously, but a lot of people were feeling different things and bottling those up and not surfacing those and asking for help and so people felt a little bit out of place. And so before diving into everything, I wanted to bring up this model, so Paloma Medina has this biceps model, so it covers six different parts, which talks about all of these core needs that we have as humans in communities and at work and within families and when any one of these core needs is being threatened, then we get this fight-or-flight response and we have all sorts of different emotions. We might feel nervous, we might feel out of place, might feel sad and so these seven parts of the model are very important when it comes to anything at work and making sure that whatever you do, whatever you say, you're not doing something that is going to threaten any of these with any humans. And so there is more information about this at palomamedina.com slash biceps. I also wanted to call out a blog post in mind, a blog post that is one of my favorites written by Lara Hogan and it's called Dealing with Surprising Human Emotions, Desk Moves and it's a article that talks about this biceps model in relation to something as trivial as changing around the desk situation. Maybe not as relevant right now, but it kind of gives you that idea of like just changing the layout of where people sit and where they are in relation to each other in relation to the manager in relation to the placement of the washroom. Something as simple as that can threaten all of these items in the biceps model and can trigger that fight-or-flight response for people and so as anyway, it's a very interesting article to kind of give you a sense of just how important the stuff is. I also really like this quote by April Wenzel which says that taking time to care about other people's emotions isn't just kind, it's actually more efficient if it leads to smoother interactions that don't trigger people's threat responses. And I find that very important because in this situation, in this talk like it is, possible to ignore all these motions that are happening. Maybe that's what's already going on. It's easy to just pretend they don't exist and kind of shove it to the side. But if you go out of your way to figure out what those emotions are and correct for them and even just accommodate for them or even just acknowledge that they're there, then it's gonna make it easier for people to work together. It's gonna make it easier to communicate and get things done. And so I just wanted to call this out as something very important because it's like, even though these emotions are hidden and not surfacing, that doesn't mean that they're any less important. So to go over all of the characters in that little story, we'll start in order and go with Emily. So Emily was doing her job. She was reporting the issues and the engineers were turning them away and saying like, nope, that's not an issue. We're not gonna do it in time for the release. So it does not matter. And the corny that Emily, the corny that was being threatened here for Emily was significance because Emily's job for this release is finding errors, making sure that the application is in as good of a state as it can be. And if it goes out and there are a bunch of errors, then Emily is gonna feel like that's her fault and she should have caught them or it feels like it's on her to get that right. And when the engineers are the ones saying like, nope, doesn't matter, that feels like it's saying that her job doesn't matter and then maybe she doesn't matter that much to the team, which is not true. The QA is incredible. And so the corny in here that isn't being met is significance because you wanna feel significant within the team. And so this is what Emily is feeling. Maria the engineer was the newest team member and it's the first time that a feature that Maria's built is going out onto production. And in this case, sometimes it's very easy to not go over step by step exactly what's gonna happen, what to expect, showing people what a deploy looks like. Even if it's an automated process, like I know that there may be some sort of CD pipeline setup with continuous deployment. So you commit some code, it goes live to production. Even just that can feel very scary because you don't know even just like, will it take five minutes to go out? Will it take an hour to go out? Should you start looking at logs? What are you supposed to do? Do you make sure that you verify it on production? Does QA verify it on production, like what goes on? There's a lot to know there. And so not knowing what's coming next can make you feel pretty nervous and threaten that core need of predictability. A mirror from marketing was trying to create that marketing content, but there's no date set for the deploy. And in this case, it's usually a lack of communication and this is gonna be a recurring theme for a lot of the people actually. But the developers aren't necessarily always in communication directly with marketing and with other services and the business side of the organizations. And so in this case, there was a bit of a communication breakdown. Nobody was really letting the mirror know when things were going out. And to mirror the core needs that were not being that or that were being threatened were equality, so fairness and predictability. So predictability, same as with Maria, it's hard because, I mean, here you literally do not know when things are gonna go out. So it is very unpredictable in that sense directly, but equality and fairness also because you're not getting the information that the rest of the team has. Like even if they don't know exactly when the deploy is gonna go out, they can very easily communicate. Like we think it'll be at this point, it's on track for this, or like, sorry, it's getting delayed. And that helps people feel like they're more a part of the team because they feel like they're seen as equals, like their job is just as important as the engineers, which it is. And that helps with predictability as well because even though there isn't necessarily a date set in stone, they know what to expect and they can see things coming. Kierthee, the engineer was the one living in a time zone eight hours ahead and it's gonna be at bedtime during the release. And so the core need not being met here is belonging. And I think that this one is even more relevant now that teams are starting to become a little bit more distributed because we're starting to hire across different time zones. It's a lot easier to have people working remotely or just as easy as before, but we're starting to do it a lot more as a tech community. And so it's difficult though because a lot of companies are still in a situation where a core or a majority of people are within a certain time zone or a very close time zone. Like if you imagine companies in North America with the East Coast and West Coast, there's a three hour time zone difference there. So we're all pretty close together. But then if you hire someone in Europe, they might be six or seven or eight hours ahead or even further. Australia is very far away as well in terms of time zone. But when you have that large majority in one time zone, it's very easy to default to that time zone and forget that people are in another time zone and that it might not work very well for them. And you really have to put a lot of effort into remembering that. And it's to do with everything, like with scheduling meetings, scheduling deploys, discussions like when you use app channel and Slack, when you do group chats and schedule all these things. And yeah, so anyways, to the point here though is that Kirthi does not have that sense of belonging because the group that is in the majority where the time zone is does not always necessarily think of her and they should be. Dave from Sales is the person who did not know about the changes going out or knew about them and didn't necessarily get a chance to see them before they went on production. And it threw off his first demo of the day. This does not sound like a good situation to be in, especially because you're not just suffering on your own like the other people. You're doing this in front of others. You're actively having to come up with solutions on the spot and people are watching you and it's a very high stress situation. And so the core need here that is being threatened is belonging, equality and fairness, those for the same reasons as with marketing and everyone just like not getting that information that the developers have and predictability for the same reason, especially because if this happens once you're gonna be on guard and kind of assume that it might happen in the future as well. And that's not a good feeling to have just always wondering like what's gonna change? What am I gonna have to adapt to? It's not a good place. Antonio from Support was the one who had to catch up writing documentation and misses the target's response times for the team because nobody gave him a demo of the new feature before it went out. Same as with the last few people, core needs here that aren't being met are belonging, equality, fairness and predictability for those same reasons. And like I mentioned a few minutes ago as well, this is especially important from the SLA side where support team, the response time for customers is incredibly important for their goals, their bonuses, it has a big impact. And for cases like this where they weren't made aware of something that was going out or they weren't properly trained on it, that's something that is not their fault for the most part. It is usually on the product and engineering team or people like with the knowledge of what's going on, it is up to them to let them know what is happening so that they can adapt ahead of time and avoid those delays. And so I mentioned this with the time zone issue with QRT as well, but the impact on remote teams in particular is very big because when you're working altogether in an office in person, you get the benefit of seeing people's reactions and seeing how they're acting. And so you can pick up on maybe people look very nervous or they're acting differently than normal so you can pick up on maybe with Maria who is doing her first deploy, maybe you can pick up on the fact that she looks a little bit tense and you might figure out like, oh, I should reassure her and let her know what's going on and what to expect. But when you're working remotely, we have the benefit and the curse of the hiding behind a screen and sometimes that means that we're feeling really scared and feeling very nervous about things but we put on a persona over text or even just in speaking, pretending like everything is okay and making it seem like there's nothing going on because we want to appear brave and we wanna appear like team members who are contributing and reliable. And so it's a bit harder to pick up on this kind of stuff on remote teams that's something that you really have to put in effort to try to find. So given that for the same situation with the same people, what does it look like when this kind of deploy goes well? So once upon a time, we are chapter one, preparing the build. Same intro as before, the engineering team has been working hard on their new feature and their enterprise SaaS application and we are going to deploy this code later this week. Emily, the QA engineer is ramping up testing to make sure that the build is done on time and Emily and the engineers plan ahead of time for what is an acceptable bug state and they work together to triage issues and maintain a backlog to fix later. This is a very important first step for any release really just because realistically, you're never gonna do a release where there's no bugs at all. There's always gonna be something or like a nice to have but there's always gonna be some sort of follow-up later. And so if you're able to ahead of time before really starting that last stretch of testing, if you're able to define what is an acceptable state for this to be deployed in, what is a stretch goal, then it's much easier for the engineers and Kierthi, sorry, and Emily to self triage the issues, figure out what is okay to do later, what is okay to do now so that it doesn't become the engineers telling Emily, like no, this is not a bug we're gonna fix, like it doesn't matter. And then Emily doesn't have her sense of belonging threatened because she's still able to log all these issues, they go into the backlog, though will happen later or beforehand and yeah, so this is a good stop to take for any release. And this deploy is going to be the first time that Maria's new feature is going out and she knows exactly what to expect because the process has been documented, the team is reassured her that her feature is in good shape. So deploy processes being written down is a great step for any team. I love talking about onboarding engineers, onboarding them remotely especially, and a big thing that I talk about there is having a lot of documentation about processes that happen over and over, because then it's very easy to onboard people because everything's written out, everyone knows what's going on, everyone has that same source of information. So if you don't have that already, that is something really good to write out. If it's a manual process, maybe even record a video and put that in the documentation so people can really see what's going on. But yeah, so this is a good step for Maria, she knows what's gonna happen, she knows what logs to look at and the team has told her like, don't worry, we're there for you, if anything goes wrong, we will make sure that it's okay and this is really good to make her feel better. Chapter two, planning the deploy. So another engineering team has built a feature for this deploy too and they are aware that something important is going out and so they're extra diligent in testing so they don't block us. This was the case where in the first version they had a bug and it blocked the deploy and then we had to wait for them to fix it. Probably the situation that has happened for people here before, especially if you have a release cycle where maybe you're doing quarterly releases or bundling a lot of projects together and releasing at the same time and you have a lot of big merge requests or pull requests going on at the same time and then it breaks the staging environment. Common situation, so in this case it's like a lot of communication between teams, a lot of planning and being aware that what you're doing has an impact on other people and that goes a long way to building trust between teams. A mirror from the marketing team needs to try out the plan feature so that they can create marketing content for it and they know when to expect the deploy because they've been in consistent communication with the team's manager or whoever it is that is running the deploy. Maybe engineering manager or maybe product manager but somebody and this goes back again to communication. Everything here is going to be solved pretty much by communication but just keeping in constant communication between all the different teams is a really good thing to do because everybody depends on each other and engineering depends on marketing, marketing depends on engineering. There's so many interdependencies that you should be in constant communication with people to let them know what's going on and in this case this is helping solve a mirror's problems from the first story. All right, so with Kierthi it was decided at 9 a.m. that the deploy will happen at 3 p.m. that day and Kierthi who lives in a time zone eight hours ahead and built an important part knows that she can be asleep by then because the team was aware of the time zone that Kierthi is in knew that she was building a big part of this deploy and went out of their way to let her know it is okay, you can go to sleep, like you don't have to stay up for this, we got it. And yeah, so for this like really just it does take a lot of repetition and trying and really consistently thinking about it but being on top of thinking of people's individual situations and thinking of how they might be affected by something is very important especially in this case with timing and time zones. All right, so the deploy goes really well as with before there are no errors, everything is all good. And chapter three, the day after. Dave from the sales team has their first prospect demo of the day and he sells a million seats to the software because his demo of the new feature was so good. Terrific, yeah, this is another situation where that constant communication really solves the issue and same with marketing, it's gonna be the same with I think the next slide as well but just constantly talking between teams letting them know what's going on, what's coming out, giving them early demos of the features coming out, it goes a long way towards building that trust. Yeah, so clients ask Antonio on the support team questions about the new feature and he got a heads up when the feature was on the staging servers and prewrote the documentation and so does not miss any SLAs and is able to answer questions right away. Same thing with that constant communication helps everybody. All right, the end. So that deploy went well, ta-da. So how would you actually get there? So a lot of that comes down to communication but also increasing the amount of emotional intelligence on the team and psychological safety and so what I mean by that is you really have to go out of your way to think about how are people feeling how might this action affect them if you were in their shoes, what might you be feeling especially for people like Maria and like it's very easy in the engineering context because for a lot of those people you may have actually been in their shoes you might have been deploying something to production for the first time ever which is scary like no matter what your level is if you could be a staff engineer joining a new team and deploying for the first time is still gonna be terrifying. So you just have to put yourself in their shoes and think about like what are they thinking what is going on and then try to adapt that try to reach out and see how you can change things or how you can help and psychological safety creating that sense on the team is really making sure that if somebody is nervous or if somebody does have an issue they feel okay voicing that concern and bringing it up and aren't worried about like retribution they aren't worried that people will see them as silly they aren't worried that they're gonna be seen as like lesser than and just making sure that anybody feels like they can bring up any issues bring up how they're feeling and have a talk about it. Specifically though, so the first tip as I have mentioned many times already but over communicate as much as possible. So you can do this in the form of having sync meetings across various teams. So it might make sense to have one-on-ones with different team leaders who can then disseminate information down through their orgs or you can have meetings maybe every two weeks every three weeks with all the leaders together so that you can talk about different priorities you can talk about the releases going out ask if there's anything also that you should know about because maybe the sales team is going to a sales conference and they really need to make sure that the demo that they have stays as is because maybe their promo video shows something a certain way or like a deploy cannot happen during this time because they're gonna be giving a keynote you really just wanna make sure you know what's going on and give out and absorb as much information as possible. So for that same pattern works really well for setting up processes for informing other teams of releases and in terms of figuring out if something's going wrong it's good to look out for changes in communication patterns on your team. This is a good indicator of whether people are feeling okay or not. Also one of those things that's a little bit easier to figure out when you're all together in person because you can see people and maybe being a little bit more reserved and maybe it's harder to capture that communication pattern on Slack or on Discord or whatever you're using to talk to each other but still something to look out for putting yourself in their shoes so really trying to figure out like building that empathy muscle and figuring out if I was them, how would I be feeling? What could I do differently? And also setting clear expectations and boundaries around code deploys. So things like who is expected to do what reduces a lot of that predictability? If you don't have a like maybe you might have one person always doing releases or it's on a rotating basis maybe it's just automatic so you don't need to worry about having like a designated person but having things like that defining what acceptable levels of bugs are having process around communication things like if you do have a manual-ish process for deploys then just figuring out what is like when you're getting ready for the deploy how do you let people know? How do you let people know it's over? Who do you involve? Just having this kind of stuff reduces a lot of confusion and it makes it easier to onboard people as well because then they know what to do and the team can scale very easily. And asking questions during the deploy ramp up. So if you are in that type of schedule where you're doing larger deploys less frequently then asking a lot of questions can get you some very interesting feedback from people. So you might ask like, do you think this is a good thing to deploy? You're like, what do you think the biggest risks are? Or like anything like that even if you don't think there's anything you'll always get some kinds of answers that surprise you. And they could be things that are really important to know but people didn't feel like it was necessarily important information to bring up or they didn't know if they were right but by asking them, they're gonna feel like it is okay to mention and that can in some cases save deploys and be really good. And the last bit here is to ask for feedback either in one-on-ones or retrospectives. I find one-on-ones really good for asking feedback because you get exactly what people are feeling it's not biased by what other people are saying in the room. They have a lot to say you get to ask a lot of probing questions and follow up questions. So I love asking people for feedback in the team in one-on-ones about anything in general like any kind of process, any kind of news but that is a really good solution or doing retrospectives. If you're not doing retrospectives already I would suggest doing those two as a team maybe every six months or so just general retrospectives about what process in the team could change what could get better, what's going really well because you get a really good sense of how things are going that you don't really get if you're a manager you're not in that day-to-day sense and everything's a bit different. So I love retrospectives as tools for getting feedback about process. So those direct next steps though that you can start taking right away are asking everyone for feedback working on that emotional intelligence so working on putting yourself in people's shoes figuratively and formalizing communication patterns around employees, around anything really but formalizing communication, writing documentation is a really good step to making your team very scalable. And just to note that this is one of many emotionally charged processes in the company and or on the team and you should be on the lookout for your team you should be on the lookout for your teammate's well-being and aim to create a culture of psychological safety. There are a lot of different things that can cause a lot of emotions right now as I mentioned before, even just desk moves can cause a lot. But yeah, so deploys are one thing to look out for but be on the lookout for others and think of how you can put yourself in people's shoes and figure out what kinds of questions to ask feedback to get to try to make things better and make the team better for everyone. And that is my talk, thank you so much for watching. Again, if you want to get in touch you can find me on Twitter at alexandras underscore dev or my website alexandras.dev And thank you so much.