first talk in 10th Paa at Char 2017. Einstein once described it as a spooky action at a distance. Now we're building communications networks with them. We're building communication networks that could provide a fundamentally secure way to communicate where the privacy would be built at a physical level. And this sounds really awesome and interesting. So here to present an invitation to help her us build a quantum internet is Stephanie Werner. Please give her a very warm round of applause. Well, thanks for the nice introduction and thanks all for coming here after dinner or before dinner or after drinks or before drinks. So before I start with talking about the quantum internet which I guess from the first slide might indeed seem a bit spooky, I want to ask you a question. Namely, I want to ask you what happened on the 29th of October, 1969. Any takers? Star of the Internet, very good. We have experts, we are of course at Charon. So in 1969, the internet I guess as it's known today was slightly smaller. And in fact, I guess it was this time it was called ARPANET and it consists of only four nodes connecting a few universities in the US. Namely, UCLA in Los Angeles, Santa Barbara in Stanford and the University of Utah. So like on this day, these guys in fact made the first transmission over the, I guess this early packet switch network. You can see that they're working very hard. They're at 9, 10, 30 in the evening. They tried to kind of communicate over this network. And I guess as the story goes, this communication was not so easy at this point. So they in fact wanted to call each other on the phone in order to verify that the transmission worked correctly. So Charles Klein was down there in Los Angeles and he called up to Stanford to verify whether the kind of packets actually arrived. So they call each other on the phone and they type an L and they ask, did you see the L? And they get an answer and he says, yes, we see the L. It's excellent, we've just kind of transmitted the first message over what is now with the internet. So they typed the O and they asked on the phone, did you see the O? And reply comes, yes, excellent, we did see the O. So they typed the next letter and in fact, the system crashed. So at this point in time, like sending messages over the classical internet was not so easy. Of course we know that it works something like this and so this is kind of our what's that group at UTEC and we can now quite confidently kind of send messages over the classical internet, even pictures at any point. At day, right. So what I want to talk now is, I guess, let me say taking this to a next level, namely instead of kind of talking about the classical internet which I guess you're all familiar with, I want to talk about the quantum internet. So this is some effort actually that we have in Delft, of course there's other people working around here. So this is I guess the effort that requires of course a lot of people to be involved. So at UTEC kind of one of our goals, in fact is to build the quantum computer and one of our goals is to realize the quantum internet. So these are some of my colleagues, so Ronald and Tim who kind of work in the lab, they kind of make hardware and David who's one of my theory colleagues and with myself and we also have an engineering team at TNO which is very essential and in order to realize this. So we're currently working quite hard to kind of achieve this 2020 goal of actually setting up a demonstration network here in the Netherlands. Incidentally, I guess we're aiming it to have four nodes as per convenience and connecting Delft where of course we are the Hague which is recently closed and Leiden and Amsterdam. So we are of course not alone in the work, so we are part of the European Quantum Internet Alliance which kind of contains some of our collaborators who kind of help us realize this goal. So of course you might now be asking the question so what is a quantum internet and kind of what makes it different from a classical internet? So I'm painting here sort of a cartoon of a quantum internet that just like in the classical network you can imagine that kind of the quantum internet connects computers but of course in this case not classical computers but actually quantum computers by kind of optical communication. So kind of the aim of a quantum internet is to enable quantum processors to kind of exchange qubits potentially over long distances. In kind of exchanging qubits, they might also sort of create entanglement between them as per this purple line. So the ultimate, I guess, dream or the big ground vision of a quantum internet is to enable quantum communication or the generation of entanglement between any two points on earth. So you're probably getting a bit worried about this given that you've sort of read about the quantum computer and you're thinking, oh yeah they're building a quantum computer and now also the quantum internet and she's telling me that like making a quantum internet is like attaching quantum computers to optical communications. First I need the quantum computer and then I also need to connect it, it's usually complicated. So kind of the nice thing maybe about quantum communication is that it derives its power, I'm gonna say a bit more about this from quantum entanglement. Of course quantum computers also do that but the quantum computer kind of becomes interesting as long as soon as kind of you have a number of qubits or quantum bits, then you can no longer simulate efficiently on a classical supercomputer because you know why you get a quantum computer if I can run it on a supercomputer. So in contrast to that kind of all applications of a quantum internet derive their power from entanglement and already two qubits can be entangled with each other. So it actually turns out that in order to do something useful with this we don't need very large quantum computers meaning very many qubits but actually relatively modest size quantum computers are already sufficient. So let me maybe say a little bit on why one might actually want to do such a thing. Apart from the fact that of course it might be cool to generate entanglement between any two points on earth. So there are of course some applications and I guess probably the most well known which maybe here I don't need to explain in such great detail is the fact that we can use it to communicate securely and I'll say a bit more about this in a second. But even though of course everybody usually thinks about secure communication as in fact the introduction already highlighted there's actually very many other things that one can do using quantum communication. And yes, I know that we are at Char so probably secure communication is kind of important but there's other interesting applications actually which are maybe a little bit less well known. So one of them for example is the fact that quantum communication allows you to synchronize clocks much more accurately than can be done using classical communication. In fact if you want to get a bit crazy it can also be used to extend the baseline of telescopes. So essentially how this works is that you have two telescopes which might be very far apart and you can think that kind of one particle of light is being actually teleported using entanglement to the other telescope where you can do an interference experiment. So this allows kind of the extension of baselines that have over much larger distances. Of course we can use it to kind of test various aspects of physics for example the gravitational effects if you care about such things. Let's just like a quantum computer can lead to exponential savings in time like it's much faster. A quantum internet can in principle lead to exponential savings in communication. So there's certain tasks which I need to communicate exponentially fewer quantum bits than I need to communicate classical bits. Now of course as I'm gonna tell you shortly communicating quantum bits is pretty hard. So you might say yes there's some exponential savings but it's like super hard to send these qubits around. So of course exponential is like a dramatic scaling. So even though I might need kind of exponentially more classical bits it might still be worth sending qubits. But if you're not convinced by this and like I said there's many more applications actually that are not mentioned here that are related to synchronization and coordinate nation tasks and distributed systems for example. And if you're not convinced one can even use it to cheat certain games. So people have proposed that two players who want to play a card game like bridge actually even though they don't communicate they can have entanglement they can kind of cheat this game. So maybe there's some potential for the future like you know Char in 2030 and hacking using quantum entanglement. Possibly. So of course you know like just like classically you can use quantum communication or kind of communication to actually access computers also to link computers. You can also use quantum communication to either sort of wire up small quantum computers into a large quantum computing cluster to be more powerful or you can use it in fact to access and quantum mainframe. So I don't want to kind of make a statement of course that quantum computers will only exist in the basement but you can think that in the at least somewhat near term future quantum computers I mean will exist not everywhere sorry to disappoint you in your house but they will probably exist in very few places like our lab in the near term future going back to some area known as mainframe. So you can imagine I have a quantum computer in the basement you only have a very simple quantum terminal on your desk and nevertheless you want to run some kind of interesting computation on that mainframe. So it turns out that in fact it is possible to kind of compute something on a quantum mainframe in the basement in such a way that you don't need to tell it at all what you're computing. So it's possible in fact with information and theoretical security to perform a communication on a quantum device and without informing this quantum device what you're actually doing. So if we kind of want to access quantum computers securely in this way in the future and then we also kind of want to send qubits around. So that's all very well you know there's some applications but the question or that might be on your mind is like why can I not do these things using classical communication? Or rather kind of what makes qubits so special that kind of we can achieve all these kind of tasks while kind of classical communication is less powerful. So of course you've probably seen all these talks right you're probably waiting for me to say that kind of qubits can be both zero and one at the same time like they can be in some superposition a particle can be both left and right at the same time maybe a thought but there's a lot of videos out there that will tell you about this. So it is true and if qubits are quite special they can be both zero and one at the same time but what really kind of gives quantum communication their power are essentially two features of quantum entanglement. So I want to tell you about these two features of quantum entanglement which kind of intuitively at least explain or give you some feeling for what kind of quantum communication is good for and why. So let's imagine that we are kind of have Alice and Bob we like to talk about Alice and Bob all the time and let's suppose that they actually have already two qubits kind of which are depict by these boxes and they are actually entangled with each other. So for example, such two entangled qubits can be created by Alice having two qubits entangling them and sending one over to Bob over the quantum internet. Okay, so now they have two entangled qubits and entanglement has a very nice feature so this is feature number one, namely that even though it does not allow faster than light communication, it allows something which is called maximal correlation. So let me explain what that means. So let's imagine that Alice and Bob are possibly far apart to make this maybe a bit dramatic. Let's imagine that Alice is here on earth and Bob is on Mars and they have these entangled qubits. Alice has one and Bob has one. So let's imagine that they make a measurement on this qubit. For example, they measure and they want to know is it say red or green? So measurement that has two possible outcomes and the cool thing is that even though this measurement outcome does not exist before, so these measurement outcomes are actually randomly generated, if Alice measures and she observes that the particle is red, then Bob, even though he may be arbitrarily far away, also observe this particle to be red. And similarly, if Alice sees that it's green, then Bob will also see that it's green. So remember that I said that these are kind of randomly generated, so they couldn't know this ahead of time, okay, this does not yet exist. Nevertheless, whatever outcome Alice gets, Bob gets exactly the same outcome. And this in fact is true for any measurement that they might make. So not just if they ask if it's like red or green, but for example, if they were to ask, is it like pointing up or down? If Alice sees that it's up, Bob will always also see that it's up. So this is feature number one of entanglement, okay, which is called maximal correlation. And that's actually already pretty cool because it's sort of at the heart of why entanglement is extremely good for tasks that require coordination, like synchronizing clocks, for example, or also sort of synchronizing things in distributed systems, for example, like agreeing on a bit and various other tasks where coordination is kind of the essence. So having entanglement kind of allows you to coordinate actions much better than can be done classically. So let me now go to feature number two, which is actually pretty cool. So not only does entanglement allow maximum correlation, but entanglement is also what we call inherently private. So let me explain what this means. So if you have Alice and Bob, you might have asked the question, well, you know, Alice has a qubit entangled with Bob's qubit. Maybe, I don't know, there can be a third qubit held by someone else that is just as entangled with these qubits as Alice and Bob, okay? So maybe it could be that his qubit is just as entangled with Alice's qubit as is Bob's qubit, meaning that they could all be sort of like maximally coordinated at the same time, for example. So the cool thing about entanglement, actually, is that the answer to this is no. So it is not possible, in fact, for entanglement to be shared. Like if Alice and Bob have two qubits and they're maximally entangled with each other, it is kind of physically impossible for anything else in the universe to have any share of that entanglement. It's pretty cool, yeah, I agree. So this, in fact, follows from all kinds of physical principles. For example, if this was not true, you could kind of send information faster than light and physics would actually look very different. So this is kind of a fundamental feature of quantum entanglement that does not exist in the classical world. So note that this feature of entanglement actually already also tells you that you cannot just copy qubits. If you could copy qubits, you might imagine that Bob can make a copy of his qubit, give it to his friend, I don't know, turn it to a dark side. And we would have three qubits which are all equally entangled with each other. So entanglement cannot be shared. This is known as the monogamy of entanglement. If two qubits are maximally entangled, nothing else can be entangled. So this has some very kind of profound consequences if you think about it. Particularly, it means that if we could somehow test whether our qubits are entangled with each other, we know actually that we are inherently private and nothing else can be entangled without a qubit. So the question is, is it sort of possible to make a test that checks whether we are sort of producing entangled qubits or whether maybe there's kind of a third party that has some share of this entanglement? So the answer to this in fact is yes. So this has been kind of discovered actually by John Bell already quite a long time ago, somewhere in 1963. And he observed that kind of if you have entanglement, you can observe certain statistics, certain correlations between different qubits that cannot be generated physically. There's no explanation for this. So this means that we have kind of a means to verify essentially whether we are producing entanglement. So before I continue with this, let me maybe kind of say that by sort of checking or kind of producing such entangled qubits and verifying that they're entangled, and we can actually also see whether kind of these qubits can be described classically or not. So kind of testing for this entanglement apart from the fact that we'll have very cool applications in the quantum internet as I explained shortly, also tells us something quite fundamental about nature. Namely, it tells us that there's certain sort of correlations between distance systems, say Alice and Bob, that cannot be explained by classical information. It tells us that these kind of measurement outcomes cannot be sort of classically described by pieces of paper attached to these particles. And I just see the answer when I measure it. So such tests can actually be performed. We have performed such a test in 2005. So this is our campus, in fact. So this is kind of where our offices are. And this is 1.3 kilometers away on the other side of campus. So this, in fact, will be done. So let me now say a little bit kind of about the applications of the quantum internet. And I actually want to talk only about the most famous ones, given that it's also about SAR, and you probably also care about security. So let me now explain a little bit how we can exploit these two features of entanglement, the maximum correlation and inherent privacy, to communicate information securely. So I'm quite sure that everybody here knows about encryption, but I nevertheless want to be absolutely clear what kind of situation we are considering here, okay? So the situation is as follows. Let's imagine that we have Alice, who wants to, even after she kind of leaves Char, sort of, I don't know, communicate with Bob. So we want to transmit a classical message, and we want to encrypt this classical message. So the kind of concern here is that there's someone listening into this communication. So they want their communication to be private from some kind of eavesdropper who's trying to intercept. And I guess you all know that one way to kind of go around this is, of course, to use encryption. And encryption, of course, requires some kind of key. That's many encryption schemes. And in a classical kind of symmetric encryption scheme, for example, Alice has two key, Bob has the same key, and they can use this, I guess, just like in a safe, put the message in the safe, send it across. And if I have the right key, I can open it and recover the message. I'm sure you all know how this kind of works. But the question is now that you might sort of ask yourself, is where does this key come from? Or maybe more specifically, how much key do we actually need? So this, some people have actually thought about a long time ago. So there's this really excellent person, Claude Shannon. There's a very beautiful article in fact in New York, which I highly recommend. And he has established actually already quite some time ago now, that in order to be absolutely secure, meaning that kind of the eavesdropper genuinely gains no information. It's not like he's not powerful enough or might need a long time, but really there's no way to kind of get the message. You need a key just as long as the message. It also means that if you send several messages, like one big message, you need kind of more and more key as you keep sending messages. So this of course a little bit annoying because it means that even if Alice and Bob might say exchange some key already here at Shawan, sooner or later they really get to like each other, they want to send more and more pictures to each other, they will run out of key. So it turns out that in fact classically, it is impossible without all kinds of computational assumptions which may or may not be true, to produce key or in fact to produce more key. So even if Alice and Bob kind of exchange kind of a small amount of key here at Shawan and later they run out, there's just no way for them to make more of it. So there's maybe a question that you might be asking is why classically, is it not possible to kind of turn a small key into a larger key or make any key at all? So classically, information can be copied. This means that if Alice sends a message over to Bob and the eavesdropper can intercept it, in fact the eavesdropper can kind of read anything on this communication channel, the eavesdropper knows exactly as much as Bob. So eavesdropper knows just as much as Bob does, but Bob is of course supposed to learn the key. There must be a way for Bob to learn the key, otherwise Alice and Bob cannot change information later. So if there's a procedure for Bob to kind of learn the key, of course also the eavesdropper who has exactly as much information is also able in principle to learn the key. So kind of this is very intuitive why in fact, it is not possible classically to produce more key. So the cool thing is actually that using quantum communication, it is possible. And like I said, I want to kind of explain to you how these two features of entanglement actually make that possible. So you might be surprised that actually the theoretical ideas of quantum key distribution go back a long way in fact to the 70s, where of course people could not send qubits, like this was a totally absolutely theoretical idea at that point in time. But nevertheless, if it was observed actually already by Stephen Wiesner, that this in principle might be possible. So of course we're a little bit further along, so people have proposed schemes. And I want to give you an intuition actually about this beautiful way of looking at quantum key distribution and put forward by Arthur Eckert in 99 that exploits precisely these features of entanglement. So QKD quantum key distribution from entanglement works as follows. I'm gonna give you like a cartoon of this protocol, of course to make this work exactly is a bit more complicated. So I already told you that kind of entanglement is very useful. So let's think about how we're going to produce use entanglement to make key. So kind of a cartoon version of this protocol works as follows. Alice produces two qubits which are entangled with each other and sends one of them over to Bob. Of course somewhere on the way maybe the e-stoppers intercepting it, we don't know. So they're gonna do this very, very many times. Remember that we know that Alice and Bob can check whether their qubits are entangled with each other. So what they're going to do is they're going to send very many qubits across and some of these qubits they're going to test and they're going to ask, are these qubits still entangled? Yes or no? In fact, like I said, things are a bit more complicated. In fact, one can test precisely how entangled they are. But Alice and Bob are going to perform this test. So if the test succeeds, then they're going to measure their entangled qubits to produce a key. So I've given you these two properties of entanglement and I wanted to now use them to explain why such a protocol might actually work. So can someone remind me what is feature one of entanglement? Yeah, so they're inherently private, exactly. So this was one of the features. What is the other feature? Correlation, okay, very good. So note that any kind of key exchange system before we even start caring about security, it certainly must make sure that Alice and Bob have the same key. Otherwise, they cannot communicate. So the scheme should be correct, which means that they should have the same key. So let's remember that entanglement kind of achieves maximum correlation. This means that if they measure the entangled pair, they get a random outcome, either red or green, but they both get the same. So if we were to use this outcome as a key, certainly we've achieved task number one of any key distribution scheme, namely that they actually have the same key. So I was reminded, in fact, that entanglement is also inherently private. So this means that if Alice and Bob actually have entangled qubits, then we know that nothing else in the universe, in particular any eavesdropper that kind of tried to intercept this entanglement, can have any part of this entanglement, meaning that also the key is completely private, because nothing else can have share of the entanglement. So this is kind of how these two features of entanglement lead to security of quantum e-deceivation. Of course, I mean, things are not so easy in practice. In practice, there will be some error on the channel, there will be somewhat entangled. So they have to kind of do some error correction and private implication. But this is really the sort of essence or the intuition of why quantum key distribution works. And we again see here why also like classically this cannot be achieved. So this, of course, you can achieve. You can always achieve maximum correlation. I could, for example, just send the bits to Bob. Everybody knows them, Bob knows them, eavesdropper also knows them. But kind of entanglement ensures that this is also private. So I've been telling you that with entanglement, one can do all these cool things. So you're possibly asking actually, what is the state of the art? And I actually wanted to start with something very recent, which has done by a Chinese group, which is in space, which has generated entanglement of the distance of 1,203 kilometers via satellite. So this is an amazing achievement of engineering. So you can imagine that just like in a classical internet, we will have sort of ground-based networks to connect nearby areas, say, Netherlands. And we will have satellites to sort of bridge very long distances or longer distances than on Earth. So this, in fact, can be done. It is relatively slow. So entanglement is generated at the rate of one hertz, roughly one per second, over such a large distance. So on the ground, in fact, communication is relatively mature at short distances. In fact, if you want to do quantum key distribution and you only care about short distances, you could buy one of these boxes, like made by my IDKontique, Huawei or Toshiba. You can install it and you can plug in some fiber and generate keys. So the kind of grant challenge of quantum communication is to, in fact, bridge these long distances. So if you Google around on the internet, you may also learn that there are sort of ground-based networks when they might kind of indicate, you might think that they're already very large. For example, from Beijing to Shanghai, I guess it's not so visible on the slide. But these currently do not yet allow the end-to-end QB transmission. So these are called trusted repeater networks, just with the trivial extension of what I just described. So let's say that Alice and Bob are kind of too far away to kind of use one of these, I guess currently commercially available QKD systems, but they can ask the help of their friend. So Alice could kind of make a key with her friend. Bob could make a key with this guy. And of course, as long as they trust him, they can then kind of do end-to-end communication. So this, of course, is some nice engineering and kind of allows you to test certain deployment. But of course, this is not what one wants to achieve so in fact, true kind of quantum communication from end-to-end does not need the trust of an intermediary person. Because I guess we all know how that ended. So the question is sort of like, given that we can do quantum communication at short distances, how can we go beyond that? And of course, you might ask the question is, why is long distance quantum communication actually difficult? And there's essentially two reasons for this, one of which which I've already alluded to, namely that it is fundamentally impossible to kind of copy arbitrary qubits. So this is kind of a problem because it kind of means that we also cannot try again. So repetition is ruled out as a means to correct errors. Currently I'm wearing a microphone, usually I don't talk so loud, but if you don't hear me, I can just repeat the information, I can resend it and I can overcome losses. This is not possible using quantum communication. If I want to send a qubit and I lose the qubit, there's no way that I can sort of have copied it and resend it. So the second reason, so this is kind of a fundamental reason, the second one is a technological reason, in the sense that it's very difficult, or I guess currently still very difficult, to manipulate many qubits at the same time. So if you're kind of following the news on quantum computing, like the sort of largest general purpose, like for any kind of computer is only 17 qubits. So this also means that we cannot do large-scale error correction. So it is in fact possible, just like in classical communication, that even though I cannot copy qubits, I can sort of dilute them, I can sort of add some redundancy, such that if some of these qubits are lost or destroyed, I can nevertheless recover the original qubits into error correction.  So of course it's desirable to sort of avoid large-scale, the need for large-scale quantum communication to bridge large distances. So how can one nevertheless kind of hope to bridge large distances? So there's a very neat trick to this, which is based on something called content teleportation. I'm sure many of you have heard about this before. But in this context gives a very cool feature to actually transmit qubits. So how can we actually transmit qubits? So one of them of course is to by direct transmission. I have a quantum channel, for example, a telecom fiber, and I send my qubit using a photon. I send the particle of light. Another way to send qubits is by using teleportation. So let's for the moment imagine that Alice and Bob already had entanglement. For some reason they've already managed to have two qubits that are entangled with each other. And we're also going to allow them to communicate classically. For example, over the standard internet. So quantum teleportation allows us to use this entanglement to now send the qubit. So how does this work? Alice is going to perform a measurement on say the qubit that she wants to send and the entangled qubit. She's going to kind of get some kind of measurement outcome which is going to send to Bob. So Bob still has the qubit, like from his end of the entanglement. And based on the measurement outcome, he can apply correction information and recover the qubit. So you might say, you know, this is all very great. Why do I care about that? Because first of course, where does the entanglement come from? First I need to make the entanglement and I can teleport or what have I gained? So the cool thing about first making entanglement is actually two for it. First of all, note that if I produce entanglement, I know exactly what quantum state I want to do. I can build a machine that tries in producing its entanglement many, many times. This also means that kind of if I send kind of entangled qubits, I can now try several times. So repetition is again kind of allowed as it means the correct error because I know exactly what I want to do. So I have a machine that produces entanglement all the time. Once I succeed, I can teleport the qubit. So there's one cool feature but the other cool feature can actually be used to bridge long distances and this is what is called a quantum repeater. So let me give you a little bit of a cartoon here. So every one of my kind of blue circles is a little quantum computer, okay? So this is the Alice's. This is the repeater station in the middle and this one is the one of Bob. And let's now imagine that kind of using these colored balls up here. Alice and this in the middle repeater station already have made entangled qubits. For example, because Alice is very close to the repeater station, she prepares two qubits, sends one of them to the repeater station. So let's do this again, okay? So Bob and the repeater station are also quite close to each other. So Bob can, or the repeater station can make two qubits that are entangled and send one of them onto Bob. So now we're in the situation of Bob. So Alice has entanglement with repeater, repeater has entanglement with Bob. So note that teleportation is able to teleport any qubit. In particular, it can be used to teleport one of these qubits from the repeater to Bob. So this means that I'm kind of consuming the entanglement here, but the entanglement that Alice has with the repeater is now transferred to entanglement between Alice and Bob. So now suddenly I have entanglement over longer distances. Now I have entanglement over distances where they could not directly transmit qubits. All right, that's great. But now we know that we have entanglement over large distance. And now we can use this entanglement to teleport the qubit across. So this is kind of the basic idea of quantum repeaters. If you first make entanglement and then you transmit qubits by teleportation. Okay, so like I said, again, this is nice because one can try again. And also the operation is actually reasonably simple. So if I can go back to my cartoon of a kind of quantum network, which really is like a cartoon, apart from these sort of quantum computers at the end, one also needs to realize these quantum repeaters, kind of in these intermediary stations that allow us to generate entanglement over long distances. So let me now say a little bit kind of about the state of the art. So there exist kind of several systems. We have one which is called envy centers in diamond. So these indeed are indeed diamonds. They're of course not natural diamonds, they are artificial diamonds. And you can think that they're kind of small quantum repeaters. So in fact, like a diamond, if it was completely pure, I guess would have no qubits, but one introduces effects into this. In fact, they're called color centers. It's what gives diamonds their sparkle. And in each of these kind of defects, and there are several qubits that can be addressed. So they have roughly six qubits and in principle one could, I guess, more. One cannot store these qubits forever, maybe right now. And one can generate entanglement between such two sort of diamonds over some distance. So this is kind of the system that we're using in the universe. There's a few more. For example, one of them with our collaborator with Tracy in the Innsbook, and there's also Chris Monroe in the U.S. There's also a few groups in the U.S. at MIT in Harvard which also have stars in the sky. So what does this look like? Okay, so that's what it looks like. There's like a diamond. It is kind of mounted on this chip, which you can see here. It was actually cooled down before Kelvin. And indeed in this diamond, there's an electron spin, and in the vicinity there's several kind of nuclear spins which are qubits. So I guess I don't want to say too much about this. But because my talk, I guess, was also called, I guess, invitation to consider quantum internet, I wanted to talk a little bit now about kind of some of the sort of classical problems which are actually not something someone should do with the quantum hardware itself, that would need to be solved in fact in order to realize the quantum internet. In fact, also to do meaningful things for the quantum internet. So I guess you all know that kind of the classical internet also does not work just based on hardware. So if I were to describe a protocol that says, you know, I don't know, Alice sends a message to Bob, then that's great. But like how does the message actually go to Bob? Somewhere in your lab, I guess it was like on your computer, there's a piece of hardware, but if you don't run anything on your computer, it will do exactly nothing. So the question is sort of like how kind of, do these kind of applications, how are they actually sort of realized on this underlying hardware? And I should say that actually this is something that is currently quite open. Currently trying, in fact, we've cooked up all kinds of sort of intermediary protocols that all talk about this. And I wanted to kind of give you only one kind of example, in fact, that already illustrates that in fact, also the kind of classical network stack that some of you all know and love kind of needs some extensions here. So let me remind you kind of what kind of IP packet looks like, of course it says like, where's the packet going to? Where does it come from? But in particular, it also has this thing down here, namely the data. So it's sort of convenient that I can here send the data together with the classical control information over the same wire. That's kind of convenient, it arrives all nicely together. So this is not possible here in this kind of quantum hardware because the qubits live inside this device and the kind of classical control information is sent over kind of a classical channel next to the quantum channel. So the first thing, in fact, that we need is some kind of layer that combines kind of these qubits with this kind of classical control information. Simple sort of first step. So it kind of defines such a thing. If you remember now how I've said we're going to actually transmit qubits, namely by teleporting them, you immediately see that kind of we also need sort of a protocol to keep track of this entanglement. In fact, I can already generate entanglement over very long distances. Maybe I swap in the background. There's some background process in my network that continuously produces entanglement, but I need to keep track of it. If you wanted to kind of go a little bit further up, you can think about kind of how do we actually route qubits around. Yes, I can send them over the kind of from one end to the other. But if you think about that we can send qubits by teleportation, it's sort of obvious that in fact I could maybe, if that's convenient, I always communicate several over a particular place long distance away. I could generate such long distance entanglement ahead of time. So kind of routing can be quite dynamic actually if I can produce entanglement. So these are all sort of questions which I guess we are currently thinking about, which I find them quite exciting and interesting, which are kind of currently in fact unsolved, but which of course are needed if you want to kind of do quantum communication over large distances in a meaningful way to actually do something interesting. So in order to do this, I guess we are still writing some documentation, so it's easier to kind of understand this. We have actually, I guess this is mainly made in Manj Ladler for you or for the community, to kind of, we have a simulator in fact, which will simulate qubits for you. You can install this on your computer, this on my computer and your computer, somewhere in the background these kind of will talk to each other and pretend to have qubits. So you can basically have it right, sort of a classical client that can communicate through this sort of back simulation and also for Bob. And you can kind of ask it to create qubits, measure qubits, send instructions to the qubits, send the qubits around to the other node. So kind of our simulator can be programmed directly in Python or Twisted, this is of course not exactly how we're going to program this. So we're aiming to actually once we release it completely publicly and to put the same interface as we would use on our 2020 demonstration effect. So I will announce this on Twitter, once we kind of have the pre-data if you're interested. And of course you can now explore sort of like actually what do I need to do on this kind of classical layer of communication to kind of control and keep track of the entanglement here, to send qubits around meaningfully and to actually realize the application. And here in the end of my talk, I also have a very shameless estimate for the somewhat younger people around here. So we do have kind of a master program at Q-Tech for excellent students. And so if you want to feel challenged and join us in this endeavor, you can talk to me. You might ask actually, what is Q-Tech? So like I said, we are a collaboration between TU Delft and TNO. So I guess as you know, TNO is kind of applied research. We have what is called the National Icon of Inevitance. So we have all kinds of support in order to realize these things. And so our goal is to realize the code computer and obviously your code in there. And we also have some partnerships down here. So if you wanna do more about this, kind of stay tuned for the release of this monochrome. I've taught a class on edX last fall, which will actually run again this fall. So if you want, you can follow it online. It will go online on the 14th of November. And for more information, see our website. Thank you very much. Thank you very much, Stephanie. We still, we have a few 10 minutes left for Q&A. We have 10 minutes for Q&A. So if you would line up at the two microphones, I will call you up. So first question, please. Wait a second. Try again. But we can't hear you on the stream, sorry. Okay. So the first one, the one in the front is not working. So please line up at the second one. It seems that the security of the system depends on being able to only entangle two qubits. Is there some physical property that prevents you from entangling more than two in such a way that would allow a Alice to share the qubit with the dark side? Yeah, so like I've just explained, so like it is in fact physically impossible for three qubits to be equally entangled as two. In fact, if this would be possible, one in fact could send information faster than light, clone qubits, actually do all kinds of things, which are quite magical. And in fact, there is a test, namely this belt test, that will verify, that will only kind of succeed if two qubits are kind of sufficiently entangled that I can rule out the entanglement with the third qubit. So like basically you do this many times, you kind of check on a kind of subset whether they're entangled, meaning that I rule out that a third qubit is equally entangled with that. So this also means that like if the e-stopper, for example, who's in fact allowed to have a quantum computer and arbitrary large quantum memory, in fact allowed to control your entire rest of the universe, has sort of tried to intercept part of this entanglement, one will detect that. In fact, I should, I've talked here about always like the extreme points, like you know, maximal entanglement, no entanglement. From this test one can essentially measure a number, and from this one can make in fact a very quantitative estimate of exactly how entangled this other qubit can be, and how much information the e-stopper can have gained. I have a question, like six qubits, you said actually two questions, but six qubits, is that equal to like six bits of information you can send at one time, or would it be more information? So like at one time, like of course you can send kind of one qubit at each other, like these qubits are actually mostly useful as a memory and a local processor. So like you can of course keep sending more qubits, but it means that you can store six of them at any one time. How fast is it gonna grow in the current future? Cause now you're at six qubits, is it going quickly, or are we kind of stagnated at six? So I mean, there's a question of priorities here, of course kind of in the quantum computing domain, like you want to have more and more qubits, in fact like in for example, superconducting qubits, you can already have 17. So their qubits are actually growing quite fast. So note that the kind of qubits that you want, or the kind of hardware for computation and communication is a little bit different. So for computation you want to do very many gates very quickly, and of course you might also want a large number of qubits, but you also don't need to store them for very long. So if you want to do a communication task, it's less important that you have many qubits, because a lot of these tasks actually need only one. But you also need a system where maybe the gate speeds are not so important, but you want to store for a longer time. Namely, because you might have a protocol that requires Alice and Bob to sort of exchange classical messages, so you need to wait until that message arrived before you can kind of continue. So this is actually why here, the objective is not to kind of go to very many qubits, but rather to increase the storage time. Yeah. Next question, please. Hello. So basically as I understand quantum things, there are some strange type of ways. And when you tell me that the quantum error correction requires multiple qubits, I think multiple waves, and I think a Nyquist probing theorem, that you need more and more resolution than more error correction you do. Isn't this prohibitive if you want to send large packets with error correction? Yeah, so not that actually like here, like one is really only using some extremely small scale error correction. Because the majority of the errors is actually not kind of corrected by errors, but by repetition. So, but let me transfer your question to the computing domain, where actually one wants to kind of use large scale error correcting codes. So there of course, like it is quite challenging to kind of build large scale error correcting codes. To be honest, like from a totally practical perspective, I would actually be less worried about sort of the theoretical existence of large scale error correcting codes, kind of I think they can probably be realized. But again, like here, just like in the communication domain, there's a lot of need in the computing domain for the development of say classical control and algorithms to actually perform that error correction. So one of the reasons in fact why it's difficult to do say large scale error correction is not necessarily just the number of qubits, but it's the fact that you need an error correction algorithm that very quickly decides what to do and kind of which qubits to correct. So this is in fact one of the main challenges, which is not so much quantum, but it's actually classical. Another question. Excellent. Hello, you mentioned that you can use quantum internet in clocks synchronization, how does it work? Because I know that now the constraint is because of the latency and do we reduce latency to zero and we get better synchronization or we have some out of the box other solution. So actually we can talk after that, it's a bit complicated to explain it, but so let me explain something slightly simpler, okay? So let's actually imagine that I want to say measure, say a relative phase shift between two things that happen at the same time. So let's say that like, I don't know, something is turning here or something is turning over there and I wanted to know sort of how much faster is this one as opposed to that one. So in fact, using entanglement, one can in fact accumulate this phase drift into the entangled state and then read it out from there. So this is actually not just used for clocks synchronization, there's also say applications where people use this for sensing. For example, to kind of, there's proposals to use entanglement to detect sort of field changes in the magnetic field on earth, I guess to find things in the ground, which may be a useful application, but this works basically by transferring the phase. So this is quite similar. If you want to know exactly how one uses this synchronized clocks, then that's more complicated but we can talk about that. Excellent, another one, awesome, yeah. How fast can you communicate between the qubits? How fast can we communicate? That is a good question. I should say that currently our goal also for this 2020 demo is not to kind of go as far, like speed is here not the objective. Currently we want to kind of make it possible to communicate long distances and I guess also connect these quantum processors. Like so kind of QKD systems at like short distances can go extremely high, they can do megahertz, but we are not doing that. We are in the regime of Hertz, okay? So we're communicating qubits per second. Okay, but, sorry, my basic understanding was that if you change one of the qubits, the other changes too, how fast? Okay, so let me kind of answer this question. So there's a difference between communication and correlation, okay? So like this happens instantaneously. So if Alice is red, Bob does not need to wait until he also sees red. And if Alice is green, instantaneously Bob will also see green, okay? In fact, it does not matter who measures first. And they will always get the same outcome. So this kind of correlation is instantaneous, which is also why entanglement is very cool for kind of coordination tasks because you have sort of instantaneous coordination. So the question is now kind of why does this, why is this different from communication? In particular, you might ask, you know, why does this not allow me to send information faster than light, okay? So remember that I said that kind of this outcome is random, okay? So like they will either see both red or they will both see green. In fact, this is random. They cannot kind of determine this ahead of time. But this also means that they cannot use this entanglement to communicate, you know, like they get a random bit which is totally correlated, which is very cool, like for making key and kind of synchronizing other kind of tasks. But they cannot kind of use this bit to communicate. If they want to teleport something, maybe you remember my slide, then we needed to send this kind of measurement outcome to the other side. And you can think that in fact, before I do that, the sort of Bob only has an encrypted QB, he does not know how to interpret this until this measurement outcome arrives and he can apply that correction information. So this of course takes time so fast and light is impossible. Great. I said Roger. Good, one quick question and one quick answer, please. Okay, yes. I actually had three quick questions. No. How big is the test environment going to be? Is it for what you can currently do or what you expect to do? Is there still a DDoS problem in networks so that- Is there a problem I didn't hear? A denial of service problem with quantum networks. And why didn't you design the Dutch network to look like the pre-internet version instead of a square, make it a triangle with a point? Yeah, good question. We have constraints. We have people who give us space to put places and we also have fiber from KPN. So we are still a bit constrained. We cannot put it everywhere. Yeah, so, I mean, of course, like we are aiming to sort of, we would like, of course, to have a larger network.  So currently we are trying to make something that kind of works. And, but in order to sort of like make this widespread, you would need some much more industrialized process than what we are doing now. So, I don't know, like some long-term future. Okay, so thank you very much. Once more, please give a big round of applause for Stephanie.


