Cool. How many of you said it was your first time here? Okay, I decent amount. I've been here once before. I'm really excited to be back. I think this is really cool that there's a place to come and learn about product management that did not exist when I started in product management. So I think it's a really unique opportunity to have a place to be in New York amongst other people and learn more about this. So I'm excited to talk to you and be here tonight. So thanks for coming out in the cold. And yeah, today I'm going to talk a little bit about decoding product management. That's my pun of the evening. But really the selling point here is working with engineering teams and not being a technical product manager. So tonight I'm going to cover a couple things. Pretty basic. I'm going to talk a little bit more in depth about my background because that's really at the core of this presentation. I'm not a technical person. I don't have a computer science background. And it's something that you're probably interested in learning about my path into product management. I'm also going to break down what product management is because it's kind of a slippery definition depending upon who you ask. And I think it's really important that we kind of get on the same level before we talk about dealing with product managers in engineering capacities. I'm going to demystify tech a little bit and engineering a little bit and talk about some of my past experiences with engineering teams and things that went well, things that didn't go so well and what I've learned at the companies I've been at. And then I'm hoping that I'll give you some actionable strategies. I don't know where you are at in your career today if you're just starting or if you're in product and you're just coming to kind of learn a little bit. But I'm hoping that there's something for everyone in this room to learn a little bit more about. I've been in product for six, seven years in New York City. So I've been around the block in a bunch of different kinds of companies which I'll talk about in a second. So I'm hoping that you can take something away from this and there'll be time to ask questions at the end. I'll just stick around at the end. You can bother me and whatnot. So thanks again. Cool. All right. So me in a nutshell. I am from Chicago. I'm a Chicago Bulls fan. Big question. I am a big deep dish pizza lover, but it is different than New York pizza. It's not comparable. It's a completely different breed of food. So don't ask me that. Yeah. So I hail from the north side of Chicago and I went to school at the University of Wisconsin Madison. So I'm Midwestern or through and through. I studied journalism. I had a really big passion for writing and I was focused on strategic communications. So advertising, marketing, public relations, that kind of breed of work. I think it's really important to note here. My internships during college were not at big tech companies. They were local. I think I worked for the make a wish foundation one summer writing children's stories about when they got donations and got to do their wish, which was really sad and cool at the same time. And I worked at Chicago athlete, which was a magazine covering local athletic stories in the area. So I really didn't have any flashy internships at all. I wanted them. Don't get me wrong, but I didn't have them. And I was staying local and just getting some writing experience. And when I graduated from college, I was just dying to work at an ad agency. I was dreaming of, you know, that mad men kind of life, but like in real day where you get to work on a Super Bowl ad and come up with like a really big sexy campaign. And it's glamorous and, you know, you get to work with like great people and celebrities and you get to write all that stuff. And that's kind of really what I was focused on. I also had a fixation with New York City. I don't know where it came from, but I always knew it was somewhere I wanted to be. And so when I graduated from school, I was like, well, I'm going to take a job that takes me to New York, whatever that may be. So through a connection, I got in touch with a recruiter with a recruiter from the Huffington Post. At the time the Huffington Post was associated with AOL and there was a writing editorial job. I've been doing a lot of writing in college and through my internships. And I'm like, I'm really interested in this. I can move to New York, you know, if I get this job. And she said, this isn't going to pay a lot if you want to move to New York City. We can all laugh at that because New York is insanely expensive. I have this role on the AOL side. It's a production role. And I was like, okay, you know, what does that mean?  I was like, say no more. It's a job. I'll be able to like move in and move to New York right away with a salary. So I took the job as an associate producer at AOL.  But on the AOL homepage, there's a bunch of different editorial sites. And so I was working on one of those editorial sites as a producer under the product manager who was in charge of the site. So we had a handful of engineers and a handful of editors who were producing news content that will go up on the AOL homepage. So pretty straightforward. You can imagine six or seven years ago. It was a little more basic than it is today. It's easier to understand now. But I was kind of just doing, you know, whatever they needed me to do, whether it was kind of explaining things to our engineer, you know, the issue the editor was having with our CMS when they were trying to write a story. I was working with our sales team if they were trying to pitch an advertising package. I was just doing random stuff. And I was just happy to be in New York. And so my manager looked at me one day and he said, you know, you're on track to become a product manager. And I said, okay, like that sounds great. What is that? I have no idea what a product manager is. And so he said, you know, it's what I do and it's really building a product roadmap.  And I was like, that's something that you can do as a product manager. And I was like, okay, I think I can do this. I've been in this role. I've been working with this team. So I was basically the point of that is I stumbled into product management. I came into this producer role because it paid more than an editor role at the Huffington Post and I just wanted to move to New York. So it was completely happenstance. I didn't have any technical background getting into product management. I was at AOL for about two and a half years and Rolling Stone reached out to me. Winter Media, which owned a weekly men's journal and Rolling Stone at the time.  I'm like, oh, this is great. We're trying to go digital. You know, this is like 2013 or something like that. We're trying to like make our websites flashy and like establish a web presence and you're coming from this big tech giant AOL. So you're going to come on our team and help us do that. I was like, great, awesome. So I went over to Rolling Stone where I was working as a product manager on all three sites, mainly focused on kind of helping them build their mobile presence because they had maybe one broken mobile app and they had mobile sites, but they didn't really understand what it meant to build SEO, search engine optimization. Again, they had advertisers chomping at the bit to work with Rolling Stone. It's such a great flashy brand, but all their money is in digital. Money is shifting to digital. What does that mean? Like how do we build these things online? And so I had a little bit of experience with that from AOL. I was helping them kind of establish a marketing and advertising strategy for those websites. I was there for about two years and a dream job came across my desk to work at SoundCloud. I mentioned I was interested in music and this was a music streaming service. I had been in digital publishing and digital news for a very long time and I wanted to like understand what platform development really meant. What does that mean to like build in a mobile app? I have no idea what it takes to get an app into the app store and for you to listen to what I'm working on like I just had no concept. And they had a really interesting role that merged my experience with advertising in college and even throughout AOL and Rolling Stone with product management. And I became a product manager for ad products and monetization in New York City. So I was working on ad formats.  But really understanding like what it meant to build on a mobile platform, what it meant to work with Apple and what it meant to work with Google and submit an app to the app store. I had no idea what that meant. So it was really a great opportunity for media to really understand platform development in a really technical way that I had never learned before in digital publishing. So yeah, I was there and kind of like digging in and I was at SoundCloud. You'll see a pattern here for about two, two and a half years. And then recently this fall I joined Spotify. So I joined as a product manager on the creator team. Very different from the ad side, but again really in line with like my passion for music, passions for artists. The stuff I can't get into too much detail about what I'm working on, but I am working on tools for artists and helping them use Spotify and really make sure they're getting the most out of our platform. We launched Spotify for Artists in early 2006, 2017. Yes. And so we're constantly iterating and giving musicians the right tools so they can maximize what they're doing on the platform. So you can see this common thread of music throughout everything, but you can see also that there wasn't this moment where I said, okay, I need to kind of like understand this tech space, but I'll get into that. So this is really where I became a product manager at AOL and this is me today at Spotify. So I've had the fortune of working at a lot of different kinds of companies with a lot of different engineering teams, both here in New York and remote engineering teams in Europe. So I've had that really great experience of getting to work with lots of different personalities. And yeah, I'm here to kind of share some of those war stories with you. I think it's kind of funny. So why am I here to talk to you about something that I can't do? Normally when people come in and do a talk, it's about something they're really confident in, a subject matter that they know back and forth, and you could argue that I guess for this, but I'm telling you that I don't have technical experience. So why am I here to talk about that? First and foremost, it's something I'm really proud of. I used to be incredibly self-conscious about the fact that I did not know how to code. I felt like I was an imposter in this world. I kind of stumbled into a product manager role at AOL. And I started working with engineers and they started speaking about agile development, which I didn't understand what that was, sprints, what's a scrum master, like all this stuff was brand new to me. I would sit there and write things down and then go Google it after our meetings because it really didn't make any sense to me. So it's something I was recently, I would say in my time at SoundCloud, became really confident in and I'll tell you about that turning point later on. But another big thing is product is growing.  There's a place called the Product School. That didn't exist when I was in product management in New York City six or seven years ago. There was maybe a general assembly or something a little bit more broad, but the fact that there's a place that people can come and learn about product is super exciting. And the pipeline of product managers is sourced from everywhere, and I'll get to that in a little bit later, that product managers are coming from untraditional backgrounds and really finding a place here. And so I think it's important to celebrate that and to highlight that product managers without that technical background. It is the second most question. The second question I get asked the most, the first one is what is a product manager, but the second one is, oh, so you know how to code. You work with engineers. I get asked all the time and someone mentioned, they get asked all the time too. So it's a very relevant topic in this field. But I would say of all these things, most importantly, I wish that someone had told me this and someone had sat up here and told me it's okay if you don't know how to code and you're going to be able to be a successful product manager without those skills. I think it would have really helped open my eyes earlier on, and so I'm hoping I can be someone for you to kind of give you a different perspective, not to say that coding isn't valuable. It certainly is. But it's not the only value you can bring to a team. So I want to highlight that and make sure that you walk away really feeling that because it's something that I had to learn through years and years of product management. So like I said, I want to step back and kind of define what is product management. We can't really talk about the relationship between product and engineering without defining product management.  Any brave souls? Yes. Yeah. Plan and decide the product. Cool. Anyone else? Any brave souls? Yeah. Someone that's a liaison connecting a lot of different departments. Yeah, a liaison, yeah. A person who creates a scope for technical people. Creates the scope. So it's like a planner kind of. So I kind of went from lowbrow to highbrow here. I'm going to read these off but I think it's interesting to kind of look at these you know generic definitions. Wikipedia says the product manager investigates, selects and drives the development of products for an organization in line. Mind the product which is a global product community if you're looking to kind of seek those out. It's the intersection between business technology and user experience. And then on Google's product management homepage they say the architecting the future of our products by bridging engineering and business as you manage a product's full life cycle from strategic planning to development and launch. So not that far off. You know like a lot of these buzzwords but also like so pretty different in terms of like how they're thinking about it. I think it's important to kind of take a further step back to get really meta and say you know why are all these companies and places defining product management so differently? Like why isn't it super clear? Why is it that I still can't explain to my parents what I do? Like it doesn't make a lot of sense. So I really tried to take a step back and think about it. And I think like I kind of said earlier product is still emerging. The product school is amazing but it's new. There's not a lot of places that acknowledge product management as a trade. And so I think because it's so new and because it's transient it's harder to pin down. Engineers have code that they can deliver. Designers have wireframes or high fidelity designs that they can deliver. Product managers don't have that tangible. I say tangible with air quotes because it's all software and it's all in the cloud. But product managers don't have that tangible deliverable that they can necessarily deliver and show in a portfolio per se like an engineer or a designer might. So it's harder to actually show the product of what you're working on. You can say I product managed this product. Oh did you code it? Did you design it? It's like no I you know I scoped it.  It's different everywhere you go. I personally experienced this and we've just seen this in three different perspectives. Different perspectives. It means something different to different companies. I can vouch for the fact that I've done different things and had different responsibilities as a product manager at every company. The perspective and the hierarchy and who reports into who is just different. It's not very clear which is exciting because there's a lot of room for growth but it makes it challenging when you're trying to pin it down. Some other common themes. So I took another step into looking this and doing some research at the big four. The big four there's a lot of text on here. I don't expect you to read this. The big four I talk about our Facebook, Apple, Google and Amazon. Like let's get the most generic product manager description on the table. Not senior, not associate just a basic generic product manager description. And you can see some common themes emerge here. You can see in some of these words that we were just mentioning. Launch, vision, execute, prioritization, business, requirements, competition, priorities. Like there's a lot of those like key buzzwords in there with really action driven verbs like develops and creates and plays really flashy that come in any job description. But a lot of these also talk about the role of engineering and how you have to liaise on with engineers and how you have to communicate with them. But they don't really say oh you need to know how to code. I will caveat there are certain job titles in certain places that are looking for a technical product manager but they will say technical product with a CS degree or knows X, Y and Z language. So it will specify but these are generic from like the top tech companies that don't necessarily say you need to learn how to code. My clicker is broken. There we go. Qualitatively in my experience product managers say you need to know enough to work with engineering. But what does enough really mean? Does anyone have any ideas of what enough could mean? You need to know enough to get by. What would enough be? I think understanding the intersection of the business from how in my case like a music app understanding how the back end talks to the killer, talks to the front end app, talks to the website and other app APIs. I think having an understanding of what's going to work and what's not going to work and knowing the limitations and capabilities of the engineers. That's a really great answer. Better than mine. Yeah. Just to add to that, I think another aspect of it is sometimes with larger products you have different teams working. And it's important you know how one change impacts everything else. The impact. Totally the downstream impacts on other teams and the dependencies. Anyone else? Yeah. Sizing. Yeah. Totally. I like to call that first thing concepts not code. And this is kind of like one of my core principles when I start with the tech team is understanding the tech stack. So the tech stack is the different systems that your engineers are working within. I'll give you an example at SoundCloud. I was working on ads. So we had an ad server that delivered an ad from the server to your phone. So I had to understand the different blocks and the different places down the path that my ad went from server to phone. I didn't have to understand how exactly it got there, but I needed to understand the journey that it went on. I needed to understand the impact and what was going to happen if one of those systems broke down, but I didn't have to understand how to fix it. So it's really about mapping out like those different concepts and not necessarily mapping out the code itself. You have to know enough to ask the right questions and say, well, what's the impact of this? I think one of the best examples is really understanding if you can build a whole feature versus half of a feature and get it out sooner. So whole feature, get it out in a long time, half a feature and get it out sooner. What's the business impact of that? Is that going to improve my bottom line? Is it going to really put my business behind? Really understanding the business impact and the sizing of that is really important. And then you need enough to inform decision making. If you understand how hard or easy something is, you can understand the sequencing of how to order certain things. If we do this work first, it will unlock this in order to launch this sooner. So these three concepts are really important to me when I start thinking about not necessarily knowing the code, but knowing enough to ask those right questions to make informed decisions and give my opinion in a way that engineers will trust. Because at the end of the day, engineers are looking to product managers to prioritize and guide the team. So what do engineers need if they don't need a code? Because sometimes I joke around and say, we just need to speed this up and I could just go and code because this would be quicker, but they don't really need that. Engineers need a business owner. They need someone who can really understand the bigger business goals. So as an engineer, they're working and they're coding in their terminal and they need to understand how what they're doing is going to impact the bigger business as a whole. They need the voice of the consumer. So something that we do at Spotify I can talk about is we do something called sound checks. We'll bring consumers and artists into the office and we'll do that whole testing thing where we watch them use the app and we get to ask questions and see what works and what doesn't work. The engineers don't have time to do that and so me as a product manager, I need to represent the consumer in that experience and be able to go and explain a use case and a pain point to an engineer that this isn't working. I saw the artist trying to use this functionality on Spotify and it's not working. We're going to need to fix that. They don't have time to go do that and so I need to represent and kind of form the context for them around the consumer's voice or the constituent's voice. And I always say a context is king. They need to see the bigger picture and how these different pieces kind of fit together from a downstream perspective. If we don't do this, this won't happen for this team or if we choose to go with this strategy or this architecture plan, these are the implications that are going to happen down the road. They need that bigger picture context and they need that from a product manager because they're not going to be the ones to be doing that. In fact, technical product managers can be a hindrance. A personal story for me, like I said earlier, that really was a turning point was at SoundCloud. So I got to SoundCloud and I was really open when I interviewed for the job. I said, listen, I'm not super technical. My manager, eight-year Google veteran CS degree could get into the code if he needed himself and I'm like, I can't do that. I'm going to be really open and honest with you, but I'm really, really excited about music streaming. I'm really excited about the product and I'm going to do what I need to do, learn what I need in order to do well at this job. So you can imagine I was super intimidated coming into that job. Mind you, his background, me, my background, being a female product manager at that, playing into those stereotypes as well. It was just imposter syndrome to the max. And I always felt that my team, my engineers, they had an issue they would go to him because it was a quicker answer. It was like, well, no, I don't have to explain all these concepts to her. Like I was so self-conscious about that. And at one point my engineering manager said to me, Jory, I need you to really lock down these concepts. I need you to understand, for example, how an ad gets delivered back and forth. I need you to understand the different components that are happening. But then I kind of opened up to him and I was honest and I said, listen, I'm super self-conscious about the fact that I'm never going to be able to give you the kind of technical detail that he can give you. And my engineering manager said to me, he's like, I don't want that. I need a partner, not a prescription. Because if you know too much and you know how to code, you're going to tell me how to do it. And I don't need you to tell me how to do it. I need you to tell me why I should do it. And that really stuck with me because it really gave me the confidence to realize that I don't need to know the ins and outs of exactly how to build this. I need to be able to make those decisions, get the context, form the bigger picture. And he said, if you knew too much, you'd tell me exactly what to do and I wouldn't be able to do my job correctly. And that really just like lit something in me and I was like, I don't need to know how to code. It would be helpful, but I don't need to know how to code. And perhaps my team can be more creative and empowered if I don't know how to code because I'm not in their space. So it was really something that was motivating to me and I thank him every day for kind of giving me that pep talk, but it only happened because I opened up and I was vulnerable about it too. So, okay, I hear you. You're listening to me and you're like, I don't know. It still feels like I need to know how to code. Get introspective. I'm not here to tell you not to code because I think at the end of the day coding is a super valuable skill and it's going to bring you a lot of success. I think you have to ask yourself, do you want to code? Do you want to learn how some of these languages is that important to you? Because if it is, you shouldn't stop yourself. You should explore that. I've known a lot of product managers who are just drawn to that and they go and take classes and they find that they really enjoy that work. And if you enjoy that work, you should do that. But I think the broader goals and the broader strategy is think about your five-year plan. Think about your ten-year plan. Do you want to be a CTO, chief technology officer where you're managing engineers? Do you want to be a general manager or a chief product officer where you're maybe managing designers or other product managers? Look at those types of roles and try to understand what you're trying to achieve because I think at the end of the day, your answer will become very clear. It's something you're excited about and something that you kind of just need to push on, like you're going to go and take some classes and really dive into that. But I'm here to tell you you don't need to and you can bring a lot of value to a team without knowing how to code. Not that you shouldn't know how to code. Okay. So I've convinced you that you don't need to code, but what do you need? So without technical skills, what can you bring to a team? Kind of like we talked about a little bit earlier, that's really valuable. I can't stress enough I'd write it as many times as the line would let me. Communication, communication, communication. If I go all the way back to my background, like in school, writing, email, vocal, whatever types of communication is the key to being a product manager. One of the easiest metaphors I used when I started was I would tell people I'm like an air traffic controller. I stood in the middle and I told people where to go at what time and made sure that no one crashed. I made sure everyone had their, I guess you could say a flight attendant too if we're going with the airplane metaphor, but everyone had their seatbelts on and everyone had like their drinks and their food and everything was like perfectly aligned. And that's kind of what I did. And that takes really strong communication skills, especially if you're working with different types of people. A designer is a very different mind than an engineering mind. And you have to know how to speak to both different types of minds. I've had the fortune at three different companies of working with global teams, getting to travel around the world and work with internationals. And over communication from like a cultural perspective is super important. From a language perspective is super important. I am always erring on the side of over communicating because it's more important that people have everything they need than hiding things from people. It's my work style, but I think it's important, especially working at big tech companies to kind of overshare if you can to the best of your abilities. User experience, like I said, you are the representative for you're the elected representative for the constituent at hand, whether it's a B2B, B2C business, you are the eyes and ears for designers and engineers when it comes to understanding who they're building products for. You're getting, hopefully, getting to do research and talk to some of these people and understand what their goals are, understand what they're trying to do on the platform. They need that because they can't do that and be knee deep in code or knee deep in wireframes. They need to really have someone representative on the team of the people you're trying to build for. And finally, they need business strategy. They don't need someone with an MBA would be nice. I have no intentions of getting an MBA. I think it'd be really great, but I'm sure that everyone who has an MBA here or in the future would benefit from it, but you need just the business strategy. What is the larger context for what you're doing? One of the most motivating things at SoundCloud when we were building an ad product was, well, this is attached to a multi-million dollar deal. And so giving that business context and understanding of, well, we need to get this out June 1st because the movie, for that movie trailer ad that we just sold is coming out then, helps them really rationalize what they're doing and helps them really feel confident in the team. And then you kind of exchange that mutual trust as well. So communication, user experience, business strategy, much more, but those are kind of my three big points when I say you don't need tech, but you definitely need this. So this is where we get to play Choose Your Own Adventure because I have no idea where you guys are coming from. So where to start when I've never worked with engineers before? Has anyone never worked with an engineer before? That was me. I was that at AOL, if you remember. This is a really fun one because people think, oh, you just need to get that first experience working with someone. How do you do that? Check out project management. Project management and product management are very synonymous, but project management is usually a bit more admin focused and a bit more agile process oriented. It's a great way to kind of start somewhere, especially now if product management jobs will say you need some kind of product or engineering experience. Project management is a really great stepping stone to that. I always say hackathons. When I first started in product, I'm also very passionate about fashion, and there was a fashion hackathon in New York City, of course, a couple of years ago, and I was like, great. That's something to put on my resume. And again, as we talked about, product managers don't really have a craft. So I went to this hackathon and found a team of engineers and designers and kind of went with it and had a whole weekend experience. And it was another way for me to really interface and understand what engineers do on a day-to-day basis. That hackathon being on my resume got me an interview at Refinery29 because they're like, oh, so interesting that you're participating in hackathons and working with engineers in that capacity. So I would definitely recommend that as a stepping stone. And then finding a mentor. I can't stress this enough, whether you're mentoring someone or being mentored. It's a great way to kind of understand how people got to where they were offered to take someone out for coffee. Hey, can I have 15 minutes of your time? I'd love to swing by a coffee shop in your office and understand how you got to work with engineers. I'm trying to break into this as well. So it's a really great way to, a low-touch way to kind of engage with people who are in a position that you're trying to get to. Anyone interviewing for a product management role or soon? I've done it a lot, yeah? Okay, cool. Do your research and learn how to talk about your technical experience or lack thereof. I was really open and honest about this when I was interviewing at SoundCloud, which had a really strong engineering culture. I said, I don't have a technical background. And you can take me or lead me as I am. I'm open and excited to learning and kind of getting in that experience, but I'm not going to over promise you that I can code. There's a sense of fake until you make it as well, obviously, like, you know, kind of understanding some of the basic concepts, not the code itself. But it's really important you just kind of own what you don't know, rather than kind of just say, all right, I work with a million engineers, this and that. Be really honest and be really open when you're doing this experience and learn how to talk about the other assets that you bring to the table, and focusing on what you don't bring to the table. Because as we talked about, it doesn't have to be code that you bring to be valuable on a team. Is anyone just starting a new product job and they're working with a brand new team of engineers? That's literally me right now. I'm three months into a new job. Yeah, cool. This was really intimidating. I had been at a music streaming service at SoundCloud for two and a half years and I started at Spotify and I'm just like, oh, bigger company, maybe better engineers. This is so overwhelming. I had a team of like 10 to 15 engineers I'm working with now. Where do I start? And one of the biggest things I didn't do at SoundCloud that I did do at Spotify is understood and pulled someone aside and I said, let's go over the tech stack.  Find your go-to person and really hammer home and learn materials for yourself. Some companies will have that and that's amazing but most companies won't have a packet of, here's everything you could ever need to know about these systems that you're going to be working with. So I can't stress enough, find that person, the gentle soul who will sit down with you and really talk about how everything is lined up. Find a person or find a place to ask questions. Someone recently suggested this to me and it was the best thing I did. Interview your team. So similar to mentors, find time 15, 20 minutes with each new engineer or with each engineer on your team or each person on your team and sit down and ask them, what do you expect from me as a product manager? What are you not getting right now? What are you looking for? What do you need? And kind of help engineers feel supported because at the end of the day, product teams are stronger when they're giving people the right kinds of things that will help them do their work better. So interview your teams and do not try and change things on day one. This goes for any new role. Do not step into a role and say, this is great but we're going to change everything tomorrow. And it's really hard. It was something that I had to bite my tongue on when I started at Spotify. At SoundCloud I was working in a really rigid agile two-week sprints. We estimate every story and we measure our velocity and we have a burn down rate and we know exactly when we're going to deliver and it's good. It's a great exercise and I don't knock it at all. I think it's really important. But I got to Spotify. There was no estimations. This is my team. So Spotify works in a squad by squad team basis and I can talk about that organization as well. But each squad, each team kind of organizes itself and its tools, its agile development in different ways. And so my squad does not use JIRA. It doesn't do estimations. It doesn't do any formal scoping exercises. And then I was like, this is crazy. How do you know what you're going to be able to do? How do you know when you're going to be able to deliver? I was in awe. So I sat down and I was ready down all my recommendations. I'm like, this is not going to work and this isn't going to work. This is crazy. I was ready to send it to my tech lead on the team and I bit my tongue and I'm really happy I did because there's nothing worse than someone coming in on their first day and saying, you got to change all this because something is obviously working for the team. Something's working in the right way. The hardest thing you can do in a new job is sit and watch and not say anything and take notes but really allow yourself the time to do that. It's really important. You'll really gain respect from the team by doing that. I got to say from personal recent experience, that's one of my biggest pieces of advice. And where to start when you need support? Join a product group. Like I said, we're at the product school. This is a great opportunity to connect with people and different organizations or whatever kind of thing but there's a lot of different groups today that really offer product support, really niche product support. I'm in a couple of women and product groups outside of the office, inside of the office. It's really great. There's so many different opportunities. We're in New York City, like Silicon Alley. There's so much here. It's a really exciting time to be here. So find a group and spend some time and really share your war stories. Connect. Go to a networking event. Come to an event like this on a really freezing night in New York City.  In fact, when I was kind of thinking about this presentation and how I was going to organize this, because this question is always looming over as a product manager. Should I be more technical or not? I pulled the women in product slack groups. So there's a global slack group where you can join and get support on a local, global level women and product managers. And I was flooded with responses. I said, hey, you know, is anyone like me without a technical product experience? And it may be a testament to the camaraderie of the group, but I also think it's a testament to how many product managers are in this space without technical experience. So pulled out a couple themes. I know these aren't kind of small, but I, you know, underlined some things. So an editor at the Daily Beast turned product managers. So she was writing and she said, you know, I understand the needs of editors really well. I want to do product management. So you switched over. She said translating high level tech jargon to regular people speak is something that, you know, you really need to be able to understand. An analyst turned PM and ACL. You need to be an excellent communicator. Communication was super key for these two women who I reached out to. I think that this is the strength of non-tech PMs. We can expertly explain the what, but trust our dev team on the how. This is exactly the story that happened to me at SoundCloud. They're going to figure out how to do it, and I'm going to tell them why it's important and provide, you know, all the context and fill in the right gaps. That's from someone who went right into product management, similar to me at Indeed. She's pretty high up over there. Teams need to complement each other. So your weakness and technical abilities needs to be made up with the strength and other PM skills. So other value can bring, such as user research, data analytics. So business oriented, really thinking about the business strategy, marketing strategy, and something, some other kind of value beyond the technical value. This one I love, and I think she phrased this really well. I just own the fact that I don't have a technical background similar to what I did at SoundCloud. Thinking about user experience and being mindful of the universe of things is super important. Be creative, obsessing about and understanding your customers' problems. These are from a consultant turned a product manager at Pillpack and a marketing comms person similar to what I was doing turned PM at Clio. So really focusing on the user experience. Bring that user experience home and really be an advocate for your users, whether you're, you know, working at a legal tech company or, you know, a news company like the Daily Beast. So it was a wide range of experiences and I said, I had to be like, okay, I have a lot of responses already. I had to like put the kibosh on it. But I have to say the biggest blocker when getting into product management and kind of thinking about not having technical experience is you. You're the person who needs to kind of psych yourself up and feel confident going into interviews, going into a new team, walking into a room of engineers to go through a scoping meeting and feeling confident that you can talk and learn and follow along on that conversation. It may take a little bit more work than someone who has a computer science background, but it's not impossible. And it's something that you can really do if you commit to it and get past the back, get past the imposter syndrome that's so obvious to have if you don't have that background. Thanks guys. Do you have any questions? I think I ended right on time. Yeah. You mentioned about your experience at SoundCloud where you're managing all the technical, you know, to bring in that aspect.  You still get that resistance. How did you get over that? For me, it's really about building those one-on-one personal relationships with people. And that's something that I feel like is one of my strengths. I have a communication background. I'm a people person. And so for me, like, I can't walk into a room and just start speaking tech. But I can ask you if you want to go to coffee and reason with you and say, listen, this isn't one of my strengths. Would you be interested in spending a half hour with me once a week going through this to make sure I understand it correctly or just pinging someone on Slack? Hey, I know we just finished that meeting. I wrote up my notes. Does this make sense? And kind of validating on a one-on-one level because if you think about it as a big block of people, it's very intimidating. But if you reason and just think about how you build friendships or relationships, going one-on-one is a much more approachable way to do it. Yeah. Yeah. Yeah. So agile development is just a way and like a framework methodology really of doing software development. So the most basic example is like every two weeks we sit down and we decide what we're going to do and we size that work and we say what we're going to deliver. And then at the end, we see if we said yes or no, we delivered it or not. And we grade ourselves basically on that. In its most basic foundational capacity, like you've done that work. You have planned work. You have said, you've sat down with the team and said we're going to do this, X, Y, and Z. And we've committed to this. And then at the end, we said we did it and we didn't do it. So if you really break down agile, I know agile is like such a buzz word, but like if you break down the foundation and the framework of what it really is, it's committing to something and completing it. And I think for the most part, all of us have done that in some capacity, whether it's in like school or whether it's in a job. And I think it's okay to be open about, no, I haven't done this two-week sprint thing, but I've read a lot about it and I've learned how to commit to things and how to report on that. And I want to learn more about it.  But I think at its core, you've done that kind of work already. I think you have. I don't know you, but I think you have. Yeah. Yeah. Like the tribe mission. It's actually very similar. So I'll explain that. The first thing I would say, we don't really have a dedicated agile coach. We have a mission level agile. So let me answer the second question. So at Spotify, we have a research and development organization. It's split up into missions. So each mission has like a purpose. My mission is the creator mission. Within each mission, it sounds, the verbiage is so funny. Within each mission, there's tribes. So a tribe can be like 100, 150 people. Within a tribe, there are product areas or squads. So each squad has a trio of people, a product designer, engineer, as it's like trio and each at the squad level, at the tribe level, at the mission level, there's a trio that's responsible for delivering stuff. And so for me, because there was no, there's an agile coach at the mission level. So I didn't really interface with the agile coach. Although I did meet with the agile coach when I first started, just to get like a lay of the land, which I, if the company has that, I would definitely do that. So I went to my attack lead because he was the most, he was the closest person to the work and the closest person to our team's rituals and could give me the why we did this and why we decided to do things like that and how it got to be because a lot of times you need the historical context and then you're like, oh, that's why we don't use JIRA or that's why we do things on Wednesdays. You know, there's always a reason. So I think also getting the context rather than just throwing things over the wall, suggestions over the wall is really important too. Sorry, what was the second part? I don't know. I mean, yeah, my, it's like a couple hundred people for our mission, I would say. Yeah, it varies though. Still no three months in. So don't quote me. But yeah, that structure is copied at a lot of different companies too. It's a really interesting structure that gives you autonomy as a product owner to make decisions and move quickly. So you don't have to like wait for your manager to approve things. You can kind of just go, which is really great and exciting environment to work in. Yeah. I'm curious if you have any tips for finding companies that are open to non-technical teams. And you know, as I've sort of thought about bringing the product management, I want to find a company, you know, like Spotify or Google that has good training in place. But there's also like the concern that, you know, those rep people with great big tech companies may not want, may not be as open to people trying to break in. Yeah. So please, I'd love if you taught me where a good break-in entry point is. That's a really good question. I think, like I said earlier, I think project management is a really great way to, a great stepping stone. I also think it's a great career path. I don't want to say that it's like an entry level position to product because it's not, it's certainly its own thing. But I think you can learn a lot about product by being in a project management role, which is really cool. I think when you're interviewing, you know, I think it's important to ask those questions and be honest about your experience and say, you know, I don't have a technical experience. What is the training like here? What is, you know, the capacity for you to mentor me and really teach me some of these things if I don't have that experience? My time at Rolling Stone, I would say was probably like the most equivalent of them not really understanding what a product manager was. So I was one of two product managers on like a digital team of like 50 people and they didn't really understand it. And so it was really hard, but it was also kind of fun because I got to learn on the job and make it what it was on my own. So that's another way to do it, like a company that's not super technical that's trying to understand digital is an interesting way to get in there as well. But if you're really trying to learn product, I would try and stick, I guess, with the tech company and be open to different kinds of roles. I would say that so many product managers at SoundCloud and at Spotify transition from other roles into product management. So don't close yourself off to a product marketing role or a customer support role. I'm trying to think of other teams, but we had so many people just shift over into product management. It's always easier to transition, especially if they need that technical experience. Sorry, not technical. If they need that product experience to kind of come in as a transfer rather than like a new hire. So that's another way. If you're open to starting with something else and then saying, you know, I'm interested in this path, is there an opportunity for that in this company? Yeah. I have a good question. Yeah. Why can that be said with sound checks? So what are the best practices for user interviews and user video testing? And how do you make sure that the sample size of the customers that they are interfacing with is enough? Because I, as a product manager, you know, it's 50 enough, it's 30 enough, it's 100 enough. Yeah. Yeah. I mean, it really depends. So I can't talk too much about the product I'm working on now, but it's something we're experimenting with. So it's a really small group because it's not very big. I think depending upon the scale and the size of your actual user base, you can base it on that. It also depends like at the stage if you're exploring versus if you're just doing like play and usability testing. I'm trying to think like my time at AOL, we were testing like an AOL TV mobile concept like would people use their phone as a second screen and like play games while watching TV. It was one of like the best user research experiences I've ever had. We spent months designing something. We get in the room, we get behind the wall, they can't see it.  Like we hate this app. This is crazy. And I was like, oh my God, we've been spending months on this. But I think, I don't know.  We really, we work with research teams to kind of help form those groups. I've been really fortunate at AOL and then it Spotify to work with a UX research team, UX researcher to kind of organize all that stuff. There is a tool that I used at Rolling Stone that we did AB testing on. I would always say if you don't have that support of a research team, there's many different companies. The name of it is slipping me right now, but you can kind of do on the fly AB testing that's a little bit more scalable if you have a major user base. So it really just depends if you're in exploratory mode, if you're in usability mode, AB testing is a really quick scalable way to get results, sound checks and in-person interviews. If you're doing exploratory or if you want more qualitative feedback. Yeah. When you create scopes, how do you know like when to stop creating your scope? Because that's like a problem that I have. Like I'll start something. I'll be like, here we go. Here's this idea. This is what I need to do. And then I'll be like, okay, this is what I need to do. Each of those things. And the next thing, you know, I have like this massive tree. Right. Every single last detail. And I'm just like, well, why didn't I just do it then? So like, where do you stop with your scopes? It's a really big question. So are you familiar with like the concept of MVP minimal viable product? A lot of times. And I can really relate to this because when you're building a product, you kind of want all the bells and whistles. You want everything to be perfect. And, you know, you want it to be the best product that it can be. But many times you don't really need all the bells and whistles. I meant like on how something works. Okay. If you were to go like, how does this laptop work? One simple thing is like, it's clamshell thing. There's a screen here and there's keyboard there. But then what if I started to dissect things like, like writing product requirements. So that really just, yeah, I understand what you're saying. So that really depends on the team. So I used to do things called PDRs, like writing product requirements, like literal books of requirements on like writing this button clicks like this. It turns blue on hover. It turns gray. And I'm like, this is crazy. But some teams, depending upon if you're working in a waterfall environment need that because in many cases, engineers are out of house. You're working with an agency and they kind of need everything there. So in cases where you're working with remote or out of house engineering teams, I would say, err on the side of more detail. If you're working with in-house teams and you're collaborating on a daily basis, or if you're working with a great designer who can do prototypes and save you the trouble of writing out product requirements, less scope is usually easier. So for me, it really depends on the team that you have. So if you have people here, you can show, ask them, what do you need for me in order to build this? I think that's kind of your best starting point, rather than trying to guess and drive yourself crazy because I've done that too. I'm like, how detailed do I need to describe? How thin is this line? How, you know, like stuff like that is insane. From the design side, a lot of the wireframe software, like Sketch, or no durability experience, like you don't have, like, the hover animation things. Like, how do you usually annotate those things if you do want to put them? Like do you usually put some sort of caption or just... Yeah, I would usually caption it. I don't do a lot of wireframing anymore because I work with a designer who does just high fidelity, like she'll do straight high fidelity designs. But if you're doing that, like captioning is usually fine. I would say if you're working with any kind of designer, just, or engineer, say what is the easiest way for you to go because at the end of the day, they're the one who's going to be reading it. They're going to be the one who's really having to figure out what you're saying. So make it about what they need.


