 I'm Kaewoo. I go by this because everywhere I've been there's always lots and lots of Catherine's, Kate's, Caitlin's. There are a million different ways to spell it. So everyone just calls me Kaewoo. And I've been at New Relic for a little over a year now. Before I was at New Relic, I had a whole bunch of different jobs after I decided that the whole doctor thing wasn't going to pan out much to my mother's everlasting disappointment. The last one was as a product specialist actually at Google where I did some product manager-y kinds of things like future prioritization with an engineering team. I ended up taking up sabbatical to go to a programming boot camp because I just got really tired of always having to persuade other people to build things for me versus just being able to do it myself. So switching over to this new career has been such a fun time. I have been loving every minute of it. It's just been really, really awesome. But it's also just like a lot for me to try to catch up on. I'm always sort of feeling like I'm pretty behind. One really cool thing, though, is I've realized that there's a lot to being a developer that can actually have nothing to do with the coding bit, hence this Pac-Man, not Pac-Man pie chart here. Another thing, too, is as developers, let's be honest. Fundamentally, we're kind of lazy, right? I mean, we like to automate tasks and find shortcuts and all of those sorts of things. And so for me, I've been applying that laziness to reporting over skills that I developed at my previous jobs over into my new one even while I'm still learning a lot about coding. And I've got two weird tricks to being a better developer with no code required. The first is building better relationships, and the second is getting better at communicating. Of course, I'm mostly speaking from my experience as a more junior developer with a non-traditional background. But hopefully, even everyone here that has more experience than me will think of ways to apply similar concepts as well. So I have a three-step foolproof plan for that thing that everybody is always talking about, building relationships. I really prefer to think about it more as just getting to know people and making friends because, of course, friendship is magic. Actually, when I was putting this talk together, I wasn't sure if I could use official imagery, so this is actually just from one of our IT people at New Relic, Vanessa, who has all of these at her desk. So it's pretty awesome. So, yeah, I mean, it's hard, though, sometimes for me because I'm a pretty strong introvert. Like, this morning at breakfast, I could definitely tell there are people there that are coming to the conference here, and I was just going through, like, don't make eye contact, don't make eye contact because I was going to be pretty nervous if I didn't talk and wanted to focus on practicing that. But, you know, the thing, too, is a lot of developers in general probably would describe themselves as introverts, too, right? And so when you have two introverts together, that can make it kind of hard to get conversations started sometimes. But fortunately, at my old job, I developed some hacks for this. And so I find that using these hacks is really useful for getting people to even just want to help you in the first place. So I swear, getting better at making friends is actually a skill. I used to always think that there were some people that are just, like, naturally really charismatic. And that's probably true, but it's not actually something that is, you know, impossible for you to try to get better at. You know, you definitely can work on this and get better at it if you're interested. One thing I do is I try to pay attention and remember small details that people have told me, especially about their lives outside of work. Sometimes this is easier for me to remember than people's names even, but I find that they're usually pretty forgiving if I'm like, I'm sorry, I totally can't remember your name at all. But I do remember that conversation that we had where you talked about how much you love Nutella or whatever it may be. Fun fact, Nutella single-handedly drives up the price of hazelnuts across the world. Oregon, where I live now, has been trying to develop hazelnut trees to compete a little bit better. Anyway. So, you know, for example, that kind of thing, it makes for better conversations than your typical small talk. And I find that when you establish a base with non-technical conversations, that becomes really helpful for technical conversations you do have down the line, particularly ones where you might have to disagree with someone on a decision that they've made. Another really dorky thing that I kind of do is that I actually sometimes mentally prepare stories to get a conversation going of interesting or maybe weird things that I've done lately because otherwise when someone asks me something like, how is your weekend? Oftentimes I just freeze up and I'm like, oh, good. And like that's it. And then the conversation goes nowhere, right? So then instead, if I'm thinking, okay, my weekend story this week is going to be about how I took a pasta making class on Sunday. That can then prompt questions from people and get them interested to try to sort of break through that initial level of awkwardness. Also, I think that if your company has a support team, you should definitely make some good friends there. I think support tends to be chronically undervalued at a lot of tech companies, but they probably know way more about the product than you do, at least when you start. And for me, I used to work in tech support, and so I always liked best the engineers that weren't really stuck up about being engineers and showed that they were willing to learn from me as well. I think another key component to getting people to want to help you is to demonstrate that you value their time and so that you took a reasonable amount of time to get as far as you could on your own. Each time someone helps you, you'll pick up more ideas and strategies to try and be able to push yourself that much farther before the next time you end up having to ask for help. When you do ask for help, you can ask questions like, if you're busy, who else could I talk to about this? And when someone does help you, you can always end with asking something like, is there somewhere I could have found this answer on my own? And if the answer was no, and there isn't any good reason it doesn't exist, you should go ahead and add it. So when you do have someone's time, try and think of ways to sort of push out and extend what you're learning. So it's not just this one specific situation that you've now got an answer to. That way, you'll be equipped when a variation of the same question comes up again, and you won't need to interrupt the person that you were asking for help a second time. Lastly, for getting people to want to help you in the first place, I find that something as simple as just showing your appreciation really goes a long way. Great mentors, of course, probably would do it anyway. But I just think it definitely never helps, never hurts, sorry, never hurts to make people feel extra good about doing something that helps you. So when you make sure to notice when people have gone out of their way to do something for you, that encourages more of that to happen, which is what you want. If you're working somewhere that's big enough that not everyone knows exactly what everyone else is working on, you can also do things like let people's managers know when they've been really helpful, because managers really like hearing good things about their reports and people like their managers to know good things they've done for the team, especially if they don't have to do any self promotion or anything like that. So it's just a nice thing to do all around. So we've covered step one now of getting people to want to help you. Step two is that I think there's a lot you can do to make your team look good to other teams. It isn't all that hard. It helps your team feel good. And it helps other teams feel good too about working with your team. One of the common areas this can come up in is in any demo or review meetings that you might attend, because I think you can give really awesome demos just by being thoughtful and prepared. Think about things like why does this change matter to your audience? Why should they care? Think about how to show the before and after, maybe with grabbing some screenshots or collecting metrics to show why the thing that your team did is such a big deal. Demos are a really good time to make sure that your team gets full credit for everything that it's been working on, even if it's not easily visible. You can do things like talk about corner cases that you've dealt with or items that you consciously chose to handle at a later time, which shows the other teams there that the engineering has been thoughtful about its impact to other teams like support. I like to prep a good amount for a demo, which usually involves some kind of script, not always like an extremely detailed one, sometimes just an ordered list of what I want to show. It's mostly just so that it flows well and I don't forget a small detail and then have to backtrack. I also like to do a test run through, and so that this way I'll know everything I might need to get preloaded onto my computer just to make the demo really efficient and less prone to errors. I think another area where it's actually not that hard to improve in is in writing status updates. I know. They're pretty tedious. I don't believe anyone actually likes doing it, even project managers, really. But even for short updates, here's something you can do. Read what you wrote and think, if someone else read this, when they got to the end, would they still have this question? So what? This is a tip for my old boss and the idea is to make sure that your status update actually talks about the impact of what was done versus just a description of the work. Here's an example. This is a perfectly fine status update of what happened last week. We changed email reports to be sent at 1 a.m. local time. But you can imagine someone getting to the end of this, you guys don't have the context for this change either, and sort of thinking at the end, so what? So what did you change the email reports to be sent at 1 a.m. local time? So maybe you can change the status update to say something like this instead. We changed email reports to be sent at 1 a.m. in local time, allowing customers to receive data in the correct local time window. And immediately you're given more context, oh, previously people were getting incorrect reports sent to them, and now we fixed that, which is really awesome. So this helps a lot for updates that get sent to, say, upper management or other teams that might not be as involved in the technical implementation details. I like to think of this a little bit like translation work, like you're taking your work and translating it into here's why you should care language kind of thing. In general, I think that making an effort to be thorough and empathetic to the needs of other teams just really goes a long way. I'm really proud of the time that someone on our support team at Nurellic told me I was her favorite engineer to work with because I was really responsive. All of this just helps people feel heard and knock down any stereotypes they might have that engineers don't care about regular people kind of thing. And so that way when your team needs their help, they'll be there for you too. So that's two out of the three items there. So third, I'd like to talk about something called ask versus guess cultures, which is my favorite frame for better understanding people. It's a culture clash that can lead to a lot of tension if you're not aware of it. So let's start with an example. Here's the situation. This is you. And this is your friend, let's say Jamie. And Jamie has a friend that you've never met named Taylor. Taylor is going to visit your city and needs a place to stay, but you'd rather not host a stranger. So your friend asks you, can Taylor stay with you? What's your instinctual reaction in your head? Not out loud, just kind of in your head. Is it, I'll just tell them no, whatever, no big deal. Or is it something more the lines of, this kind of puts me in a difficult position. That was just a quick litmus test. If you think it's not a big deal to just say no, you are most likely from ask culture. If instead, the situation would make you feel really uncomfortable, you're most likely from guess culture. As far as I can tell, this ask versus guess culture description first came up on an ask meta filter post in about 2007. The way it's described there is, in some families, you grow up with the expectation that it's okay to ask for anything because you're okay with getting no for an answer. This is ask culture. And guess culture on the other hand, you really try to avoid asking unless you're pretty sure the answer is going to be yes. And the way that you know if the answer is going to be yes is by sort of putting out delicate feelers out there, which if you've done this well means you won't even have to ask, you'll just get an offer. And even then you have to use your judgment for whether to accept that offer because you have to ask yourself, are you imposing on this person at all? Ultimately guess culture is really about the idea that putting others in the position of having to say no seems rude. So this is a spectrum, not a dichotomy. Based on my own experience, places that have a really strong reputation for being really nice tend to be guess culture. But it can vary regionally. And on a global scale as well, I find that some countries have a culture of being really direct, like all the Germans I've ever worked with, while others are much more indirect, like in Japan or something like that. Maybe I should move forward and like people are taking pictures of slides. Cool. Okay, so let's go through a few more examples. This first one is from a medium piece that I read about something the author called the Seattle know, even though it's not necessarily Seattle specific, that's just where this piece came from. Anyway, it goes like this. Some reason says, hey, I'm going to this party. Do you want to come? And the response is something like, hmm, that sounds interesting. I'll have to check. Or oh, yeah, maybe. And then you don't hear from them again about this. This means no. This is not obvious to everyone. This is not obvious to me a lot of times actually. And so this is a pretty clear example of a guest culture situation. All right, here's another example that a personal example that happened a couple of months ago. So normally on the weekend, my husband Dan and I each cook one big meal in order to have leftovers for the upcoming week. One week, one day I said off-handed as you said out loud, I don't have time to make lunch for next week. And I was just talking out loud about how I would need to figure something else out for lunch. But my husband Dan, he interpreted that as could you make some extra meals for me so I have lunch for that week. So he says, I'm going to cook two meals this weekend. And me, in my head, I'm thinking, that's so weird. He's planning to make an extra meal this weekend. But okay, sure, whatever. And I didn't say, oh, you don't have to do that. So I just like totally did not receive that signal out there. And so at the end of the weekend, the end result was, I'm over here thinking, why do we have so much food in the fridge? And my husband's over there thinking to himself, I'm such a good husband. I'm like really good at telling funny stories about my husband apparently. It's like my thing. So anyway, I want to talk a little bit about the pros and cons of ask versus guess cultures. I have a preference for one and I'm sure my bias comes out, but that doesn't mean that it's objectively better overall, right? So ask culture prioritizes efficiency in knowing exactly where you stand because there's no ambiguity. You also tend to get what you want, at least in the short term. On the other hand, it does come across as a lot more confrontational, which sometimes can make people feel uncomfortable, maybe even alienate them. Guess culture then prioritizes avoiding hurt feelings or embarrassment from direct confrontations. And it's generally considered more polite, but it does depend on this really tight net of shared expectations. You have to be able to recognize the subtle signals that other people are sending and receiving. So that can be bad if you're not great at reading social cues, which I find in that position a lot. And if people don't share your expectations, you can end up feeling like no one is listening to you at all. So let's talk about some strategies for handling ask to guess situations and vice versa. Generally speaking, it's about trying to step a bit more into the other culture so that your message is clear and people are comfortable. And now that you can at least recognize the difference, you're most of the way there. So if you're from ask culture, my first tip for you is to make a guest culture friend who can be like a little bit of a guide or an interpreter. That's what my husband Dan does for me because if I'm confused by some interaction, I'll often bring it home and you'll help me dissect it to see what was being said between the lines. Remember to that it's not just what people say, but what they don't say as well. Because maybe there wasn't an explicit no in someone's response to you. But maybe it wasn't an enthusiastic yes either. So pay attention when there's any hesitation. And lastly, go ahead and apologize and clarify later if you realize too late that what you said might be misinterpreted that you sent out a guest culture signal that wasn't what you intended. I use this strategy a lot. Well, if you're from guest culture, when I was practicing this presentation and asking my husband for advice, he told me that guest culture people don't need to hear this. They already understand all of it. But I couldn't handle the asymmetry from leaving the slide blank. So just a couple quick points. If you're angry or frustrated with someone because it seems like they're just in your face all the time. Remember that they might be unaware of the rules and it might take some education to bring them on board. Consider also that softening a no with an excuse can end up hurting people in the end as well. If they don't understand that that was a no. One phrasing that I find helpful to remember is before you ask people for something, say up front that it's okay to say no. Even for guest culture people, you can use this to remind yourself that other people can say no to you as well, even if you're feeling uncomfortable about something you have to ask. So that wraps up three step plan for better relationships overall. Now let's talk about getting better at communicating. Now that everybody likes you, your life of the party, and they want to help you, there's a lot of things I think you can do to make it easy for people to help. Help them help you. There are a few different ways that you can do this. I think one of the hardest parts to learning is just letting people see inside your head. There are ways that you can make this easier by articulating the premises that you're working off of and the logic that you're using so that together you can narrow down what you don't understand or are missing. You can say things like you had me up until such and such a point or I'm confused because I thought you said premise A and premise B, but here it doesn't seem like this logically follows. This is a good general format for describing problems. Say what you're trying to do and why so that someone can jump in immediately if that's not even the right goal to be going for in the first place. Also describe your current problem and what you've tried already so that they won't give you suggestions that aren't relevant anymore. When I worked in tech support the best clients would put all of this information up front in a ticket which saved a ton of time on the back and forth even just understanding what the question was in the first place and we could get back to them faster with the actual solution. Remember that just having the courage to say I don't know is a strength. Exposing your own ignorance feels really scary and I suspect that in some ways this gets scarier as you get even more experience because now you have a reputation you want to protect and maybe you're afraid of coming across like an idiot or something. So just remember to try not to get caught up in your ego when it comes to these things. For me I'm always practicing even just saying things like I don't actually even know what that word means that you're using. But the sooner that I tell people I don't know what's going on the sooner I can get to actually learning and working. So now I want you to think back to the last few times you asked someone for help. How many of you after you got help heard something from them that was like did that help right? That's because most of us are really needy and really want validation. My favorite feedback that I get from people actually is that they've gone off into the real world and actually used my advice. So when you tell people specifically what they did that helped you they'll know what they can do more of. For example it really helped me when you walked me through how to use these tools or it really helps me to be the driver when we go to a program because I absorb more than when I'm just shadowing. So that's that first point of better communication. Step two I have this idea that questions are kind of like a superpower. And so as we all know with great power comes great responsibility. Good questions are invaluable for highlighting assumptions I think and helping the team avoid dead ends which helps you all move faster. Questions like are we working on the right thing or is there a reason we're doing it this way? This is something that came up a lot in my old job as well actually because sometimes this uncovered a misunderstanding about a new features requirements where an offhand comment suddenly got interpreted as a must have item. And so getting rid of these sorts of things saves everyone time and disappointment. Of course you want to ask your questions in a way that won't put people on the defensive. If someone hisses at you that even I can tell that is not a good sign. Try and express humility since you're asking questions because you want to learn rather than assuming you already know. You can also think about questions that other non-engineering people might ask like your users and salespeople. Getting these answers earlier on gives your team a jump start on looping in other teams as needed because if the only answers your team has are pretty vague that's an opportunity to dig further for more clarity. So two out of the three on better communication one last main point. Third one then is giving good feedback. I think that giving useful feedback to the right person in the right venue at the right time is hard for a lot of people. But for me when I was in tech support we would frequently do quality reviews of each other's responses to customers as well as give pure feedback every few quarters. So I got a lot of practice at phrasing feedback without losing friends. Before offering feedback I like to spend some time thinking about what will be useful to the person receiving the feedback. What is it that they want? What are they trying to do? And of course you always get bonus points for bringing suggestions of solutions along with you. It is hard sometimes to refrain from nitpicking just for the sake of having something to say but I think it's worth it to increase the value people get from listening to you. You want people to think that you have a high personal ratio of useful to not useful things to say. Something else I've been trying lately as well is to make sure to give positive feedback whenever there's an opportunity. I don't mean like phony fake positive compliments or anything like that but just that when something good happens make sure to bring it up. My hope is that this is helpful in the longer term so that I can build up a general reputation as a positive person and any negative feedback that I do have will then be taken more seriously. On the other hand sometimes giving good feedback can also mean just stating I don't have an opinion on this topic so that you withdraw yourself from the pool of people weighing in. This makes life easier for whoever is in charge of getting the group to a consensus. One last part of feedback as well of course is accepting it graciously so that you keep getting it and keep having feedback for improvement. One thing you can do is rephrase what people said to show that you understood the core part of their feedback and make sure not to get defensive even if you disagree on some portion of it. Because remember you don't have to act on every piece of feedback but it's very helpful to acknowledge it so again people feel heard. So that wraps up my ideas for better communication. Before I finish up my talk I do want to mention a couple caveats and pitfalls to avoid. Sometimes I think we have a bit of an issue in the tech community of undervaluing non-technical skills and a lot of what I've talked about is essentially using non-technical skills to help move yourself forward. The thing is you don't want to be assumed to quote unquote just be the secretary which I do not mean as a dis on secretaries at all it's just not the job that I'm working towards. There's also this phenomenon called the Girl Scout Tax which is about how we have a we tend to have a stereotype and expectation that women are helpful which unfortunately sometimes leads to women not getting credit for providing that help because supposedly oh that's just what women do they're helpful versus someone that's gone out of their way and is a really big team player. It's just one of those unconscious things that we probably all do from time to time so something we should all try to watch out for to make sure that everyone is recognized and appreciated for what they do. Ultimately keep focused on whatever your end goal is whether that's getting better at coding, working on bigger features or learning about the market and industry whatever it may be so that you can consciously choose what things you'll do that will bring you closer to the goal and not do things that move you farther away from it. These are some recommendations that I have for further reading. The first two are books that are pretty quick and easy reads actually and the other four are blog posts. I'll be tweeting out a link later to these slides so that you can go back and look these up if you're interested. Thank you.