to taking the pain out of support engineering. My name is Ceci Korea, and I'm a software engineer over at Context.io. Mostly what I do when I'm talking about support engineering is I handle support for a publicly available API. So typically my support users are other developers. So that's mostly the frame in which I'm basing this talk around of. But hopefully a lot of the stuff that we'll talk about today is also applicable to other types of support teams. Before we get started talking more about support, I want to start a little bit with a story. Back when I was in college, I got a job working at an amusement park back in Houston, Texas, called Six Flags Astro World. And if you've ever worked for an amusement park, they have a crazy customer service-oriented type of work culture. So one of the biggest things I took away from that job, and honestly, it's been a while. So I don't remember much about the job itself, but I do remember one thing that they taught me that they ingrained in everybody. And that's if you don't know the answer to something, don't just walk away from a customer. Say, I don't know, but I'll find out for you. And that's something that I heard back when I was, I don't know, maybe 19-year-old college student. And that something has stuck with me pretty much throughout every job I've ever had. And I feel like that mindset of you may not know something, but I'm going to go find out for you is at the heart of what makes a good support engineer or a good support engineering team. So what is a support engineer? I've been talking to people throughout the conference and whenever they ask me, what are you doing here? I'm giving a talk on support engineering. Oh, what do you mean by support engineering? A lot of people have different definitions. So for me, a support engineer is a developer or some sort of technical person that's providing technical support to other developers or maybe end users or maybe within your company. So you're providing some sort of support internally to other developers at your company. So it really depends on the size of your company and how you currently handle support. Again, for me, support engineering is supporting other developers that are integrating our public API. But again, it might be different for your company depending on your setup. Why am I passionate about support engineering? Honestly, support has a bit of a bad reputation when you talk about support in tech, but I'm actually really proud to work in support and I really love it and I enjoy it. And I think this is because twice in my career, I've had first jobs where my job was to support other people. How can you have two first jobs? That doesn't sound right. My first job ever out of college, I worked for Electronic Arts, I worked for their customer support division, mostly writing content for the website. And then years later, I decided I wanted to go into programming in my first programming job, where I had some sort of engineer in the title. I was a support engineer for Context Sayo. It's currently also my current job, but I've sort of been promoted since. So twice in my life, I've had sort of like that title as like my first way into an industry. So I'm really fond of support. So let's talk about some support engineering best practices. Today, we're gonna learn how to think critically about problems. We're gonna learn how to prioritize a relationship with your support team. We're gonna learn about continuity. Specifically, this is continuity of your tickets. We're gonna talk about ownership of your tickets. We're gonna talk about boundaries because that's actually something that we don't often talk about when we talk about support. And I think it's really important to make a happy team. And then lastly, we're gonna talk a little bit about some tools that I cannot live without for my support life. So part one, thinking critically. And this is when I'm going to put on my hat of having worked for Electronic Arts for a while. I was assigned the Sims 3. Yes, this was a long time ago. We're at the Sims 4 now. And I was assigned to be the subject matter expert for Sims 3. And this meant that I got to play the game a few weeks early and I played it for maybe about two weeks straight at work and I was going at it from the perspective of let's try to find things are going to confuse end users and let's try to preemptively write content that's going to help end users overcome those issues. So what the studio did right in this perspective is that they gave support early access. It doesn't actually always happen. In the year or so that I worked at EA support, we didn't always get a build of the game that we were supposed to write content for. Sometimes some studios would even give us like a book list and that was super helpful but that wasn't always the case. So a lot of the times we just had to make do with what we were given. And this studio was really nice and that they actually did give us a build of the game for us to test prior to launch. They gave us that time to test before the launch. They gave us plenty of time and that gave us the time that we needed to preemptively generate FAQs. I actually looked today and I saw one of the FAQs that I wrote back during the launch of Sims 3. It's still up there and that's what happens when you give your team the time and the tools to write good content. Good content sticks around. So as you can see, I wrote this about eight years ago and it's still up online. So I'm really proud of that. And this taught me that if you remotely think that something could be an FAQ, it should be an FAQ. And what this whole sort of case study around Sims 3 and giving the support team early access and giving us the time to really go through the game and think critically, that's something that you need for each launch that you have. You need to give your support team the time to look at what it is that they're supporting and put on their thinking hats and start thinking about in terms of is this going to be a question? And that's not something you can really teach, that's something that you can only learn by doing. So giving your team the time that they need to be able to get to that content is really critical. So this was a successful launch again for those reasons. Let's talk about a not so successful one. And this is where I learned that prioritizing our relationship with support is really important. Mass Effect 2, great game. However, we had an issue where people who purchased the game through a pre-order were given a code to get DLC downloadable content once the game was released. For some reason, it was really difficult or it just was a very confusing flow for people to redeem this DLC. So this launch generated a huge amount of calls and emails to our support center from gamers who couldn't figure out how to redeem their DLC code. And this is something that would have been avoidable. So in this perspective, what the studio got wrong is that they didn't give support early access to the game and they didn't give the team that chance to be able to go through your game or go through your product with that sort of thinking cap. And they didn't give the team that time to think critically about what it is that they're supporting. And I feel like had we been given that chance, someone would have said, hey, you know what? This flow is a little confusing. Maybe we should write some content around it. So eventually we did end up writing some content around it and that helped. I actually ended up making a video on how to redeem the DLC, which I thought was silly at the time, but it actually really helped the people on the front lines of support have something that they could point the customer to so that they could perform some self service. Having said that, what the studio got right after this is that after they saw the amount of volume that that question generated to our support center, they were able to say, you know what? We messed up and moving forward, we're going to prioritize a relationship with support so that we can be more preemptive on future launches. So to give them that credit, they did realize this and then after that they did prioritize a relationship with support. And obviously, you know, this has been a while, I no longer work there. So I don't really know how things have gone. I don't think that they've ever had any issues. So let's move on to part two and let's talk about continuity. This is where my fun anecdotes about working in the gaming industry stop and I start going into more about working in the tech industry and doing support specifically for a public API. So continuity, I see two types of paradigms of support and one works I think a little bit better than the other. So let's take a look at both. This assumes that if you are doing support, you have some sort of support queue or ticketing system. What I see typically is a pattern of either dedicated or rotating support. What do I mean by that? Dedicated support is when you, depending on the size of your team, you have one person or a group of people whose sole responsibility is to answer support questions. You can also have a rotating support pattern where one person in your team rotates, whether it's weekly or bi-weekly, and gets to put on that support hat. This is typically what I see in smaller teams where you might not necessarily have the volume to justify one person full-time always doing support. So a lot of the times teams will have some sort of like support rotation where someone trades in the responsibility of answering support questions. Typically, I hear terms like support star or support firefighter for these types of support patterns. Let's talk about dedicated support. You can probably tell that this is a pattern that I like because I think that this works a lot better. Dedicated support works because it allows you to have business continuity for your tickets. This means that it's someone's responsibility to answer those tickets, and that means that it's that person's responsibility to ultimately let the customer know about a resolution. So they take a ticket from initial contact through that solution, and then they close that ticket. And that means that you have continuity. That means that there's one person that knows what the final resolution to a particular issue or bug was. And that is really important because that is what builds your support history. And then you can draw from that. You can find efficiencies based on that knowledge. Also, when you have someone whose sole role is to do support day in and day out, especially if they're in a more of a support engineering type of role, when they start doing one test repeatedly, they'll find efficiencies, and that might mean that they get to write a script or a tool to automate that process. And a lot of the times you don't get to those tools. If you don't have someone whose job is to do those repetitive tasks over and over again until they figure out, hey, there's an efficiency here that we could learn from. This also helps you build relationships with your customers. For me, that's specifically important in my team because I support a product that is an API. So typically the relationship that we have with our customer is really long. They're really gonna integrate with our API. Typically we're talking about years of support. So establishing that relationship with the customer, with the developer that's integrating our API is really critical because we wanna make sure that they feel comfortable asking questions. I often get things like, oh, well, I don't know if this is a bug and I don't know if I should tell you about it. No, absolutely, tell us about it. We wanna hear about it so that we can fix it. And you don't get there unless you have that sort of relationship. Now, when dedicated support stops working, it's when you don't have a way to sort of promote the people in your support engineering team out of support engineering. A lot of the time support engineering is a role that is typically filled with junior developers and that was actually my case. And I think it's a pretty great way to level up junior devs, but you have to have a plan to get them out of support once they grow out of that role. And that is an issue that I see a lot of the times with support engineering positions. You just kinda get stuck in support and you don't really see a way to move out of that position unless it's at another company. And from this perspective, you lose out of all of their relationship building or all of the knowledge that that person had while they were doing that job for you. So I think that having that exit strategy and a clear path to move forward from support engineering for your team is really important so that your team members can avoid burnout. Now let's talk about the other side of the coin and that's rotating support. And why I think it doesn't work. So when you have a support rotation, usually this means that you have a team and maybe your support for the week and you get to meet the front lines, you get to ask questions or answer questions from your clients.  And what ends up happening a lot of the times if you don't have a very clear process for this is that there's not a lot of follow through. So sometimes book fixes or solutions or tickets sort of get lost in the shuffle because once someone is done with their rotation, they just kinda forget about their tickets. A lot of the times this can lead to handoff confusion. A lot of the times teams that have a sort of rotation for support don't have clear processes for handing off the ticket. And this also leads you to a point where there's not a lot of business continuity for a specific ticket.  So that can also be challenging. Also, you lose some efficiencies because each time, depending on how long the period is between rotations, you might forget how to do something. So there's always a period where someone gets back into the rotation and again, it's sort of like their week to be in support. They have to learn how to do support again and that it takes a little bit of ramp up. So there can be some efficiencies lost from that pattern. I do feel like there is a way that you can have this sort of support rotation pattern work and that is if you have very clear guidelines, specifically around issues that are gonna take longer to solve than your rotation duration. So for example, if you get a ticket and you verify it's a bug and you feel like this is gonna be a non-trivial issue to solve and it's definitely gonna take you longer than a week to solve, you need to create a support issue whether it's in JIRA or whatever other ticketing system you use to track features or to track your sprint. And you need to add them to the active sprint. What I typically see when people use this pattern of rotation for support is that they might even get to the let's create a ticket and put it in our backlog but if they don't actually put it in the active sprint that ticket might not get resolved until weeks maybe even months later. And by that point, if you have that ticket open with your end user, whoever responded first is getting graded on that response time. So by not adding that ticket to your active sprint, you can potentially increase that time for a resolution and that can really hurt the support engineer that's providing the support to the end user because then that means that they had a ticket open for weeks or maybe even months. And you really want to try to avoid that. So that's why I think it's really important that if you do get to a point where you see an issue and it's gonna take a long time to solve, go ahead and add it to your active sprint otherwise you might forget it. Also, and this is really big, if it happened on your rotation, you still own it. What I see most of the times with this type of support rotations is that again, I did my week of support, I didn't get this fixed but I'm not gonna support this week so here you go and a lot of the times there's a lot of history that's missed whenever there is a handoff like that between people that are doing on call. And I feel like the best way to avoid any sort of scenario where an issue is lost track of is to make sure that you still own that issue after your on call is over. This increases that ownership of that person to try to get that done. Otherwise it might just fall through the cracks. We're gonna talk a little bit more about ownership in a second. Right now, we're gonna talk about ownership and escalations. There's a couple of ways that I also see people handle ticket ownership and escalations. I call it removed versus owned and these are totally terms that I came up with. They're not established anywhere so if you find them a little confusing let me know and I'm happy to clarify later. Essentially what I mean by this is that a removed escalation is when you work as part of a team and you have to throw an issue over to the other side of the fence and then someone else fixes it and then they let you know hey it's fixed get back to the end user and let them know that it's fixed. So there's sort of like a layer of removal between the person doing the fix and the end user. I feel like this pattern can be really challenging because a lot of the times teams lose a sense of the priority for the issue when you're throwing things over the fence. This also means that when you're throwing an issue over the fence if the other person on the other end doesn't actually have access to the end user it loses a little bit of that impact. When you have a team member that is handling a support escalation and they don't really get to talk to the client I feel like that loss of accountability to the end user adds time to the resolution because typically when you leave people to their own devices and you say hey here's an issue put it over the fence fix it people tend to prioritize supports a lot lower than feature work and again this kind of relates or goes back to the idea that typically as an industry we don't tend to think positively about support we're not really excited about support it's just something we have to do. So that's why when you use this pattern of a removed escalation and you throw something over the fence and the person doing the fix doesn't actually know who it's impacting they're just not really gonna prioritize the work. They're also not being graded on an SLA like the person that's actually responsible for getting back to the end user with a resolution. So when you throw things over the fence and it's someone else's job to actually fix the bug that person is not actually being graded on the time that it took to resolve and the resolution back to the end user that person is being graded on whether or not the bug got fixed. But the person actually getting back to the end user on the support side that person gets graded on how long the whole interaction took. So if it takes this other person a lot longer to fix and they're not really prioritizing the fix it hurts the other person on the support side of things. So this kind of goes back to that idea of like if you don't see that impact just people don't care as much and this is again it's not malicious or anything like that. It's just that it can be really hard for you as a developer to prioritize support if you don't really see the impact of your work. You're more likely to see impact for new features that you're building as opposed to maybe a specific bug or edge case that someone is experiencing. So let's talk about owned escalations and this is the type of escalations that I really like to do. And the way that I see it these are a little bit different when you throw something over the fence in like an owned escalation pattern when you send something over to a fix for another team it is that teams or that person's responsibility to ultimately get back to the client with a resolution. So they are owning the solution they are owning the response back to the customer. And the reason why I think this works much better is because this allows you to have more of that business continuity if in my support ticketing system I can actually say, hey, John, here's this ticket I'm escalating to you. If you have any questions that are gonna help you solve that issue go ahead and ask the end user directly. So this means that there's not so much of the middle man in between and then also the fact that that person gets to talk to the client and ask questions brings the client background and center. So I feel like that helps sort of alleviate that issue of not seeing the impact of the thing that you're trying to solve. This also increases accountability because when you know specifically the person that you're talking to and how the issue is impacting them and their business, I feel like you're much more likely to feel like, oh yeah, this is absolutely something that I really should fix and I should prioritize. So again, it increases accountability. And also when it's your job to actually get back to the end user and let them know, hey, I went ahead and fixed this issue, then you can also start seeing any bottlenecks in the process because if it takes, once you escalate a ticket and if it takes that person or that team a little bit longer to get back to the client, then you can start seeing where some bottlenecks might be happening and then you can start addressing that. For our perspective, even if we don't have a specific fix, we like to at least get back to the end user and let them know, give them a status so that they're informed, hey, this is gonna take a little bit longer than we thought to fix, but just wanted to give you the heads up that we're still working on it. And if it takes, we check in a couple of days or every couple of days just to get people a little bit of an idea if something is gonna take a long time. So that also increases that accountability for someone because if you're having to tell your end user, we're still working on it, we're still working on it, it might sort of like help you or motivate you to get something done. The next thing that I wanna talk about is boundaries. And as I said earlier, this is something that we don't typically talk a lot about when we talk about support, if ever. And I think that this is something really important because if you don't have clear boundaries with how you communicate with your clients, this can actually potentially lead to some serious burnout from people. So let's talk a little bit about boundaries with clients. One of the things that I see, and this is typically something that I see for smaller teams where they can't really have 24-7 support. So if you're working for a large corporation, this might not necessarily apply to you if you need 24-7 support. Typically people have support centers all over the world so that they can get or catch every time zone. But for me working in a mid-sized team, we really can't do that. So in order to be able to get back to people within a reasonable amount of time, we established support hours and we stick to them and we have an automated ticket if someone contacts us after hours to let them know, hey, we are based out of this time zone and we operate during these hours. And if you send us an email outside of those business hours, we did get it but just FYI will reply within this timeframe. And that helps your team know that they don't have to be constantly checking for new tickets and they don't have to be getting back to people at non-business hours. Also, one thing that I've learned sort of the hard way is that you need to allow for a reasonable amount of time between responses. I had an issue where I had a developer who was integrating our API and we typically don't do code review but it was a particularly slow day so the developer sent me some code and he said, hey, I'm getting this error and I decided to look at it and it wasn't even an error with our API, it was a Ruby error so I was helping this person program some Ruby even though that's outside of the scope of what we can really do with support, at least in our perspective. But I still helped him out and I let him know and I sent him on his way and then a few minutes later, he reopens the support ticket and he's like, oh, well, yeah, I'm not getting that error anymore but now I'm getting this other error and again, it was another sort of Ruby programming error, it was an error with his code, it wasn't an error with the API and I decided to help him again and then he reopened another support ticket and now I'm getting this error and again and I was like, I think he's using me as his own personal stack overflow and if I continue to do this, I might write the entire application for him through support tickets and that can be a huge liability for you if you're in this sort of support type of business where you're helping other developers integrate with a product, that's a liability because if the other person, the other end user developer doesn't actually know how the integration works, they're not gonna be able to troubleshoot any issues on their own and also very specifically with code and code samples, I often have to tell developers that specifically ask me, can you please write this bit of code for me? I'm sorry but we can't write your code because if you don't understand how this works then we're liable to you for that little piece of your code base and we simply cannot be liable to all of the developers for their own integrations. Again, it's setting that boundary of we work on this API and we will help you integrate with this API and we will help you with any errors that you encounter while doing your integration but we very firmly cannot help you do the integration on your end or write your own code and I feel like that was a very healthy boundary for us to establish because again it could potentially open us up for issues and allowing a buffer time between responses solved my specific issue of people trying to treat me like I'm their personal stack overflow because when I allowed more time between responses it allowed that person to go and try to figure things out on their own and it actually unblocked them. So now even if I do have the time because it might be a particularly slow day, I try to time box the time when I actually answer questions so that I'm not constantly being someone else's crutch. I think that crutch is a little bit of a harsh term but essentially when people get used to like really good support, it does become a crutch so it's a fine line to balance and I think that going back to a healthy time of response time between different interactions can really help you not be a crutch for the people that you're supporting. Here's a recent interaction I had where I practiced this idea of a little bit more time between interactions and then he came back and he said, you know what, actually I read your docs. I read the freaking manual and it's okay now and this is the type of stuff that I love to see when people are able to say I read your docs it helped me, it unblocked me, yay. Let's talk about good behavior and bad behavior and reinforcing good behavior. This is an actual email that I got fairly recently from a developer. I'm not gonna read everything out, try to redact it a little bit but essentially this guy is really, really angry and you can really tell from the tone and he's saying sorry but this whole thing is messed up. I was trying to test your stupid webhooks and they don't work and this is a really big deal to me because our support tickets don't just go to the support team, they go to the entire engineering team and for our engineers to see this it gets them really riled up, it can be really demoralizing so from that perspective I wanted to put an end to that type of behavior real quick so this was my reply. First of all I tried to pull rank and say hey I'm the lead support engineer here at this team because sometimes that helps people take them out of whatever foul mood they were on sometimes people just wanna talk to someone in charge so I said hey the lead support person here and I just wanna let you know I will get to your question which actually was user error but I said I just want you to know that we have zero tolerance for that type of language and that type of behavior this goes out to the entire team and we will not hesitate to ban any developers if not stick to a modicum of the quorum when talking to us and our team and after this he never talked to us like this again his tickets became way more reasonable he's still working with us he's still working on this API but I needed to shut that behavior down because I knew that if I didn't address it really quickly and sternly it would continue this is where I can't stress enough that your team's sanity and happiness is so worth it and it comes first because when I wrote that message I didn't have to go and ask my product manager if it was okay for me to send that answer they I knew that they would have my back whenever I wrote them that reply so if you are managing your support engineers in any way shape or form you need to empower them and you need to let them know that their happiness ultimately really matters and if you have to step in and talk to someone in this way to let them know that their behavior is not gonna be tolerated your support engineers need to know that you have their back because really if you don't have their back and you don't take their happiness into the equation you're gonna have a bad time if your engineering team is unhappy it's just really gonna affect that morale but also doing support engineering is so rough again you get people that talk to you like that fairly regularly so people can get burnt out doing this so really you want to make sure that you have your teams back and in this case I'm happy to say that my team had my back and I felt empowered to tell that developer to quit that type of behavior Lastly I wanna talk about tools for the job and specifically around documentation typically we talk a lot about documentation documenting our code we talk about tests being documentation and it's all great but we rarely talk about documentation as documenting things like troubleshooting or a thought process or how to do common tasks and when you're doing support engineering this is so critical so I came up with this idea for my team of the support playbook so this is a living, breathing document where we document processes of how to do common tasks and why this is really important is because when you onboard someone else to do support for you you don't have to specifically pair with them 24-7 while they're just getting started you can actually say, hey jump on the ticket in queue if you have any questions consult the support playbook first if you can't find the answer let us know and we'll pair on this with you and this actually allowed us to onboard people on to support a lot quicker because people felt empowered to go and find the answer for a specific issue on their own before having to try to escalate the issue so for these reasons I think that support playbook is really vital for your support team it helps reduce training time and then it also allows you to find efficiencies for automation if you find yourself and your team constantly looking at a specific page on your support playbook wiki on how to do a certain task you know that that's something that could possibly be a good candidate for automation I also think it's really important to empower your team with lots of data so from that perspective I live and breathe by my dashboards specifically we use Datadog and Grafana I specifically like Grafana a lot because they have an open source version that you can sell posts and what this helps me do as a support engineer is when someone has a question like I get a lot of panic developers saying your API is down it's not updated on your status page and then I go and I have the power that this data gives me to be able to tell the developer no it's not down but I do see this issue let's go and figure that out so having that data I can really empower your team logs logs are my friend and I could not live without Scalar Scalar is an amazing log aggregating tool that we use we actually have three different accounts that we sort of switch back and forth I am not paid by these people at all I just wanted to give them a shout out because I could not do my job without this tool that helps me see all of the logs but also it helps set up alerting and that alerting can go to our Slack and that alerting can also open up incidents in our paging system so this is vital to us we also use RunScope for automated API testing again not being paid by them just a really neat product and the way that we use this to monitor our product is that we have RunScope tests running about every five to ten minutes and the results go into the Slack channel and we're able to track response times and whether something is succeeding or failing and this actually allowed us to see as we were working on new features and improving our API it allowed us to see how our response times were actually improving so I highly recommend this tool RunScope also makes an open source tool called Request Bin that is really helpful whenever you're trying to troubleshoot endpoints or specifically webhooks they used to do a tool that they hosted that allowed you to create an ephemeral endpoint unfortunately some people were abusing that but Request Bin is open source and you can self host an instance of Request Bin on Heroku and that's what I do a lot for testing things and also helping other developers test our endpoints so TLDR talked a lot about support engineering and sort of best practices and what it means to me and I feel like a support engineer by definition they're good at troubleshooting they're also good at communicating because they're having to talk to end users or maybe even between teams they're also good at seeing patterns once you start doing something like support engineering every day you'll start seeing patterns emerge that'll help you again gain efficiencies so people that do this day in and day out can be really great at seeing patterns within your own product so I think that a good support engineer is a good engineer and I really believe that support engineering can be a really great way to level up junior developers as long as you're giving them a path to move forward within your organization to other engineering opportunities within your team so having a good culture having a culture that prioritizes support engineering simply means having a good engineering culture period we have any questions about support engineering I'm happy to talk to you after this maybe out in the hall my name is Sessi Korea you can find me on Twitter at Sessi Korea and I'm always happy to talk about support with you thank you