So you've got your TEFL certificate. Now what? How do you go about looking for a job as an English teacher abroad? TEFL TESOL Recruiters Using a recruiter can be a great way to find a TEFL job, especially if you are applying from your home country. Some recruiters will help with the necessary paperwork involved in applying for the correct visa for your destination country and some may even arrange orientation sessions before your job starts. Recruiters are paid by the schools to find teachers and should not charge teachers for finding positions. Depositives Great way for new teachers to find legitimate jobs. Recruiters can offer visa assistance. Provide relevant information about destination countries. Take some of the stress out of moving to a new country. The negatives. Avoid companies that charge the teacher for their services. Research the company thoroughly before committing. Remember that they work for the schools, not for the teachers. Online job adverts. There is a large number of websites advertising TEFL jobs all over the world, and this is a good way to find jobs yourself while you are still in your home country. Many sites allow you to search by country showing you what is available and your chosen destination. Even if you don't apply to any of the adverts, there are good ways for you to suss out typical salaries, benefits, and so on of local job markets. Depositives There are thousands of positions around the world advertised online. You're free to choose where you work. You can judge the job market and the country you're interested in. Negatives Online ads attract a lot of applicants. Schools tend to prefer hiring teachers already in the country. Watch out for scams. If it sounds too good to be true, it probably is. Applying in person Applying to schools in person is often the best way to secure an English teaching job. Most employers prefer to hire someone who is already in the country. Due to the transient nature of EFL teachers, job openings arise frequently and employers often rely on word-of-mouth and personal contacts, rather than posting a new advert every time they need a new teacher. Depositives Many employers prefer hiring teachers who are already in the country. An employer is far more likely to read a CV on their desk than in their inbox. It's an excellent chance to make a great first impression. The negatives It can be expensive. You'll need to support yourself while job hunting. You'll need to arrange visas, accommodation, and transport yourself. Speculative email This enables you to access EFL jobs that may not be advertised and ensure that your details are already with employers when openings do arrive. All you need to do is write a cover email for the area in which you want to work. Search on Google for schools in that area. Collect all the relevant email addresses in one word document. Create a new email and address it to yourself. Add the email addresses you have collected to the BCC field. Attach your CV. Send the email and wait for responses. The positives Send your details to a large number of potential employers in one email. Access jobs that aren't advertised online or elsewhere. The negatives Adding the email addresses to the CC field instead of BCC will show everyone your writing to more than one school. So where to start looking? The biggest demand is in Asia with 400 million learners in China alone. The highest salaries are in the Middle East with 5,000 US dollars per month on average. The lowest cost of living can be found in Latin America with only 400 US dollars monthly.


