 Awesome, yeah, so let's get started. I wanted to kick off this talk by just discussing a little bit what it means to be a senior engineer. Because I'm sure that a lot of you have that question in the crowd and it's a difficult thing to answer. Most people that I talk to who are, you know, kind of entering, you know, the first phases of their career who are really driven to kind of move up in positions, they often want like a bullet list of items that, like, what do I need to do in order to become a senior engineer? And it's, you know, it's never that easy to pull that together, but what most people gravitate towards is a lot of the technical aspects of that, right? I need to know these libraries, I need to know Ruby, I need to know all these different things, which is definitely really important. But I think if you were to talk to a lot of people who are in an engineering leadership position, they say like, yes, that's important for sure, but it's really only like one part of the big picture of what it means to be a senior engineer. And that's what I'm going to kind of delve into today. So for me, when I'm hiring senior engineers, a big portion of it is I want to see that they understand that they can't do everything themselves. Like most software these days is built by teams of people, very few pieces of software are built by individuals these days. And when you're working with a team of people and you're senior and you really, you know, have a lot of knowledge in that area, your primary role becomes actually like leveling the team up and spreading that knowledge that you have. And that's really, really important to the job description of a senior engineer. And it's not something that we always talk about. So I really wanted to dive into that today with you guys. So how do you start leveling up a team of engineers? You do that by teaching. And teaching becomes a bigger, bigger role and a bigger kind of driver in your career as you move further into the engineering discipline. And you have to become a really good teacher because you want to learn how to have a big impact on your team. Being a senior engineer is all about having impact. Like you can't write all of the code yourself. You need to work with the people around you and you can have a much bigger impact on the code base by teaching them all to become better coders and spreading that knowledge around. So it's all about becoming a high-impact engineer. That's why they pay you the big bucks as a senior engineer. It's because they can pull you on to a team and you're going to make a huge difference into all of the code that the team is producing, not just the code that you write yourself. So teaching is going to become a big part of your career as you move forward. And I want to kind of provide some guidance here today about how to do that. So I'm guessing most people in this room did not go to school to become a teacher. Anybody? Ah, damn, I thought some boot campers. All right, there we go. Got one. Nice. I didn't go to school to become a teacher. I went to school to become a coder. And I get this from a lot of new engineers. They're like, how am I supposed to have all these teaching skills? Like, how am I supposed to do this? It's something that I'd like to tackle today. Because when I did it, I learned it by trial and error. And I'm hoping to provide a lot of those lessons learned to you guys today. My background is really from computer engineering. I started in that in university. Started working for MavenLink pretty much right out of college. And that team does exclusively pair programming. So I learned really quickly how to teach and how to start talking to people on a daily basis. And I moved up through my career at MavenLink and got into team lead positions where it was my entire job to level up the team and to deliver the features that we had. So that became even more of a focus for me. Now I'm a director of engineering. I've got to level up teams of teams. So it's even more of a focus. And it's a particular area of learning that I'm really interested in. Also used to be an ex-shy person, really super shy in high school. And it took a lot to learn how to get up in front of people and teach them something. So I want to kind of, you know, that's my background. Show that to you today. And definitely let you know that anyone can do this. Anyone can teach. And I'm hoping to kind of help you get there. Cool. So the game plan for today. I've got eight lessons that I've learned over the course of five years working in engineering and trying to level up all the engineers around me. I'm hoping it's all going to be helpful. We're going to go through each lesson at a time and see how it applies to engineering teams. So dig in right in. First thing I learned with working with teams of engineers is that a question from someone on your team is a huge opportunity for growth for that person. There's a lot more potential to a question than what most people give it. I'll kind of like dig in and show you what I mean by that. So like for most people, you go to work, you're sitting at your desk, you're jamming on some code, you're probably concentrating, maybe have the headset on, you're really focused. And at some point, someone's going to come by and interrupt you and ask you a question. Maybe they have a blocker, maybe something's causing air, maybe bunlo's being a pain in the butt, maybe something's happening, and they're trying to get some information from you because maybe you're the most experienced that area, you need to help. What do most people do in these types of situations? If you were to think of a response to that, what do most people respond? Or this, this is worse. They, you know, I fixed it, merge into master, you're good to go. They basically never answer the question, they never really tell the person what was happening, they didn't give them information or background or what's going on. And this is really common for a lot of engineers because they want to focus on what they're working on and they're not necessarily paying attention to the interactions with their coworkers and what they could maybe do to help leverage that opportunity that that person kind of presented because they have a problem, right? They're really motivated to fix it and if you could provide them more information around the context of the problem, even if you've already fixed it, that could help them so much more than just telling them to merge master and continue on with their day. So let's see how we could maybe reframe this and take a better approach. And like first off, I just like to kind of build this in as a nice trigger point for people, like as you're working with teams, when you get questions from people who are maybe less experienced than you or maybe don't understand what they're doing, like, you know, don't just spit out the information. Think about what you're going to say because this is a really good opportunity for you. And one of like the many ways to approach this a little better, and I think this is probably the easiest one that most people can pick up is just start asking questions, right? If you know the answer to this, try and get the person to reach that conclusion themselves because they're going to learn a lot more that way and they're going to remember it. They're going to be able to use that going forward. So for example, especially if it's a bundler error, the first thing I'd ask the question is, what does the error say? Did you read the error? Tell me what it says because most people don't read it. You know, and then try to ask them things about like the context of what's going on. Do you understand, you know, what does bundler mean by this error? What's happening? You know, do they understand like what's causing the issue? Do they understand the underlining context around this situation? Maybe then you can even try and, you know, dig into the problem and say like, what has changed, right? Most of the code that you're working on probably works in the beginning, most of the time. Something has changed is now causing this problem and try to get them to focus. Sorry. Anybody? The screen's on. All right, let me just unplug and plug in again. Yeah, what has changed? There we go. All right, sweet. Yeah, so helping someone, helping someone, you know, towards the solution, part of that could be narrowing the scope of the problem. So often when someone has no idea what's going on, they feel like everything could have caused it, everything in the world, so like help them narrow it down and say like, we've only changed two things since the last time this was working. It's got to be one of those two things that maybe they could follow the steps towards the solution. This is like one of many approaches to do, but I would try to just encourage you to start asking questions instead of responding with information. It's gonna be so much helpful to the person that you're talking to. All right, and then, this is pretty tightly coupled with the last lesson as the next one was, learn to tailor your responses to your audience because everyone you talk to is gonna be absorbing information differently, and you're not just talking to the same person every time. They all have a very unique background, experience level, comfort level with the things that you're talking to them about, and you really wanna try and hook into that so you can have a really effective teaching moment with them, a really effective communication with the person you're talking to. So one really interesting technique you can take towards tailoring your responses is something that Max Lamberg brought up in the Tav coaching. Pretty good book, I would recommend it. This is called the skill versus will matrix. This is essentially providing a model for you to figure out what teaching approach do you take with a person at any given point, and it's a really nice cheat sheet if you're just entering the teaching phase and you're trying to figure out how do I tailor my discussion with this person to be the most effective. So let me explain what this means. So skill versus will matrix, you basically have two axes. You have one for scale, which is someone's ability to accomplish a task. The other one is will, so their motivation or amount of drive to do so. Take it, you split it into quadrants, and depending on where someone is in these particular quadrants, you can figure out what's teaching technique is gonna be most effective, and I'll kinda walk through it to explain it. So for example, as you go through your career, you're going to bounce all over this chart at various different levels. I'm gonna go through a few of the stereotypical ones that a lot of people fall into, and a junior engineer is a really good example. When they come into a company for the first time, they're really excited. They are so motivated to learn, they are awesome, they are pumped to be here, and they haven't had a lot of time to build their skills yet, so they're gonna be relatively low on the skill axis, but pretty high on motivation. And for these people, you kinda wanna take a specific approach if they're really motivated, right? With these folks, you really wanna try to provide guidance for them, because they're motivated, they're gonna start to figure things out on their own, but you do need to give them a little bit of a guideline. So for these guys, think about providing tools, providing training, providing a little bit of a guardrail as they find their way around. It doesn't need to be too overbearing or direct, because they're gonna be able to kinda figure it out on their own. Especially if they're in the sort of lower skill category or are new in the position, try and remove obstacles as much as you can. Like if you foresee this being a problem and them getting really stuck on something, they're not gonna know anything about. Like try and remove that ahead of time, because what you're trying to get them to do is to learn. You don't want them to bang their head against the wall on something silly. So keep an eye out for that. Reducing risk is very similar, right? See if you can remove some of the really big issues that they may hit, so that this could be like a much more effective learning opportunity for them. So now your junior engineers may be like one month into the job, and often they'll kinda fall down a little bit on the motivation scale. And this is because they start to realize, like how much they don't know. They get into a company and they're like, oh my God, there's so much code. There's all these different gems, what is going on, I don't understand this. And they start to freak out a little bit. And like this is very common, and it's just sort of a natural process as you're entering a new co-base, entering a new organization or career. So for these guys, you wanna take a slightly different approach, right? Like they probably have a relatively similar level of skill, but the motivation is definitely decreased from their first day on the job. And for these guys, you wanna take a much more direct teaching approach for them. Provide very clear explanations of what you want. Try to identify motives. And what I mean by that is like explain your logic. I'm making these decisions or we should do it this way because, not just straight up telling them because it's not really providing a lot of background for them. Help them with the motives that they can use that going forward. And then lastly, develop like a shared vision of success. Tell them what it looks like when you're doing a really good job at X, when you've completed this really well so that they know what they're shooting towards. Cause without the high level of motivation, they can get a little lost and they'll find her a little bit. So this is really important for someone in this position. And this will hopefully help them, give them enough direction and explanation so that they can move back up on the motivation curve and get on their way. Okay, now you got your mid-level engineers. Mid-level senior person, right? They're like highly skilled, highly motivated. These guys are great. These are where you want everyone to be. They know exactly what they're doing. They're really motivated and driven to do it. So for these folks, like it's a much lighter touch when you're teaching. You want to take more of a delegation approach to them. You want to kind of open up freedoms and the things that they're doing, really just provide a very loose guidance to where they should go. You can communicate trust is really important for folks in this position. Like they often don't know how well they're doing something or how good they are at it. And so really try and kind of bolster their confidence and that can be really effective. Cause like they're skilled, right? And they're motivated, so they're gonna go. So just let them do that. Help develop stretch goals for them. That's really important in their development. And then broaden responsibilities, right? If you think of someone, maybe you have someone in mind that's in this position, like see if you can push them even further. They'll help build their skills that way. And you're senior engineer. So this happens sometimes too. Sometimes people fall down, the motivation curve a little bit. Still incredibly skilled. They're really good at what they do, but they get a little bored. Maybe they've been doing the same stuff over again and they've been there, done that. This is really, really common for senior engineers who have been in a position for a while. For these guys, your main teaching approach should just be excitement. You don't necessarily need to teach them things cause they're highly skilled, right? They can do it. You really just need to focus on getting them back up and motivated and then they'll be really, really productive. So things like this I would try and point out challenges. There's almost always something tricky or interesting in the work that they're doing and really kind of emphasize that when you're talking to them. Identified their interests. What is it that they're interested in? Is it functional programming? Is there a way of incorporating that in their work? And then just aligning their interests with their work. So project allocation and things like that is really important for someone in this position. If you give them too many projects in a row that's gonna be really boring for them, they're never gonna get motivated again and that can be really detrimental for their progress. So put it all together. You basically have a really easy cheat sheet for how to approach teaching moments with any type of an engineer at any level. You basically start to ask yourself two questions. How skilled are they at this particular thing and how motivated are they to learn this right now? And then you have a really easy way to approach this. All right, lesson number three. So as you start teaching, as you start building your kind of knowledge base of whatever you're working in, some people's default reaction is like they really wanna share that knowledge and they're very excited about it, but they often do it by just by doing. You often see people come over and grab the keyboard and just start typing and showing people things. And I would definitely encourage people like to resist the urge to do that. If you were doing most of the typing for a person that you're trying to teach, you're probably not teaching them, unfortunately. So I would just use this as a big red flag for people, yeah. Most of the time they're not gonna understand what you typed or what you did. And even in the best case scenario, this person's gonna wind up back at your desk like 15 minutes later asking you what is this, what did you do? Worst case scenario, they could spend days or weeks trying to figure out what you just did or it'll lead them down a terrible path. So just try your best to resist the urge to do that. Everyone wants to share their knowledge as they become more and more senior and just try to funnel it in the right direction. That's a really good point to learn. Are there exceptions? Yeah, sometimes. I would be really careful with the exceptions. I think the only scenario that I've seen this work well in is if you're setting up an example for someone that they can replicate. It's basically the only time. And even then, if you can get them to type it, that's even better. But if you really wanna kind of give them a solid base of an example and they can replicate it and they do understand what it's doing, then maybe try and teach by doing, but be very, very careful with this one. Lesson number four, so keep an eye out for mimicry. So this is another thing you'll see a lot when you start working with teams of engineers is people mimicking code. I mean, what I mean by that is copying or replicating existing code or behaviors that they see other engineers doing. So for example, have you ever, have you ever heard this? Like, hey, I saw this in another file and I copied it over here because I thought it would work and it does. So I clearly, I need that line of code. Anybody? Yeah, yeah, that happens. Huge red flag, huge, huge red flag at that moment. If you're working with a professional engineering team, like this is a giant warning sign that if someone has said this or if someone seems like they're doing this, they're mimicking code, this is a moment where you need to sit down and start explaining what's going on because if they truly don't understand what the code is doing, that could introduce huge bugs that's gonna cause a lot of learning issues down the road because they know it's a thing but they don't really understand it and they keep using it. So I would definitely point this out as a really good thing to notice as you start working with more and more people. There's probably a few of you sitting there thinking like, well, I've copied something from Stack Overflow before and put it in my code and then it works. That's fine, right? Yeah, yeah, we all do that. I've done that. And that's a part of learning, especially if you're learning a new framework or a new library or something like that, there's a lot of hand waving in the beginning and believe me, this code is doing something. We'll explain it later. And that's okay for a learning process as you're trying to adapt to something. It's less okay for a professional engineering team and that's the difference. You don't want people to bring that practice over into your production code where they're putting code in that they don't understand how it works and try to make that okay for your team members to start talking about. If they're copying and pasting code, they should just, maybe it works, maybe they put in it, it starts working, but they need to start asking people like why is it working now? What is it that it's doing? So it's just another really good thing to keep an eye out for. All right, this is probably one of the most important lessons that I learned is that being a senior engineer is all about teaching and teaching is all about communication skills. It's really, really important and it's something that's gonna be really important in your career no matter which direction you go and engineering communication skills are vital. In comparison to the computers that we program, humans are terrible communicators. We are constantly losing information when we're talking to each other, when we're writing things, when we're trying to just communicate anything. We lose all of the meaning sometimes, the context, the background behind what we're saying and it's really hard to get a lot of the information across the wire. And I think in a more, you know, maybe less nerdy or poetic sense that George Bernard Shaw said is that the single biggest problem in communication is the illusion that it has taken place. Much, much better put. But I would encourage anyone who is going into engineering to really put a focus on this. I think it's not something we talk about in engineering school at all. It's not something that I even really thought to put a lot of energy towards as I was working with a lot of people and it's something that I think you can really build alongside your technical skills. Like if you're a junior you can still work on your communication skills as you're building technical skills. So like keep both of them in mind and a really good way to do that is to just start. I'm very analytical so I try to measure everything. So I start to measure my conversations, especially when I'm talking to groups or if I'm talking to my teammates. And I'll say like, I really need to tell this person how to update this gem or whatever it is. I really need to communicate this thing. I go over there and talk to them about it and I try to notice like how much information is actually getting across. And you can see this by like, well by just watching their faces in a lot of cases, you can kind of see where they drop off, where they start, stop paying attention or they're getting confused. You can start asking people to sort of replay some of the things that you've been telling them to see if they could rephrase it. So if they understand what it was that you're communicating or if they rephrase it in a totally different way which sometimes happens. And see if you can kind of build in a few points where you measure how effective of a communicator you are and then like really reflect on that. You know, if you had a discussion with someone you're like, God, they just really didn't get it. Like they did not get what I was trying to say. It's not on them necessarily that like they didn't get it. It's on you to figure out how to better communicate that. And if you just keep doing that on like a daily basis, you're gonna become a really effective communicator because you're just gonna be tweaking and improvising as you start talking to people. So I would encourage you to kind of build that into the back of your mind. And this happens a lot in meetings. If you guys do stand-ups, this is a really good opportunity to do this. See if you can communicate to a group in a really quick manner. All of the important things that just happened to you, you know, the day before. Great opportunity for this. Okay, so we've already gone through five lessons. You guys should be perfect teachers by now. You're gonna be awesome, right? You know, as you start to become better and better teachers. Another thing to really keep in mind is to have realistic expectations of your teaching, of yourself, of the people that you are teaching. Because it's really easy to get frustrated sometimes. You're just like, I explained it perfectly. Why did they not understand? And it can kind of get a little annoying as you go through this process of like teaching and leveling up engineers. So I would just keep in mind that teaching is absolutely a marathon. It is not a sprint. It takes time for people to absorb information. It takes time for them to level up in whatever you're trying to teach them. So just be realistic, right? Acknowledge your wins, because there definitely are some. If you're actively trying to teach people, like you're getting something through. So really try and look for those things. The people you're teaching may have advanced in other ways as well that you might not be acknowledging. And try and celebrate that too, right? You're putting a lot of effort into this and that's a really great feeling when people are learning from you. So just keep an eye out for that. And then kind of above all, don't expect them to absorb everything. People don't. And that's just okay. That's the way it's going to be. So you can kind of battle this through building in different, kind of fixes to your teaching technique for that. Repetition is by far the easiest one. You know they're not gonna absorb it every time. So try and repeat it. If there's something you're really trying to get across, repeat it over a period of time and they will pick it up. It just takes a while. Okay. And teaching also benefits the teacher, right? It's really, really beneficial to be in a position where you're trying to communicate this to someone else when you're trying to teach someone else. It really solidifies your own knowledge that you have because you need to formulate it in a way that someone else is going to be able to understand. It's great for building confidence. That is by far the most effective tool for building someone's confidence in a particular area. And I would encourage people to look at their team members and see who could teach something today. Because I'm pretty sure everyone on the team has something to teach. Even if it's an engineer that's been here a week, maybe they could sit down and teach you what it was they were doing the day before. Like they're the great opportunities to open that up to people. And it's huge for their learning curve as they progress in their career. They need to build confidence in what they're doing and they need to be able to explain it to other people. It's also a really good opportunity for feedback, right? You can go through a teaching session with someone and if you've developed a good relationship with them, they can help feedback on how you could do better as a communicator, as a teacher. And that feedback is also really helpful for you as a learner as well. Okay, lastly, last lesson. A lot of people probably work for engineering teams. They may have a manager, maybe just a coworker or a boss but I would encourage everyone to talk to your superior or your colleagues about how you could be learning more effectively. And there are a lot of different techniques. How to build in teaching opportunities and learning opportunities with the people you're working with. And a lot of the times your management can help you do that. Because it's basically their job to make you a more effective engineer. Like every day they're desperately trying to figure out like how do I make this person better? How do I make them a stronger engineer? So talk to them about this, right? If you think that there are opportunities for you to be learning more, discuss that with them. And some really simple ones are often trying to find ways to challenge yourself. In a lot of teams there are things that are kind of exclusively reserved for senior engineers. Like architecture planning or big feature things or performance hits or benchmarking. Sometimes the senior engineers get to do that. And there's not really a lot of opportunity to show junior engineers what that's like. So if that does happen in your org, I would encourage you to talk to your manager about doing essentially a ride along. You don't need to do the technical plan, but you could certainly be in the meeting where the senior engineers are discussing that. And you're hearing what's going on. And you have a foundation for how this works. And you can do this over several months and get a really good idea of what it's like to do that. And that'll build a great foundation for you as you move into a senior role. So trying to incorporate things like that, hopefully your management is actively doing that. But it's also up to you to like really raise your hand. Another thing is teaching focused practices. It may even like we pair program. And that is definitely teaching focused. You're constantly trying to communicate information back and forth. And that is great. That is an absolutely spectacular way to become a good teacher. Another thing that we've been doing that's relatively new. But I wanted to bring up today because I think it's pretty nice. We've been calling it show and tell. But it's basically at the end of the day, our team of engineers, which we usually do teams of five, will get together and they'll review the code that they wrote that day. We do this every day. And it's sort of like a mini code review process. It's relatively simple. You kind of present your code. We do it on GitHub. We show the diffs. And then you see, how do I explain what I did today? How do I explain my approaches? And you have to really kind of present this to the team. And it's a great opportunity to get feedback on how you're doing and what you're coding. And we do this every day. So there's no piece of code that goes 24 hours without someone else seeing it. And so it's really great for people who are learning that they can't go down the wrong path for too long. We're gonna catch it right away. It's also great to build their communication skills because they have to talk about their code on a regular basis. And that's something that's been really effective for us. Also another great teaching opportunity, conferences. Your manager, I hope your manager would love to help you prepare a submission for a conference. Really great for communication skills and teaching. And I'm sure that the people you're working with would love to see you kind of advance to that level. It's also great for the company. So it's like a win-win. Definitely encourage you to talk to them about that. So I hope these lessons have been helpful. I hope that it saves you a little bit of time in some of the trial and error that I went through as I was kind of growing into the engineer that I am. And before you move on to the next talks and kind of absorb a bunch of information, I wanted to leave you with this quote that I really like that is true learning involves a permanent change in the way you see and act in the world. The accumulation of information isn't learning. So I hope today that you learn something and maybe it'll change the way you behave and maybe it'll change the way you see things in your day-to-day life going forward. And then it'll be worth it as we go on to accumulate more information and more talks. Thank you. I think we've got time for questions if anyone has anything. Yeah, yeah. So I'll just repeat the question a little bit. But he was just asking if I had seen mentorship be a really good opportunity for senior engineers that have maybe been a little demotivated recently. We've got a mentoring apprentices. Yeah, yeah, that's a really great point. I've definitely seen that. We've, it's kind of funny in the pair programming community. I think it's like the opposite. Sometimes teaching can burn out as well because it's like too much teaching. But yeah, especially if you're, pair programming you're teaching all the time, but for people who solo a lot, giving someone the opportunity to teach enforces how much they know. And that is huge motivator for their ego and for everything. So yeah, that's a really great idea for motivating someone. He's maybe a little bit too stuck in their own world, helping level someone up. Yeah, so just for the cameras. So he was asking, he has two engineers that both start at the same time, both at the same skill level, but one of them seemed to want a much more direct structured teaching approach where the other was much more okay and it's just kind of going on their own. And yeah, like not without knowing the people, I would say potentially one of them maybe wasn't as motivated as the other. But it's hard to tell. I think motivation plays a lot with different people. And if someone is coming from an industry where they're not as used to being self-taught, they're not as used to like digging around themselves, that can often present itself in a different way. And I've seen that a lot from people, like with academic backgrounds actually, like they sometimes want the structure in the teaching technique. And they do fall a little bit more into that direct category where they need clear guidance and you need to figure out like what it looks like when they succeed. It's really important for them. But yeah, it's tricky gauging sometimes where they are, but I think if you do try both approaches, you can see how effective they're going to be and that might actually help confirm where they are in this goal versus Will Matrix. Yeah, so we have a Salt Lake City office. We're in San Francisco, so we deal with this a lot. We remote pair a lot. Biggest thing, my favorite, is persistent Google Hangouts for this. It eats up all of your Wi-Fi, but it's really good though. I try to get a camera on as much as possible, so we had a few people starting in our Salt Lake City office. We moved everybody into a room. We had a Google Hangout going all day for both offices, and you can see people walking in another room. You can see their body language when you're talking to them, and that helped a lot. I've seen people do it also. If they have pairing stations normally, they have two monitors and two cameras, and you can actually put some, the other person's video on the other monitor, and you can see when they move their head to go and look at you in the other monitor, so it's almost as if they were right next to you, and that can really help a lot with the body language as well, but cameras can be a little creepy, but you get used to it. The Hangout's great because you get to see when people with experience, maybe a more senior folks, walk into the room and are sitting next to you, and there's so many more questions going back and forth, because they're just like, oh hey, James, what's this thing? Or what is it, and that's, oh, so good. Yeah, I'd recommend that. Yeah, it's a great question. He was asking if you're trying to guide someone towards an answer and they can tell that you know the answer, it kind of seems like a scenario where you're getting tested a little bit, and yeah, that can be really tricky. First step, and this is a broad one, is make sure you're in an environment where that's okay, where the other person is okay with learning. They recognize that this is not a test, this is a learning opportunity, so that's a more general answer. For more specifics, I would generally act as if I am equally as interested in the research we're doing to go down that road. Often when I'm trying to explain something, I'll get them to go into the source code of whatever the thing is that maybe they don't understand, and I'll be like, oh, I didn't know that, or hey, this is also a thing that didn't accept, and yeah, maybe I kind of knew in general the answer for this question, but I'd try and be open about the things I don't know, and that makes them much more comfortable with also showing that they don't know something, so yeah, that's a tricky one. Yeah, yeah, that's a tough one. Replay, replay, yeah, because your communication gets even harder at packet loss, even harder when you're dealing with someone who maybe it's not their first language. Yeah, the best thing you can do is figure out replay and open teaching opportunities because it is sort of a form of replay. So you think you taught someone something, and then you maybe try and get them to either teach it to another person and you can understand exactly how much they absorbed or replay it back to you, and that's definitely going to confirm or deny it, like whether or not they absorb the information. Yeah, that's hard. Cool, and bills, nice, awesome. Well, thanks for all the questions. Thank you.