 So, Megan, thank you for the intro. I think I wrote that blurb when I was, I must have been feeling insecure, because that's the most dramatically positive view of my career that one can have. Other takes are, I have a linguistics degree because I'm terrible at career planning. So somewhere in the middle is the truth. My name is Jack Danger. I lead infrastructure engineering at Gusto. We do payroll, HR, and benefits, and there's a lot of companies out there now that are, on the wrong side, the axis of scalability, where it's not a lot of simple data. It's a little bit of extraordinary, complex, extraordinarily important data. So some of you may be in those places as well. Ruby is a really good language for those kinds of problems. And Gusto has a lot of them. I'm talking about scaling teams, I'm talking about interviewing, I'm talking about skills, I'm talking about people. And this is a talk sourced from the frustrations of myself and many of my dear friends and colleagues over the last couple of decades. How many of you have been asked questions during an interview that you know in no way correlates to on-the-job performance? Okay, some hands. I wasn't sure if anybody raised their hands, so I phrased it as maybe rhetorical, but thanks for participating. All right, and how many of you knew during an interview that you have skills and knowledge that that company totally needs and nobody asks you about them and nobody allowed you to show them, right? So we're going to talk about designing engineering teams. Something different than what we've used in the industry in the past. Caught it. This talk, as I mentioned, is sourced from many of my colleagues and my friends feeling underappreciated or misunderstood at work. And this effect is pronounced for people who do not present as white or straight or male, but it absolutely affects everybody. The solution is you just got to hire great engineers. Okay, no, that's actually like super terrible. This is basically the problem. This idea that there's a great engineer out there or that there's a thing you do to become a real engineer is the core problem that we're facing in our interviewing. This is how you get things like words like ninja and rock star and guru on job descriptions. Someone looking for someone amazing. You can't hire great engineers because the phrase great engineer itself is so coarse as to totally obfuscate all the details of what makes someone effective in a role at a company in a particular team. There's a lot of detail in that. It's like saying write good software, which software? I don't know, it doesn't matter, just make it good. Okay, I put some JavaScript together, great. Let's run that in a database, no, don't do that. It was good for some things and not for others. We didn't have any design thinking around how to do that. Software engineering itself is a massive field. It has thousands of skills involved in it. It has many, many hundreds of domains within it. And each company operates in just a few of them. And each of us are only competent in a few of them. There are engineers out there that effectively have no overlap in their skills with one another. Here's a hypothetical example. This is not dissimilar from a lot of things I've seen in my career, I was at Square for a long time. So as it grew, we had a lot of people from different backgrounds come in and have to face that they had a different origin story than someone else. So Jordan here went to Stanford, got a CS degree and knows how to balance a binary tree. And during the CS final, Jordan was asked a question to balance a binary tree. Great. And then Jordan and all of Jordan's colleagues went interviewed at BigCo where during the interview, the interviewer asked them to work with binary trees. Jackpot. That's totally software engineering. They're good at that, right? And then they get on the job and they meet Kelly. Kelly graduated high school and didn't go to college. Kelly spent the first 15 years after high school working at a bookstore. These are all made up people, by the way. Kelly does not know how to work with a binary tree. Kelly is however the only person in the company who knows how to use GraphQL. So Jordan knows C in Java and Ruby. Kelly knows C++, JavaScript and Go. Which one of them is more senior? One of them is older, but we know that that's not really a factor. Maybe a better question, which one of these people is qualified to interview the other? Would either of these people pass the others interview bar? And the bar is the problem. So I've heard this at a lot of companies, and pretty much every company I've worked at, they want to have a high bar for their talent. We have a higher engineering bar. We don't lower the bar for some candidates. A bar, you have to have grown this direction that far. In one line, is that how that works? There's two lies hidden in the idea of a hiring bar. One is that people have an inherent ability. You are at that bar. If you can get someone who's brand new to be able to do a really complex problem during an interview, that growth trajectory is what I want to hire for. That ability to learn algorithms or something in an interview, that's incredible. It doesn't matter where they're at. It matters where they can get to, how they can do that work. But the other lie in there is that people grow linearly. I'm never going to cross this bar if I go up and turn a corner and I learn this whole thing over here. I know a little of every language, but I don't know how to work with databases. Am I at the bar? So let's take a quick look now at some of all the skills involved in Rails. You can all read that, right? Now this is a graph of skills, a dependency graph of skills involved in working with Ruby on Rails from a couple of years ago from a good friend of mine and colleague Brooke Rigio at CodeFellows in Seattle. I really appreciate their curriculum. Now let's zoom in a little bit. Enhanced. Enhanced. OK. It's a little grainy. But in one corner of this, there's working on the command line, or the operating system, files, like CH modding stuff, and running stuff, and I don't know, creating bin stubs in your Rails root directory. That's important, right? Sure. Could you get a little bit without it? Yeah. Objectively, you can. A lot of people don't know this stuff. How about over there? On the other side, there's Ruby gems and package management. Important? Yeah. Somebody in your team needs to know that. Does everybody? Like running gem stash locally and how the bundler actually makes calls to download files, it's nice to have someone around who can debug that. But not everybody needs to know that stuff. But there's a huge mass of skills. Which of these, I think we'd all agree, some of these are ancillary, not necessarily required. Which of these are the core skills? Which of these, does everybody have to definitely do to get in the door at your company? Well, obviously. It's project management and licensing. And let's add to that also, I don't know, browser quirks and sass. Those are the core. Everybody definitely has to have those. The rest are optional. And that's just the stuff you need to be good at Rails. Say somebody comes in. They're like, 20-year veteran in the industry. And that industry is video games. And they can do C++ on mobile. Can they be effective in a Rails shop? I don't know. But that's a problem we need to figure out. There's no bar for engineering. So what are we doing when we try to hire? I think what actually happens is this. We're looking for the overlap between us, personally, and the other person. The more overlap there is, the more talent we think they have, because the more talent we're able to see. So the overlap is, in fact, our signal. I know how to computer. I know these things. So if you know these things, then you know how to computer, too. That's the logic of most of our interviews. Other things I know, how much do they know? And a truly exceptional candidate can even succeed in this environment, because they know so much that most interviewers will ask something that this person can do. But you know who else succeeds at the same level or even better? Someone with an identical background. Hey, at Stanford, I learned this thing. Can you do this thing? Oh, yeah, you went to Stanford, too. You can also do that thing. Wow, we're both really good at software. Like, no, one of you is totally redundant. And who can't succeed in the system? People who have different backgrounds. People who don't overlap with the interviewers, which means they have skills and knowledge that are not present at your company, which is exactly the people you most need to hire. But how do you get them in the door? How do you do it without lowering some real standards, where everybody does want to work with people who can teach them things? Everybody wants to work with smart people. Everybody wants to work with people they feel like everyone's carrying the load. How do you know if someone can carry their share of the load? Which is really the question we're asking. Can you provide value? Can you work alongside us? What can we be peers? Now none of this became clear to me until, like, well in my career. About 10 years ago, I hated algorithm questions. Hated them. Because I couldn't do them. I just had a linguistics degree, right? Like, I didn't know anything. I didn't know the name of any data structures. I didn't know the runtime or algorithm complexity of anything. So I had a favorite question. And early on in my time at Square, I asked this question, tell me about some source code that you didn't write that you appreciate. And tell me why you appreciate it. Great question, right? Sure. If you do a lot of open source software, and like you read a lot of other people's source code, which I did at the time, and I was really into that. And I thought it really contributed to my sense of taste and API design and code organization. And it does. And that's one skill. But, and this is the source to jQuery. Remember the day I cracked open jQuery? Like, I'm just going to read it. Like, how does that stuff work? And I learned some stuff about JavaScript. And some of the people who utterly failed that question went on to lead me at that company. Like, one of them had implemented a database from first principles. Another one had a PhD in CS from Stanford, and had worked in compiler science, and had worked on the closure compiler. And he had not one idea to share with me of like interesting source code he'd read. But he was amazing. He was just different than me. And the two were different from each other. Now, with a little more experience, I think this is what was happening. It's just the Dunning-Kruger effect. Junior people are not qualified to evaluate senior people. And senior people don't feel comfortable believing that they actually have skills. They think that those skills come easily to everyone. And so you have no real way to evaluate anybody. As I developed my skills, I started finding a lot more overlap between me and other people. I'm well into this now, where there's nothing a new grad knows that I don't also know, because I've interviewed enough new grads that I've seen a lot of the things that they can teach me. So now, everybody I interview, I think is amazing. And I can see how they could be successful. And I also see how they could fail, because I can think of somebody just like them who succeeded on the job despite everybody maybe not believing they could. I can also think of someone just like them who had skills that weren't the right match for the company at that time and couldn't gain traction. So if I can imagine everybody succeeding, I can imagine everybody failing, what am I to do? Let's pause that for a second. Let's talk about aviation, because there's two industries that are well ahead of ours, and we can learn from their mistakes. Aviation and medicine. They are both industries where people learn for a long time to do the job very carefully and correctly, and something real is at stake. In those cases, lives. In our case, something real is at stake in those industries. Now 100 years ago, aviation was people flying over the front lines of World War I. And it's an open cockpit, right? And they'd light dynamite and throw it over the side, and they'd take grainy photographs with old-timey cameras. And then after the war, commercial aviation was a person with a plane who would take you into the sky for money. It's like driving, but without a license, and up. A lot of people died. And then 100 years later, they got really good at it. In 2017, this is my favorite fact of all facts. In 2017, there were zero commercial jet aviation deaths in the world. Not one. You put these tin cans full of fuel, full of people, up in the sky, and it worked 100% of the time for an entire year globally. How do you get from there to there? And if anybody's ever read the book, Drift Into Failure, I recommend it if you work on anything critical. The path was actually pretty simple. You just figure out what are the things required to keep a plane in the air? Like, what actually do you need to do? And then, how do you need to organize people into roles to do that? And how do you train them? That's the work. That's all it is. And then the other one, medicine. Medicine's actually way behind aviation and safety. A lot of people are still dying in medicine. They invented the checklist manifesto, a tool to go on day. Yeah, they've got to figure out the checklist. Aviation's beyond the checklist. It's not in a book. It's in a response to the tool to go on a book. But I recommend them both. I'll recommend them both from the CTO of Mode Analytics, who's this here. Go join the company. They're amazing. But medicine is they have two things that we definitely need to borrow. One is the division of responsibilities into roles. Not necessarily titles, but roles. And the other is teaching hospitals. So let's talk about what you have in an operating room. In an operating room, a long time ago, that was just a doctor carving someone up. It's grown a lot since then. Now, everybody in an operating room knows what they're there to do. I was reading about a nurse who was saying that when he goes into surgery, he doesn't need to know any of the people. He just knows that if he's the tech nurse, he knows what he's required to do. He knows that everybody else is required to do. Like, there's a system for it. It's kind of like we have an incident response in our field touches on this. Like, we have an idea of instant leads and like those roles. But the rest of our work, not so much. So in an operating room, you'll get like a surgeon. And you may have an assisting surgeon. And you'll have a tech nurse, maybe a scrub nurse. You'll have an operating room nurse. You may have a vendor representative if there's some sort of hardware or tool that is in use that needs someone who knows medicine to consult on it. And you have medical students. And each of these people have very well-defined roles. If you are in an operating room and you're just a doctor, you don't get to be there. You have to observe. Like, what are you doing here? Oh, I'm a doctor. I'm just going to take doctor in here. What? You cannot interfere. This is a well-run team. We know what we're doing. And some of our teams are like that. But we haven't quite gotten there. If we were to imagine a software team of people at some hustling startup in an operating room environment, there'd be like a developer and then a senior developer with imposter syndrome, and then a junior developer who thinks they're amazeballs, and then another developer who works on tools and just cannot help but continually sharpen scalpels. And then another one who's always trying to find the optimum height of the operating table so everybody's moving around and it's like, version change, version change. And he keeps moving. And then there's like a boot camp grad who's had a whole other career already and the most junior person in the room and the only person who knows that that's the wrong patient. That's about how our teams work. About a year ago, I started thinking about, I was working on a startup, I started thinking about what are the teams that I've seen, been on or been around personally? Not like in blog posts and conference talks because you can't trust anything that you see in a blog post or a conference talk. For the ones that I'd personally seen that were really good teams. And I don't mean outliers, like some rare, hard to find team. Just like a decent team. What were the ones where, when requirements changed, the team could change with it? When a new person joined, they became part of the team. When a team that produced something that was usable by the people who used it. And if nobody is using something the team produces, that team should not exist, right? So that's core to the team. And I came up with a list of attributes that this team had, and it was just roles. And some of them were explicit, but some of them were implicit. And I've been thinking about what it means about our hiring process, what it means about our evaluation and promotion process, the way we talk about engineering, that these roles are totally hidden. But I think they appear in a lot of teams. One, it's a little more obvious, is the people leadership role. Now, you may take this for granted, but a lot of companies have no management layer or management layer that's so diffused that there's 22 people reporting to someone, which is the same as not having a boss at all. You have no support. You have no one to create an environment, a carefully curated environment, which you and specific other people can organize to do your best work. And a brief aside, there is a lot of literature on how when you leave IC track coding to move into management, it's a totally different job, and the feedback loop is a lot longer. I would say it's not longer. It's just that you're not good at it yet. So when you first started to code, the feedback loop there was longer too. And when you develop these skills, you actually can have an instant sense of satisfaction from leadership when you get good at the parts of leadership. The other thing they say is that you can't really apply your technical skills to management problems. I call BS on that. I think you have to leave behind the low-level stuff. You can't tie yourself to specific features. But you actually can take all the high-level concepts with you. Imagine if you've worked on a high-throughput, multi-agent, non-locking processing system, a bunch of things that coordinate with each other but don't block each other that each do work. That's an awful lot like designing a team that has high throughput. Like you can take the same approach. And I consider the people need to be absolutely a member of the team because they're doing the same thing. They're identifying problems, designing solutions, implementing those solutions, deploying them, maintaining and monitoring them. It just happens to be that the implementation is by collecting people. The deployment is by chartering and naming a team. And the maintenance and monitoring is by finding the metrics that that team really cares about that will let show them that they are making progress and give them feedback to course correct when possible and then supporting and empowering and unblocking each person. It's the same kind of work just applied to a different medium. And therefore, I really believe people lead in the same levels everybody else in the team. They're just sort of the meta support. The other thing I saw on a lot of teams was some sort of technical lead. Like this isn't particularly insightful. There's somebody on the team who understands what the whole team's doing maybe a little bit better, can go a little bit ahead and can scout out, oh, we need to make these technical choices now because we're gonna get into a hole later. It's great. If you don't have that, your team really needs that and you should hire for it. If you do have it, you can have some people out of the rules. One that surprised me a bit is I think all the teams had somebody who actually gave a damn about the people who used the output. Whether it was a customer facing product team and they cared about the customers and they got metrics for like signups, usage, feedback. What does the customer support team field in terms of feedback to iterate on the work and get feedback on the work? Even if it's an internal tool, you're building the deployment dashboard for your company. Do developers like it? Can they use it? Does it provide them meaningful data during post mortems? Like, is this something that people care about? Having somebody on the team who actually thinks about this, they may even contribute a lot less code. They might even be a PM. They might not write code at all. Having that makes the team more successful. But there was one more thing that I found as I was like digging through my memories that really surprised me. And maybe it's not the most important part but it's the most surprising part to me. All these teams had students. They had someone in a learning position. And I think I know why. And that's because teaching hospitals outperform non-teaching hospitals across the board. They cost more, just more price money going in. But they're lower in patient mortality, which, if you think about it, is the whole point of a hospital. So they're better. They're just better. And there's very few problems that can be solved with money. But when you find them, I recommend seriously considering just using money to solve that problem. There's like a couple in the whole world. One of them is you can add more people to a team if that actually will make the team better. And if those people are actually the easier ones to find because they're just beginning their career and they're looking for you and they're not getting headhunted as much, well, it's not actually as hard to find them. So let's talk about why does a teaching hospital outperform non-teaching hospitals? It's this thing called the paradox of expertise. It's also called the form of name is negative transfer, which only makes sense if you think about it as, well, you learn skills over here and then you try to transfer them over here, but something went wrong. So imagine you're a surgeon who started surgery in 2008. That's great. You're gonna get really good at 2008 techniques of surgery. It's 2018. You're really great at something that's 10 years out of date. Somebody who's just starting their feet in the field now has 2018 techniques. Who's the better surgeon? Well, it's a wash, but research shows that three years in, the new person will be better than you at 13 years in. And that's because you just didn't keep up. You didn't learn and iterate. You didn't have to keep learning the new things that everybody else was learning. And I'll say a brief story time. I've been a victim to this and I didn't see it coming. I was at Square in 2011 and this company started in 2009, which was before AWS was PCI compliant. So you couldn't use AWS for this, which meant we racked our own hardware. There's somebody who was on salary with stock and benefits who had to call on a phone, somebody else who had a telephone who was at Dell and they'd say, how many things with what CPUs and memory they wanted from Dell to be put onto a truck and driven to a big warehouse that was a data center run by Equinix in San Jose. And then when it got there, Equinix would take the stuff out of the truck, bolt it to the wall, and that's where we came in. So we had to have our own images of Sentos that we used to image each machine. And then we had to figure out how to use our root cert to sign a new X509 certificate for each of these machines in a way that we didn't have to have someone on premise to do each one. And there's a bootstrapping problem there. And if you're at all impressed, I'm flattered, but those skills don't translate. It's 2018 now. A year ago, Amazon launched a thing called Fargate where there's a Docker image, you give it to Fargate and it runs. Where? You don't have to care, it just runs. So somebody's been working on Fargate for the last year and I know how to screw together blade servers running Debian or something. Who's the better person to put it in charge of a highly concurrent massive modern web app? It wouldn't be me. It would only be me if I had to onboard and train the new person who's working with Fargate and I had to keep up with my skills. All right, let's review. People grow in unique and interesting ways. They are, it is not a line. It is nowhere close to getting to a bar that you pass. That does not happen. Also the field is vast. I put 10% here as what nobody knows 10% of software. Nobody knows 0.01%. And that's because the process of learning this craft involves writing software. Each of us has written more software than we have time to read, much less read each other's. And that's just the people in this room. There's no way someone can get close to approaching even like a little bit of what is out there for software. It really does take people with completely non-overlapping or barely overlapping skill sets to start to cover some of this space. A team requires people in many different roles. You cannot have a successful surgery with only surgeons because if you don't have an anesthesiologist, that patient is awake, you can't do it. And you also can have only anesthesiologists. That's just sleeping. If you have a team with only people leads or only technical leads or only product-minded people or only tools people, it won't be effective. And if you lack any of those, it won't be effective. And those are people with different inclinations and different backgrounds, different skill sets. And they came in the industry probably from different directions. And lastly, students help the team. There was a new security engineer who joined my team a few weeks back. And day one she started asking, how does this work? How does that work? Can you explain it to me? And just tore through Terraform and Chef and AWS and Kubernetes and security groups and IAM roles and are like Ruby monolith and she's finding slow queries from my SQL query log. And she's just all over. She's asking everybody to show her what's what and the entire team sort of woke up a little more. Because well, now we have to keep up with her. And we're learning. I'm learning more. So if there's one concept that we can, I hope that you go away with, it's this. There is no such thing as a real engineer. That has been a plague on our industry for a long time. There's no such thing as a valid hiring bar. There's no such thing as a real engineer. Would you say that with me? There's no such thing as a real engineer. One more time. There's no such thing as a real engineer. One more time just make me feel good. There's no such thing as a real engineer. There are engineers of various types. And there's no one of them who reaches a point with like, ah, I don't have to worry about imposter syndrome anymore because I haven't figured out. I hit the bar. I'll pass all the interviews now. Like that doesn't exist. The most beginner boot camp grad can positively influence your team. And some of 40 years of experience may also if they know the right stuff. This is something I love this. This is from Medium. They put together this thing called Snowflake that is a beautiful visual representation of how they see levels in different skills and knowledge areas for their own promotion system at Medium. And they broke it down to four sections in the bottom. It's the what, the how, the context, and the people. And each one, you could be like a one or zero through four. And you add up the total points and it has this really cool visualization off the top right and that's your level. But they don't confuse linear level with the much more detailed stuff below that. And one of the things I love about this is if you zoom in the bottom left there, all of the what is mobile web client foundations and servers. Servers is like a billion things, right? But not at Medium. At Medium, that's one of the 16 things that you need to be successful. And I really appreciate that Medium makes no attempt to say this is what it takes to be a real engineer. They say this is what it takes to succeed at Medium. And if Medium goes into a different area of the market, it goes into a new product space, these will change because the work is different and the needs will be different and the skills they need to hire for and promote based on are different. So just imagine if you were able to figure out what skills were necessary to succeed at your company and your organization, what actually does it take to succeed? And then you found a way to measure for those. Maybe they're technical. These are just technologies I've listed because they were conveniently one word. But when you talk about collaboration or community, okay, yeah, but what kind? Like specifically, do you need someone who's friendly because you have a bias toward a toxic culture in your industry? Or do you need someone who can initiate conflict when appropriate, hopefully both? How do you measure for these? How do you measure for the actual skills? And really, once you have a map of what's necessary at your company, well then you can do something interesting. You can start to ask candidates what they're good at and you can evaluate them specifically on the things that they claim to be good at and how they map to things that you know relates to what's useful at the job. The bit in the middle, the interview panel, it would be unique for every single person. It would have to be because there's no, that's such thing as a real engineer. There's no one way to do this. You just gotta find out can the Venn diagram of this person and this company produce value here. It's time that we fully, completely give up on the concept of engineers fitting a mold. So let's hire people and develop them based on the actual skills that our companies need and the actual skills they want to grow into and the roles they want to grow into. Ignoring the skills they don't have as long as somebody else in the team has them. We don't need everybody to have any one skill. Really, it's just editing text files. That's the one thing that we all have to do. And that shows up in every other skill. So if they can't do that, they don't have the others. If they manage to get the others, that's amazing. Maybe they're blind and they do it entirely by dictation. That's fantastic, that's cool, hire. But there's basically nothing besides editing text that is necessary to succeed in this field. And if we do that, hopefully, we will get away with no longer asking people to implement binary trees and we can start interviewing people in a way that shows off their rich humanity and invites them to be their full selves in our companies. Thank you very much. The question is, what if you know you as a company know that you need a skill and no one in the company knows it in order to be good enough to evaluate for it? Yeah, that's a really hard question. It's actually a really common problem too. The two ways of knowing to do this are, hire someone who just claims to be good at it. I mean, that's how a lot of us got our first jobs. I don't know. Another way is to put together a test to build a thing that uses that technology or something during the interview and just freely admit, we don't know how to do this, we're hoping you do. That's how senior talent is hired. You don't hire a CTO by saying, we're all CTOs. Come in and show us you can do it. It's more like, will you come show us the ropes? So, and I gravitate toward that, honestly. The last startup I was with, it was called Absolutely. My co-founder and I, Kate Huddleston, we interviewed our first hire by asking her, you're gonna be an early engineer at this company. You'll probably be an early leader. Therefore, we need to know you have leadership ability. Your role in the interview is to make us interview you. Design your interview panel, because that showed off the creativity that we knew she would need to be able to succeed in that role. And she killed it. We're like, strong hire. That was amazing, so we brought her in. Does that answer your question? Okay, that's a good question. The question is, if we don't have titles in our roles, how do you know whether you're in or transitioning out of a student role? Is that the question? I would say that you don't have to be beginning your career to be a student. In fact, it's just as effective if you take a very senior person and you move them from one role to another. One of my friends at Square was a systems engineer working with our MySQL clusters and he was getting burned out. And so, his manager said, well, you know C, right? And he just walked him over to the iOS team. And just like, here's your new iOS developer. And he had to learn everything from scratch. He was super senior in some areas, super junior in others. And there was no line at which he stopped being a student. But if you find that, the way I think of it is, everybody in your team should be the tech lead, a people lead, the product lead, an explicit tools person or a teacher. If you find that you're just generic engineer, you need to go find some students. But once those people are grown such that you can't tell who the students are exactly anymore, you'll find some more students. Yeah, the question is, we talked about interviewing, but how do you deploy these ideas in onboarding and afterward? And I'm assuming even through the promotions and long career work. The main prop, like the main glitches you're onto, the main sticking points are at the interview stage. Once people get through, they can say, by the way, there's some things wrong about how you interviewed me. Then they have the cloud to start to make systemic changes. So don't worry about it as much once someone's in the door. But when you're onboarding, I think that, and I don't have any specific suggestions here, except that the onboarding definitely needs to be, here's what we have, what do you have? If that's the framing of the onboarding, then the company will continue to grow in a rich, culturally additive way. It's like this is old saying in therapy, if you wanna actually connect with someone, say, I am here, where are you? We do the same thing with our new engineers. So we've done this so far. It's worked somewhat. Here's how you couldn't navigate it. What do you have for us? And can you please help us fix this? And then everybody's in a bit of a student role there for a while until all the information is exchanged across both barriers. Okay, we're out of time. Thank you so much. I appreciate it.