Open air is about opening up science to new possibilities. We need to make science more social, more relevant, and more dynamic. As scientists, we often wonder, is my idea really new? We already have indexing tools and text mining is coming, so why not using intelligent semantics to make search engines understand what we're looking for and show us whether it has been done before? We also need to see how ideas evolve. Citations already link publications to each other, but we need to show it in meaningful ways and find the papers that really matter. We should weigh the influence of scientific works on the publications that cite them. But before that, papers need to be reviewed and that is generally a waste of resources for our scientists and reviewers. Opening up manuscripts to public peer review should reduce workload for all and allow for transparency where we really need it. Science is dynamic, it changes all the time. Accordingly, just like folks can go through different editions, scientific papers should have version numbers. Currently, papers stay fixed in time from the moment they're published, but there is always something to improve upon. Still, papers are one thing and data is another thing. So, we should keep track of data as well. We can already share it on open platforms and be rewarded when someone else uses it. So, data use counts should be a measure for the output of a researcher. Then again, we scientists often cling to our own data. But maybe sharing is worthwhile. It takes us further with collaborations and it makes us work faster and better and we become more responsible too. So, let's face it.


Okay, so I know you guys want to do chemistry and alkenes all night, but I have some desiccate. So this will be the last problem that we do. Very similar to the other ones. How do you make this compound this chlorohydrate from an alkene? So cyclohexene is the only alkene that would be able to be used to synthesize this. Of course. So you're going to have to add the hydroxyl substituent and the chlorine on there. So how would you do this? If you recall, Cl2H2O. So we can do the mechanism too. So Cl2, it looks like that. When it gets into the presence of an alkene, it's going to make this have an instantaneous dipole. So this chlorine will be partially positive, that one will be partially negative, and that will induce that alkene to attack it. Once that happens, these two steps happen at the same time. So all of those really happen at the same time. Concerted reaction. So what are we going to get? We're going to get the chloromium ion. We're also going to get Cl minus, so the chloride ion. And remember, this is in a solvent of water. So there's a ton of water. There's a lot of it relative to the little bit amount of Cl that's in there. So water is going to see this three-membered ring. And remember, three-membered rings are very unstable already. Chlorine being very big and bulky doesn't mind having, you know, is very big and bulky. And these carbons don't like having that strain on that ring. So this is going to see the opening, right, and come in and attack, knocking that bond out like that. So we're going to get the protonated water there, or the protonated alcohol hydroxyl group from water attacking. And then remember, of course, we've got a lot of other water molecules out there. So that's going to give you your final product, H3O plus, which you will wash out. So that's it for the night.


Dear students, in this module we'll move towards the last step in the homology modeling pipeline. So now we will talk about the model validation. Till this point we have constructed a structure for the protein by using the protein sequence and the protein structures from the PDB. We have created its backbone, we have inserted the rotomers, we have also put the gaps and replaced them with loops and coils. Moreover, once we have done that we have then optimized the structure by putting it in MD simulation and then we have selected the structure with the minimum energy. Now having done all of that we have still one problem. That is we have to check each and every torsion angle using the Ramachandran plot of course as well as bond lengths, the bumps in the structure. So there may be some exceptional protrusions from the structure that should not be there and this is what forms the crux of the model validation. So let's start. So as I just mentioned we now have a protein structure that we have predicted and that it has the minimum energy and therefore is very stable. This was obtained by using molecular dynamic simulation. After we have predicted the structure we need to evaluate the structure for bumps, bond angles, torsion angles, lengths of the bonds that are there and several other properties such as distribution of polar and apolar residues. So for instance if you have a protein like this so this does not have a obvious bump however if you have a prediction such that you have helices and then there is a portion in the protein that is protruding out of the main structure so you want to reevaluate this structure. Also the bond angles in the backbone should follow the Ramachandran plot. So this is called the Ramachandran analysis and it is an integral part of the protein structure prediction problems. Similarly in the next step you have to see the angles of the rotomers and see if these angles are valid. So all of these angles need to be within a certain range for each amino acid. So remember that each amino acid has a certain preference for the torsion angle that is the angle with the side chain. Next you have to really see what are the bond lengths. So if the structure that you have predicted has these bond lengths that are very long or very short then you would want to adjust the structure such that the bond lengths they stay in the tolerable range. For instance hydrogen bond should have a length of about 2 to 3 angstroms. The other covalent bonds should be according to the atoms involved. And lastly other properties such as the distribution of polar and non-polar residues should be normal. So in the structure if you have a polar or a charged residue inside the protein structure then your structure can have an unstable core and therefore may be an incorrect prediction. So the important points to remember is that we can tolerate the errors, slight errors but such errors should not be in the active sites of the protein. So the active site is that site of the protein that is responsible for the function of that protein. So the hydrophobic core may have slight variations but the active site of the protein must not have a lot of variation. So now that we have performed the entire 7 steps of homology modeling we must also critically analyze what are the shortcomings of such an exercise. Because the homology modeling is based on the template structure so it means that anything that you predict by using the template structure is only limited to the structural design of the template and therefore there is a large bias towards the protein structure. Also if there are conformational changes in the protein whose structure is unknown that is the target then because you are using the template you cannot predict those conformational changes and therefore you can miss those conformational changes. And lastly the homology modeling pipeline cannot help you to discover newer sites for binding of drugs and other such novel behavior. The fundamental reason for that is because you are using the knowledge that you have from the structure of the known protein and therefore you are limiting yourself to the structural prediction for such a protein only. Now how do we overcome these limitations that are set in place because we are using a template structure. So there are two other ways for homology for the prediction of the protein structures as well. So one of them is called threading and the second one is ab initio modeling. We will look at these approaches later but the point here is what to do if homology modeling fails and therefore you also have other methods to predict the protein structure instead of homology modeling. So we will examine the online tools that are available for each one of these strategies later as well.


We're recording in progress. Going to turn this. Did you mute? Okay, so we have. So it's mine. I thought it's smooth. So the first speaker is a plea from ETH and the search for flatbends and pack of metals. Right. Okay, so it's a, it's a big pleasure to be here and I want to thank the organizers again for having this marvelous meeting. That seems to have started many, many years ago, and the topics seem to have moved on to, you know, starting I guess with heavy odds of ITC and now, now this time is dedicated more to top logical effects. And I am going to talk about essentially a search for a key ingredient of interesting topological effects in real, real material. Let me just, let's just see how this works. Why is this not advancing? Oh, there we are. Okay. It's funny that it doesn't. Let me just acknowledge that my collaborators in advance is always important, especially if you run out at the end. So I've highlighted here at the beginning of the list, the junior people, the postdocs who've really done most of the work on making this happen at the variety of institutions, both in Switzerland, including, of course, ETH and EPFL, but also University of Geneva. And the work that I'll describe is, is covered in these two preprints and there'll be another one shortly dealing with the end of the talk if I manage to get there. So just by way of outline, I'm just going to tell you probably something you already know, just sort of briefly reintroduce the Kagame lattice and what can happen on the Kagame lattice with electrons and spins and why is it so interesting for the correlated electron community. I'll then just briefly touch on what's being done with real materials, insulators and metals in the search for flat bands. And then I'll talk about the material, which is the main topic of my lecture today, and then deal with electronic structure and magnetic excitations thereafter. Okay, so frustration, you all know, triangles are interesting because you can, if you have a third spin, I'll say in the Ising model, all coupled equally to each other. That one is frustrated, doesn't quite know what to do if you set the other two spins in a particular orientations. And of course, these, this gives rise to, you know, sort of non-trivial geometric frustration on bigger lattices of triangles. So the triangles are the basic motif. And of course, you can decorate these triangles with spins. And actually, the other thing that you can do with the triangular lattice is you can thin it down. You can dilute it. And one thing actually that I'm sure you all know is that if you just remove, let's say, if you remove one third of the spins to make a hexagonal lattice, actually, you're no longer frustrated. You can generate, you can create a lattice where all spins actually are happy. So playing around with the triangular lattice and its derivatives is interesting. So in the case of going from the triangular lattice to the hexagonal lattice, the dilution actually helps relieve the frustration. And, but there are other, and so this is, of course, a simplest case of a vacancy lattice derived from the triangular lattice. You can, of course, also have more interesting vacancy lattice. He's then simply hexagonal, which we know so well from graphene these days. You can have a two by two vacancy lattice. And this actually gives rise to the Kagome lattice. That actually maintains some of the triangle. So there's frustration that is actually continues to exist. And this fitting out exercise in this case, you know, leaves you essentially with, with a problem for the simple ising model. But actually, you can relieve the frustration, of course, to some degree, if you, if you have a continuous spin degrees of freedom on any of these lattices. But what happens with the Kagome is, is, is, is especially interesting with this vacancy lattice. You have this opportunity here to create, let's say, some ordered structure, be it anti ferromagnetic or ferromagnetic where you actually maintain local degrees of freedom, which can fluctuate at no cost to their environment. Okay, so, so what this effectively means is that in real space, you have these, these localized degrees of freedom, which, which essentially can rotate in the presence of everything else without any cost. And that of course leads to these famous flat modes that are the topic of this particular, particular talk and I think also suspect the topic of many other talks at this meeting. Just, if you want to read about this, this is of course a very old story, something that probably Chandra and I wrote, you know, 25 years ago. So moving into case space, how does this happen? So if I look at the ferromagnetic spin waves on the honeycomb lattice, of course, those are have a very close relationship to the electrons in graphene. You have this famous dispersion relation with these touching points. These are going to type these Dirac nodes at the, at the K points of the, of the, of the honeycomb lattice. So there's this, of course, is has been much discussed and has interesting course implications also, you know, when you think about edge states and everything else, whether it spins or electrons. If you, so there's two modes here, essentially that touch. Now, if you, if you go to this is the root three by root three, super lattice of the, of the ordinary triangle lattice. Now, if you go to the Kagamine, there's actually an extra mode that gets added in case space that corresponds is flat in case space corresponding to these localized degrees of freedom that I mentioned to you a few minutes ago. And so you still get actually inherit essentially these Dirac, these, these, the, the, the inherit the hexagonal modes, including the Dirac points, which are marked by the green arrows. You inherit those, but you add, in addition to those Dirac modes, you also add a flat mode on top. And these are just spin wave calculations, but as you know, these are completely essentially just related by a simple square root to what you see for electrons. And this topic of what might happen in such lattices when you add correlations really came up in a serious way a little bit more than the decade ago in the paper from the group of Jarvan Wen at MIT. And they, they started to try to tune these dispersion surfaces that I just showed you using first and second neighbor poppings. And they also added spin orbit coupling to make the physics a bit more interesting. And they also added ferromagnetism. But basically with this tuning, well, these modes here up here, you see the ordinary Dirac type modes, or if you wish, the graphene type modes, but they of course acquire gaps, which, which are, which basically become a function or a function of these these additional parameters that are thrown in. There's also down here, there's this, this originally flat mode, whose curvature and distance from these others is can be essentially fixed by these first and next year's neighbor parameters that I just illustrated in the last slide. And what we have here really is a metallic ferromagnet with a spin orbit interaction. And it's of course interesting at that time was thought to be interesting because maybe this could be a residency for high temperature fractional quantum pulse states in zero field. And so long story short, here's a particular tuning that they use, they got sort of they introduced flat bands in this simple lattice, Kagame lattice for the U. So these are potential hosts for exotic quantum pulse states. And in some sense, this is not in some sense in every sense is the motivation for this kind of work is exactly the same as a motivation for all these wonderful studies of twisted violet graphene that you've heard about for the last five, six years, especially from the MIT and Columbia groups. So what about experiments to actually see these flat modes actually to spectroscopically make sure that they're really there and that all of this theory based on very simple models is somehow relevant for actual physical measurements. It turns out actually that it's rather more difficult there. I mean, on the insulator side, essentially for the simple ferromagnetic Kagame systems, the best data are available for this horrible organometallic thing that copper does have ideal this copper VDC I can't pronounce that benzene dicharboxylate that I just did. Those are the things that essentially are stuck between these layers. You see the benzene rings there. And then there are these Kagame layers which are actually quite perfect for copper. Now the unfortunate thing with this is that it's not possible to get really large crystals. And so all of the data that we have on this system, the dynamics of looking or looking in detail at the flat modes is on powders. Now that's an insulating realization. That can just look at the magnetism. There's of course metallic realizations. And the most popular one with the sort of people doing experiments has been this iron iron 3-10-2. It's misspelled there. And what this is is Kagame bilayers with interspersed with Kagame bilayers of iron and 10 interspersed with simple 10 triangular layers and then another Kagame bilayer on top and so on and so forth that gets repeated. So this is a proposed metallic realization of this material. It's actually not quite as simple as that in the sense that the Kagame layers, these bilayers actually are actually distorted and they're distorted in such a way so that actually you lack inversion symmetry in the points of inversion symmetry even in the plane. And the other drawback of this stuff is that the crystals are rather small, but you can get reasonably good things in the sort of fractional, a fraction of a millimetre range. This stuff has been studied for a very long time. Actually it's been studied in the last 50 years. It's curious, it has a very high paramagnetic transition temperature. It's not 630K. So it's a very strongly coupled sort of stoner type system one thinks it has a curiosity that attracted most of the attention, which is it has a spin orientation transition sort of at around the 120 Kelvin where the moments go from fine essentially perpendicular to the plane to in the plane. And it turns out that there's a recently we will establish there's a nice critical endpoint associated with that transition. This is not the topic of this talk, it's really thinking about the dynamics trying to see if we can see the flat modes that are needed to get all this interesting many body physics. So what about the electron? So we actually have performed many, many of the people from Oleg Yazev's team in our collaboration have gone and calculated using DFT, all kinds of parameters. I'll get to some of those later. And what you see is actually is a band structure like this. It looks like any other band structure of a complicated material. There's actually in this, any DFT calculation that you look at bears no resemblance at all to the simple dispersions that I showed you at the beginning, even the dispersions that when he expanded the range to be to second year's neighbors. So it's a fully three-dimensional metal. So that's a little bit sad. It's got an absolutely baroque Fermi surface. So again, nothing at all like what you were told to believe. And and then people, of course, did photo mission. And what I'm trying to convey to you here is that actually the photo mission is doesn't actually show very much of that spaghetti. The photo mission also has a drawback, especially as photo mission is usually performed, is that not only do you see the spaghetti from the bulk, but you also see all kinds of fill from the surface states, particularly at the energies where people like to do photo mission, which is, you know, near, you know, between 50 and 100 EV. And so there's some ghost-like features. And a lot of time was spent in the early days, meaning a few years ago on looking near the K points. Of course, these are the same K points that were inherited from the hexagonal lattice and triangular lattice. And there's this feeling that, well, there are probably Dirac points there. Now, what the calculations actually do show is that those so-called Dirac cones are first of all, they're not predicted by DFT for the bulk, but they're actually derived from the superposition of surface and bulk states. And so that's sort of the, you know, that's happy to engage in more discussion about that, but that's basically no Dirac points here. The other thing is there's no, nobody can see any flat bands there either. New discovery, which there'll be, I think, a talk later in the meeting about is that, although there are no Dirac points, there are tons and tons of well-knowns, which are very close to the Fermi surface. So the other thing, a thing to say is experimentally, you know, there are these, although there are these features which have fooled people for a long time, there's no sign of well-resolved quasi-particles near the Fermi surface and no sign of resolved flat bands anywhere, but there are curious features in the 3D band structure which ARPES does see. And they're seeing it actually in a very ghost-like way. So what I'm showing you here is essentially a photo mission. You of course all know that with photo mission you only conserve momentum in the plane, but of course you could always fix the momentum along the Z direction for the initial state by looking at the energy, the outgoing electron energy. So you have a way actually to perform KZ scans by varying the energy KZ where Z is perpendicular to the surface, perpendicular to the basal planes of this material. You scan the photon energy into the soft X-ray regime. So this is now hundreds of EV. And so what I'm showing you out left is a section of the Fermi surface actually in the KYKZ plane. And what you see is that there are actually curvatures, there are band curvatures there. There's also what's noticeable is that if you look in detail and there's some optimism near the gamma and Z points, is there looks like to be some essentially zone center Fermi surface which is actually fully modulated along Z. And you can make this out in this cut along this dash, vertical dash line. You can see here that there are alternating sort of dark and bright regions exactly at the Fermi surface basically centered on the gamma and Z points. So that was just a very, very small hint. This is hardly definitive, but it said that perhaps to look for, we should try to finally see if we can actually image directly real quasi-particles near the Fermi surface by going into a different regime with the instrumentation that's available for our pitch. And what we decided to do to try to see a little bit more in detail, particularly what goes on near the gamma points, is we went to do laser arpes with a very low initial photon energy, just 6EV. And of course what that 6EV means is that your typical kinetic energy for the electrons, you have to subtract the work function with the electrons from the photon energy is going to be measured in single digit EV. And the great thing about that is that these low energy, the very low energies, the electron mean-free path becomes much longer. It's basically a border of 100 instruments or beyond. In contrast to what that mean-free path was in this regime where I showed you the photomission data, again which misled people about these so-called direct cones. And so we're now dealing with the mean-free path for the electrons exiting the sample, a good more than ordered magnitude longer than we were dealing with in this typical soft sort of UV range that people work in. The other thing that actually the laser brings, it brings a much smaller spot size than you get out of the normal cyclotron source. But these two facts are very important. So the first thing, the three things that you get, one thing is you get much more bulk sensitivity so you don't have to spend all your time trying to sort surface from bulk. The other thing that gives you specificity to particular locations in the sample. And of course last but not least, it gives you much better energy resolution so you really can start to look at quasi-particle lifetimes and mean-free paths. So at the same time, of course, one needs to do some DFT to try to understand those pockets. DFT does in fact give these pockets, DFT for the full three-dimensional material. These pockets don't exist in any kind of simple model calculation for the bilayers or the monolayers. And the most important thing I know this, unfortunately this screen is much smaller than I thought it would be. The key point that we want to look at is here near the gamma point. And what you'll notice is there are indeed electron pockets for the electron-like Fermi surfaces centered on the gamma point in a very small range of q-space and a small range of energy transfers which is actually perfectly matched to the 16e incident of energy we are using for this particular photo-vision experiment. Now the other interesting thing that the calculation, of course, reflects is the fact that there is no, that there is actually a missing inversion symmetry in the plane for these real materials. Again, if you squint at this, and again I'll show you a little bit more data later in a minute, is depending, in fact, on how you, depending on essentially the orientation, let's say, of your experiment relative to the crystal, you'll find that actually these Fermi surfaces are not inversion symmetric going to the gamma point. Okay, so that's, and the last but not least is what goes on near the gamma point is very, very sensitive to you in the DFT plus you calculations which were performed here. And so if somehow you can get your hands on these gamma points in a clean way, you can actually decide, determine what you might be. This band minimum really moves very quite strongly in view of 1.3. For instance, a band minimum is something like minus 0.1 EV below the Fermi surface and if you view as a half then it's substantially lower than 1.3. So if you can with high resolution measure that band minimum you can also establish a key parameter for the many body physics here which is basically this U term in the DFT plus you calculation. Okay, so now finally I'll show you some data but to the data do not disappoint these are now subtly when you do this experiment and sure enough you actually resolve these features at the around the gamma points and you see a nice seemingly sort of circular thing which has three fold not six fold symmetry. So it doesn't invert so if they rotate by 180 degrees that pattern is not the same. The other thing that you see is you see evidence that there are actually three bands there and we just label them alpha, beta and gamma. And the minimum is minus 0.1 EV which means now you could actually compare it directly with the DFT plus you calculation and then isolate this U term. Now if you move the beam on the sample actually you rotate this pattern. Okay, you rotate it if you like by 180 degrees or if you wish it 60 degrees which of course is equivalent to 180 because it's of course three fold symmetric pattern. So what you can see here at the top you can see that this pattern here is rotated so flipped through the origin. Also if you look at the energy Q dispersion curve it's simply also just simply flipped around the origin. So this pattern here is really crucial is not symmetric going through between the M and M between the M prime and M point. So depending on where you are in the sample you get different looking band structure but it's always symmetry related in the sense that there are two band structures that you see which are simply rotated relative to each other by 180 degrees. So the twinning matters, yeah. Yeah, and now there are and sure enough I'll tell you in a minute. Yeah, that's the next topic but let me just do the material science housekeeping first and then we can do the physics. So just on the material science side you can actually map out this crystal and essentially what's happening here is the crystal is twin and you have you can actually map out the band structure in different locations and actually have my postdoc, Sadie Kihana wrote a fancy machine learning algorithm to go through all the data and identify which to which of the two rotations the different bits of the sample belong and so here's a nice map and now getting on to the physics just one other piece of housekeeping these data are in fact consistent with synchrotron data at the other gamma point if you add up the data from the different from the different rotations okay so the synchrotron data is just sort of the circle if you then simply add the two types of domains that we have you get something which looks rather similar to the synchrotron data but as Andre just pointed out the resolution is much better you can start to do physics with those streaks so let's talk about the physics you could do so this shows first of all the comparison in detail with DFT DFT actually this is a DFT calculation where we've done a little bit of averaging along the Z direction simply because of course even here there's still a finite escape depth for the electrons but what you see here next to those data basically going from the M prime to the M point is three major bands crossing the Fermi level three major ones and then amazingly actually up here there is a flat band apart just about 20 or 30 millivolts above the Fermi level and so this actually the DFT really replicates that structure with one big proviso namely that there are three bands crossing the Fermi level not two so there seems to be there's a spare band that's come in into the data that one, the beta band it turns out that beta band is the sharpest one of the lot and in fact what I'm showing you here is just cuts through the actual data just showing you how sharp in fact that beta band that beta band really is and what you're seeing here at the at the left is two polarizations and that turns out actually whether you see that band or not depends on the polarization how you see that band but what's found is you get fairly sharp what we call these alpha bands but then if you tune into this vertical polarization you actually get you can actually see what we call a gamma band which is here and on top of that you see an extremely sharp beta band and in fact if you just analyze a mean free path that you get from that it's an axis of 100 angstrom it's something like 150 angstroms which is actually comparable to what you get as a mean free path from the just the very simple fluid analysis of the bulk resistance this is around 4 kelvin actually it's around 4 kelvin it's down the domain size is just measured in several 20 microns type so the scale bar is 40 microns so you just park actually the data that I'm showing most of the data would park here yeah so depending on the polarization so here here you see basically you have to look at the contour plot you see two things and I'm just cutting very very close to the front edge here and so what you see here is you do actually see two things as if this thing looks like a shoulder but it's actually another peak and then you see this extremely sharp object rising from that yeah on the other side you see alpha band is a fairly sharp peak but not quite as sharp as one so beta is the sharpest one of the one beta is also the one that makes the least amount of sense because alpha and gamma just sort of exist everywhere beta just stops just just sits there okay so this is this is interesting actually just for the record I'm not going to go through this since it's a little bit too detailed is these flat bands somehow these these I didn't mean these flat bands these the small fermi surface looks relevant for other measurements for instance the haspen alpin there's actually for instance you can calculate from our measurements you can calculate the dhva frequencies for this for the small gamma band and actually get values which are which are close to those actually they're actually attributed to something completely different they're attributed to this to these Dirac points which DFT shows are just not there so we have a feeling that we actually have resolved why you do see this the haspen alpin even though and it's just by a coincidence that whatever calculation was done for the the haspen alpin coincides with the incorrect band structure for the material but this is this is a detail but the fact is these bands matter in the bulk ok now there's another interesting thing about this this stuff so we said that there are three bands when in fact I really expected only two based on the DFT but if you warm up from six kelvin or 70 kelvin that beta band just disappears so the beta seems to be a low temperature a property of a low temperature state doesn't the field get worse? ah that's a synonymous I'll talk about broadening now of course of course it could just be broadened out but the fact is you cannot identify it anymore yeah let me let me now show you what what else we learned here so we actually have plotted up here for you I've plotted the the widths of these peaks which is of course just the inverse scattering length as a function of the distance from the Fermi surface and so you'll notice this is here in inverse angstroms so that delta k there's a half width and it turns out that and what I'm plotting for you here are the data sets where the different colors correspond either to different bands beta band or alpha band and different temperatures so the hotter the alpha band which we can still identify here at the high temperature and then at the low temperature at 6th Kelvin it moves down to there this is the beta band which we can only resolve at the low temperature and what's very interesting is these straight lines here correspond simply to the really silliest marginal Fermi liquid ansatz where you say that essentially this width here this half width is precisely equal to essentially the is precisely limited by the wavelength of these quasi particles as measured relative to the Fermi surface that's a slope that slope is exactly one so that's a funny thing so in other words these things to here over a phase shift which is precisely defined by the distance to the surface okay so there's something interesting going on here and we suspect basically that there's some kind of strong correlation physics here which may now come from the combined effects of an empty flat band which we did not see and then perhaps you which is quite sizable 1.3 EV and of course let's not leave out spin orbit coupling so the physics of generating this band here this extra band may be physics that we're all familiar with from other systems including at the fermion systems where you could actually generate some kind of a sharp quasi particle resonance which is induced on account of partial immobilization of carriers via hybridization with this flat band so this is so we look for a flat band I don't think we found it we did find it in DFT calculations if you look in detail at the photomission data which we believe now is bulk and very well resolved it seems that there's action interesting many body physics effect which we ought to be looking at so just summarize arcus plus DFT no flat bands northera coins and simple cagamate monon bilayer calculations but near the gamma point strong correlation physics perhaps connected with flat bands just above the last two minutes let me just talk about the spin sector of this material so couldn't get anywhere with the simple models for this cagamate lattice when we looked at the electronic spectrum and photomission the question is do those simple models make any sense even for the spin sector rather than the ordinary particle sector and here I actually have to affirm you that on the spin sector things are amazingly simple so we've done relatively elastic x-ray scattering measurements of the magnoms here and indeed actually we do find a strong optic mode and that optic mode is indeed coming is indeed what you want for this dispersion surface remember what I said at the beginning dispersion surface essentially the cagamate thing has three parts to it it has essentially what I expect for the honeycomb lattice for this Dirac points plus a flat K independent thing stuck on the top and one can actually see that flat K independent thing and the data extremely simple much simpler than photomission data are life continues to be simple there's actually only one coupling constant that we can identify that coupling constant just comes from the nearest neighbor it's 25 and a half and actually that gives you even though now ignoring the two dimensionality a mean field transition temperature for the material of 800 K which is not terribly far from the 640 K that's being observed so we have the simple light in the spin sector rather complicated life in the pausing particle sector so summarized interesting flat band physics without without highly localized orbitals or spins on the cagamate lattice at first sight iron 3102 looks like a great realization but there's really no evidence for the flat electronic bands as one would have hoped from the initial you know jargon when type calculations however it's still worth thinking about this stuff I'm going to cover this gamma point centered small primary surface where there's clearly some strong interaction physics going on and there is also DFT evidence for a small sort of flat band near that near those parabolic bands that are defining those small primary surface at the same time at first sight second sight but at first sight actually the spin waves look extremely simple let me just leave you with this the stuff is both simple and complex and I think it has some legs left for people like yourselves to do some theory on excellent other questions about probably question about the second talk that you are going to give if I you phrased magnetic results in terms of spins just spin Hamiltonian if instead I will use fermionic length and takes point of view that you said that there are bands near the Fermi level and presumably flat band above if I take this and calculate particle whole bubbles and then from them calculate spins susceptibility do you think did anyone do this and second that probably flat band will have some effect on Sfqonomica that tiny flat band I don't know yeah what I can tell you is that this story on the spins is much more when you start looking at the details of that it's much more complicated than that the physics of this magnetic response function the poles of the magnetic response function are correctly given by the stupid theory with one parameter but everything else the real parts of the pole are given but everything else is completely different but in general this is a metal it's a very good metal and the life is extremely different I mean I can just maybe give you a preview because I skipped over those slides this shows the this is the essentially the magnetic susceptibility as a function of q and omega for the simple Kagami lattice of course with rakes you only have access to the zone center but the fact is that the selection rule for normal normal system with localized moments which says actually the optic mode should not be visible for example in the cubos to zero limit that selection rule is hugely violated in this stuff and the other thing of course if you start looking at the we've then of course done an analysis data the eigen frequencies as I say the real part of the eigen frequencies is actually given correctly by the stupid theory but the imaginary part is much more interesting and also the scattering amplitudes are not at all given by the do not obey the normal extension rules that you have for an insulator so life is much more interesting you showed some polarization dependent data on our piss is it clear from that what orbitals are involved in the beta band that is puzzling well from the polarizations of course you can tell that but as I say this beta band doesn't seem to show up in the bank calculation so what orbital is it which orbital it obviously has to be the same orbitals that you see in the gamma and the gamma point the gamma band we do know a lot about from the from the DFT because it does show up in the DFT that one does show up in the DFT so the our hypothesis is basically that the beta band is derived from a hybridization of the gamma band you see it's out there hybridization of the gamma band and the flat band and then the alpha band for some strange reason doesn't really hybridize maybe for some symmetry reason with that flat band above it but this at this point this is just conjecture and one should be able to you know one needs to go and ask very detail questions of the DFT calculation which we have not yet asked you mentioned something about marginals from a liquid telling that delta K precisely equals to K minus K if so I just wanted to you don't mind what is delta K? delta K is the half width delta K is the half width of a Laurentian that's used to fit the data I see, so it's Laurentian feet and it fits yeah those are these fits these are the these are the fits here okay right and the half width of this thing is exactly this thing it's exactly that but what that means is if you have a confining it's as if you said that it's a funny coincidence it may just be a coincidence but basically if you say I have to fit one oscillation of a quasi particle within that mean free path it's a numerological thing I'm not sure I'm surprised to know that Laurentian fits at all quasi particles with some lifetime but a half width doesn't it doesn't depend on whether I'm telling you about Laurentian or Gaussian right? yeah but it is it does you know the way these things have tails on them so you certainly need there are tails on these things and so and there's asymmetry okay I don't see other questions so let's thank the speaker again so the point is basically that those beta bands are generated dynamically at low temperature this is an exercise for the theorists it's validator we're through that plane