 Okay, so good morning, everyone, welcome. Let me just click this. So as I was introduced, thank you for that. My name is Alon Reineck, and I work for Synopsys, where I developed, where, sorry, ooh, jitters, sorry about that, where I manage the development of the Node.js and .NET agents for Seeker. If you've never heard of Seeker before, it's probably the best I asked solution out there. If you haven't heard of I asked before, it's fascinating as all application security is, but it's also, unfortunately, not my topic today. So this is the last time I'm going to mention it. I want to start off with a question. So by shove hands, who was at DevCon for CZ earlier this year? Awesome. So if you've never heard about it or haven't attended, first of all, I have to recommend, do attend it. I've been speaking at DevCon for CZ since 2013. This was actually the first conference that gave me the opportunity to publicly speak. It's awesome. It's really one of my favorite conferences throughout the year. Although DevCon for US is kind of giving it a run for its money. So good job, guys, yeah. Final question for the two of you who were at DevCon for CZ. Did you go to DevCon for CZ and miss my talk over there this year by shove hands? Yes, sir. It's a bullion, either. Well, no, no hard feelings. There were quite a few good talks in parallel. I'm actually bummed I missed some of them. So back in DevCon for CZ, I gave a talk on how Open Source made me a better programmer. I got quite a lot of feedback for it. Quite a bit of it was positive, so thank you everyone. And one bit of feedback kind of stuck to me. And this feedback said that I was kind of stretching the truth there, not in the sense that Open Source won't make you a better developer. It definitely would. But calling myself a developer was kind of stretching the truth. And the reason for this is kind of simple. A developer's day should look like this. Now, I see a couple of grins. These are tools I like to use. So just say I am not going to entertain the religious debate of IntelliJ versus Eclipse. I'm most definitely not going to entertain the religious debate of Vim versus Emacs. Like, all religious debates, both sides have a point and the argument is pointless because neither of them will convince the other one. We aren't going to go there. If you use whatever tool to develop software, if it's one of the tools over here, if it's a tool not over here, if you use Notepad, if you use a bunch of butterflies, if you are creating software, you are a developer. No religion involved. Unfortunately, My Day doesn't usually look like that. It looks like this. So I see a couple of people with kind of questioning looks and a couple of people nodding in shared pain. So for those of you who do not recognize these logos, My Day, mostly dedicated to writing a bunch of email, reading a bunch of more email, moving tasks around in JIRA and attending conference calls. A whole lot of conference calls. If you don't recognize these, this is great. I completely envy you. So going back to that point of feedback, can I really call myself a developer? No, fair enough. I get this. But I don't think this feedback undermines my core point. My core point being that working on open source has been the most intense and the most rewarding learning experience in my career. So if I can no longer call myself a developer, but I still want to fly out to conferences and give talks, kind of revamped that talk and asked, can working in open source help me become a better manager? And I'm going to say yes and explain why. So first of all, let's start out on square one. Make sure we're all on the same page. What is being a manager all about? So even though I am no longer a developer, I've retained a very important skill from my development days and I'm still really good at copy pasting. So here's a definition I lifted off Wikipedia, which I'm going to read to you. Management or managing is the administration of an organization, whether it is a business, a not-for-profit organization or government body. Or if I sum this up really quickly, ugh, moving! Okay, I'm sorry, that wasn't really polite of me. It definitely was impolite to the hard-working contributors to Wikipedia. You really put in the time and create this body of knowledge for all of us. And it really wasn't polite towards managers in general. Although to be completely honest, I've been doing this for, give or take 10 years, it is the truth. Management really isn't that interesting. The reason it isn't that interesting is because it really isn't that difficult. It's kind of simple. You decide what needs to be done, you decide who needs to do it, you tell them to do it, once repeat. Simple, easy. Well, almost. At least being a bad manager is really easy. If this is the way you manage stuff, it's the easiest job in the world, and you're definitely doing it wrong. Being a good manager is really, really difficult. It's really challenging. It's a whole lot more than just telling people what to do and when to do it and how to do it. And well, there's a lot that goes into being a good manager. A whole profession, it's a whole skill set, but the one key element in my mind that differentiates good managers from bad managers, really sets them apart, is leadership. People don't follow people who just tell them what to do. People don't follow other people by virtue of some taunt up title. Senior manager of Node.js and .NET age, nobody cares. Just is not interesting. People follow other people, people follow leaders because they're inspired to do so because they buy into this shared purpose. They buy into a common goal, they buy into a path that will lead us to this common goal. And well, I can't claim I know all the managers in the world, obviously, but from my own small perspective of being in the tech industry for about 20 years, 100% of the good managers I've worked for, with or have worked for me were good leaders regardless of their position or their title. In contrast, 100% of the bad managers I worked for worth, note that I didn't say worked for me, I don't hire bad managers, 100% of the bad managers I worked for worth were poor leaders. And you can really recognize us when you step out of the scope that they're managing and see how they interact in other places. So if we kind of want to talk about, sorry, how open source can set you up to be a good manager, first step is to ask how you even become a manager. In the tech industry, more often than not, this happens by something I like to call a reverse promotion. Back home, we also call this an Israeli promotion. If you've never heard about this, this is the weird concept of instead of a normal promotion where you get a title and do the job that fits your position, in a reverse promotion, you first do the work, you do it well enough, long enough and visibly enough so you get noticed for doing this work, and then hopefully someone notices and gives you the title or the position to match the work you're doing. It's also called a reverse promotion because usually you just get a bunch of other responsibility and more stuff you need to do with exactly zero dollars of a pay raise. So you kind of fund this new position by spending more of your time, which is always fun. As a side note, there's a small line in this name. Can anyone figure out why I'm lying here? Because I am lying through my teeth. The fallacy, the lie here is that management is not a promotion. Becoming a manager is not a promotion, at least in good companies. Management is a profession. It has its own skill set, it has its own way of doing things, it has its own tasks that need to be done. Transitioning from an individual contributor to a manager is not a promotion. It's a career change. Now, good companies understand this. Good companies have the infrastructure and the processors and the HR facilities to support people who want to change their careers. To support quality engineers want to become software engineers, software engineers want to become PMs or data scientists, scientists, sorry, or managers that have the training, that have the support system around us. Bad companies don't understand this. Bad companies kind of have this arbitrary cap for individual contributors. So you go on and kind of progress in your work and at some point you hit this glass ceiling and then since you're good at your job and you want to continue advancing, your only option is becoming a manager, which is horrible because a lot of the time this isn't done since you're passionate about management or actually want to do this but because you have to. So you have really good engineers who kind of become managers by necessity without wanting to be managers, without understanding the difference in profession and quite often these good engineers become really bad managers. Hopefully in good companies this doesn't happen. Good companies will allow you to advance as an individual contributor throughout your career and will allow you to shift to management if you're actually interested in this. If your company doesn't have this notion, talk to me later. I am recruiting and I do understand the difference here. But sorry, that was kind of a segue. I want to get back to my topic. What does open source have to do with all of this? For me, everything. Open source by definition does not have titles, does not have ranks. It might have roles. Open source has these specific roles of maintainer or committer or someone who's in charge of something but first of all these aren't usually these aren't official titles. And more importantly, these are all reverse promotions. Pleased most of them. 99.999 something percent of all these roles. People who have been doing the work and get noticed for it and the community by consensus kind of votes them into this new role says hey, thanks for a great job. Here's a bunch of new responsibilities for you. Thank you guys. Really appreciate it. So open source has everything to do with this topic. That open source is all about being able to exert influence without the actual authority, which is leadership at its very core. Once you know how to do this properly, once you become good at this, becoming a manager is kind of a non-issue. You just continue doing the same thing with a title match to do it. So how do we do this? How do we treat working in open source as a learning experience as something to set us up for becoming managers or becoming better management? Managers at least. But first of all to quote another great leader, be the change you want to see. Almost, this is probably a misattributed quote. But anyway, be the change. Lead by example. You cannot expect others to do what stuff you aren't willing to do but yourself. It just does not work this way. If you want people to look up to you as a leader, you have to walk the walk and not only talk the talk. You can't go on saying, we need to improve the quality of this project. We need to make sure that all new PRs have at least 90% code coverage, okay great. And then you go on and submit a bunch of untested code. It doesn't work. People notice hypocrisy and people do not follow hypocrites. If you aren't willing to actively share that, A, this is doable and B, this is important enough that you're willing to divide your effort to it, no one else will. So this is critical, this is crucial. And this by itself is not enough. It's not enough for a very, very simple reason. Most of us human beings are really bad at reading minds. We are not born telepathic. We don't just get it. Most of us need to be told things. And as a famous programming language says, explicit is always better than implicit. We have, as leaders, we have to convey what we expect from the other members of the community. Luckily, open source communities as a whole have a bunch of processes, a bunch of cultural aspects that really lead into this. We, we as open source communities have become really good at communicating what we once done. And for this we have backlogs and issue trackers and feature review processes, et cetera, et cetera. Really good at listing out the entirety of work we expect. Large projects, better organized projects, have also become really good at communicating when they want stuff to be done. We do this by sprint planning and by milestones. We in open source have become quite good at saying we are at feature freeze. We will not review new feature requests. Although if you're doing this correctly, you can just say that, you turn this into a conversation. Thank you for your contribution. We are at feature freeze. We won't be reviewing new features, but we expect this version to be released on October 23rd, after which we will resume feature reviews. And you kind of, you then just throw stuff over the wall. You also take responsibility for it and say, okay, we won't be doing this now, but here's when I'm gonna get to it. And probably most, most importantly or most obviously, open source projects have become really good at communicating how we want stuff to be done. And this happens in a bunch of different levels. First of all, we have our coding styles. We have our guidelines. This is how you're supposed to write code. The interesting thing to note here is you don't necessarily have to have people involved in this conversation. Does your project use a lender of any sort? Lending isn't a technical item. Lending is all about communication. It's a very simple, very explicit, very cheap, very obvious way of communicating to contributors. This is how our code should look, even though you don't need to have anyone else in this conversation. I run my code, I submit a PR, run the build locally, the lender will spear out a bunch of messages, use four spaces instead of a tab here. Use tab instead of four spaces here, camel case instead of snake case, vice versa, whatever. This is all about communication. This is all about telling people how they interact with this project. In a higher level, we also have the infamous contributing MD file, which doesn't just say four loop looks like that, initiative statement looks like that, but you're going to have deeper considerations. We are really concerned about the size of the binary, so make sure you never statically link anything, but I need dynamically link, or this needs to be extra resilient and rely on nothing, always statically link all your dependencies, but follow the approaches for different projects. We've become very good at communicating these. And on the highest level, probably the most interesting part is that open source projects have come to the realization that people don't communicate, people don't really interact with the source code, people interact with other people. And since we are very bad at reading minds and a lot of us don't just get it and we need stuff spilt out, in the last couple of years, projects have started adding codes of conduct. These are, again, documents that say, this is what's, what are valid or invalid ways to interact with other contributors. This is how we can and can't behave. Now, this isn't to put people on the spot and it isn't for lawyering and saying, well, in this email message from 2013, on your fourth line, you did this which violates that section of the code of conduct. You can, but that's not really the point. It's explicitly stating how we want to interact, how we want our community to look and being able to call people out and say, hey, this isn't what we agreed about. This isn't just my opinion. This is a consensus we have written down here. Let's try to follow it. So, as leaders, we started out by leading by example. We continued with very explicitly communicating to our community members what and how we expect stuff to be done. And now we kind of get to the danger zone because we're, as leaders, we are staying the first term. We are starting to get noticed. People start coming to us for questions. What should I be doing? How should I be doing this? And this is usually new managers, classic pitfall. You don't have to know all the answers. It's really fun being the person with the answers. It feels great to have people coming to you and saying, hey, how do I do this? Oh, you look over there. Yes, thank you. You saved my day. Makes me kind of feel great. I'm a superhero. Solved somebody's problem. This is intoxicating. It's addictive and it's really dangerous because once you get to use to this, you kind of get this wrong notion that you have to have all the answers all the time which means nobody else can have any answers because you have all of them. This is terrible. You need to be really, really careful of this. Good leaders aren't intimidated by members of their own communities, of their own teams. They aren't intimidated by someone else having better ideas. Good leaders celebrate us. Good leaders understand that the strength of the team, the strength of the community is as strong as its strongest members. Having other strong members doesn't dilute your leadership. It brings the entire team forward. Once you kind of recognize this and reconcile with us, you can start making better decisions usually by not making them yourself by not insisting on having all the answers but by having conversations, by bringing people in and saying, okay, let's talk about this. Let's bounce some ideas around. Let's see what the best idea is. This is great on paper. In practice, it doesn't necessarily always work. Not because it's a bad idea but because people are people. Quite often, the idea that wins in this situation isn't the best idea but the loudest idea. The text version of this, since most open-source communities and conversation happen in text and not in voice, is the idea that's presented in the best English, which is kind of a shame because open-source in its core is something global and distributed and many of us don't speak English as a first language. It's our second or third language. But we still kind of have good ideas. Even though our English isn't that great. So if you leave this unchecked, quite often you kind of consolidate on the most eloquent people. People with the best English. The people with the most free time who can reply to each and every email in the mailing list. I cannot, right now I have 960 unanswered emails just in my inbox. So you kind of have these natural people who evolve as the go-to people, the people with ideas, but these are not necessarily the smartest people. These are not necessarily the people with the best ideas. And part of your job as a leader, as a manager, is not to moderate us necessarily. Not to say, well, shut up Rick. You've spoken enough. Give someone else a chance. That's being a bad manager. But making sure that the best ideas really emerge. And you do this by pulling people into the conversation. First of all, preface for this, which again is kind of obvious, but as I said, we are bad at reading minds. So I'll be explicit instead of implicit. The base thing to do is to make sure this is a safe space. Make sure everyone can voice their opinion. Way too many communities where someone comes up and say, yeah, here's an idea we can do da, da, da, da, da, da. And quite often they get the answer. Excuse me. Who are you? How long have you been programming? Well, I've been programming since you were doing long division. I'm not gonna entertain this nonsense. True story. We're not name names, but I actually have a PR which I sent to some project I want to name. I got an answer, but you don't even have a PhD. You did not formally prove this. People like you should not be writing code. Okay. Thank you for your feedback. This speeds up your process in a factor of 15. If you don't want it, don't take it. But thank you for your feedback. I'll start working on my PhD right now. This is not a healthy community. This is definitely bad leadership. So the very base should be make this safe space. Make sure everyone can voice their opinion. And if they have a bad idea, you can say this idea isn't good because X, Y, Z. But you're criticizing the idea not the person who presented it, which is a key difference. The kind of next stage of this is actively pulling people in. And here too, there's a right way and a wrong way of doing this. The wrong way is putting people on the spot. So Shirley, what do you have to say about this? This is terrible. Now, everyone is looking at her. She has no idea she's going to be called up and chances are she's going to say, no, I don't have anything to say about this. Stop looking at me. And not only have I wasted everyone's time, I've also created this image of her being someone without ideas and no one will come to her for ideas later on. So don't do this. Sorry, Shirley. Nothing personal. The kind of right way to do this is, first of all, to lend your own credibility outwards, especially after you've become recognized as a leader in this community. So you can be in a discussion and say, well, this is really a complicated problem. I'm not really sure myself, but I know David is really knowledgeable about the subject. I'd love to hear his take on this. This is completely different. First of all, you aren't putting someone on the spotlight right now and you are lending your credibility. It's not just David what do you think, but I know David knows a lot about the subject. I'd love to hear his take. Doesn't have to be right now. Let's wait for him to chime in, but let's not move forward till we heard him. If you really want to vamp us up, ramp us up, sorry. What I like to do is go offline and encourage people to come in, which kind of looks the same, but it's even more powerful because it's done privately. So you go in and say, hey David, I've seen your work over the last couple of weeks, months, whatever. Really impressed by it. Really love to see you chime in here. And now you can start a feedback loop. Chance is on. No, no, I don't want to contribute. Okay, why don't you want to participate? What's a missing piece? Oh, you aren't sure about your English. Okay, why don't you drop something out, bounce it off me, I'll review it, send it back to you, and then you can present it to the community. You aren't sure about the idea. Okay, let's discuss privately once you're confident enough, you can present this. There are a lot of ways to bring people into this discussion. This to me is kind of the key in good leadership. Not only managing tasks and making sure that this gets done before the release and that doesn't, and we darted all the eyes and crossed all the teeth, but actually helping others grow, making your community stronger by making the participants stronger. Now this, I know this sounds like a lot of corporate management talk, kind of half expecting me to wear suit and tie and charge $500 an hour, because I can, your company's gonna pay for this anyway. It really is not, it really isn't. So here's a real-life example from a project called Moquito, it's a marking framework in Java, which I started, I've been using it for years, I started messing around with contributions about two or three years ago. Been doing these small things and I really got noticed here. And this is feedback for one of my PRs where the maintainer discusses technically what's going on here, da, da, da, da, da, da, da. And here, actively, publicly, he's reaching out and saying, well, you've done a lot of cleanup work and a lot of bug fixes, do you want to contribute an enhancement? Here's something I think could be interesting for you. This ended up being one of the major feature. I think it was 2017-12, don't remember to be honest, it was a couple of years ago, but check out the link if you're really interested. This works, I don't know this person, I never met him. I don't know where he works, I have no idea if he's a manager or not. But this is definitely leadership. This is in the open-source space, no money involved, no corporate management, no nothing. This is how you drag people out, how you help them grow, how you make them more prominent, more effective contributors to your project. Now, if you can do this in open-source, you can most definitely do this within your own teams, within your own groups and stuff you manage. I'll share the slides, of course, if anyone wants to link later, it's just a kind of a last thought, a last notion. We as managers love to measure things, just kind of is corporate management. We get hit up a lot with numbers and metrics and measurements, and we often spend a lot of our times preparing slide sheets and sharing 12.4.5, 12.45 at least, percent improvement here and there. Here's a metric for you as managers. In the last week, month, year, how many people have you helped become better contributors? Have you helped promote? Have you helped become leaders in their own rights? If the answer to this is zero, in my opinion, and I really don't care about your performance review in your parent company, as a manager, if the answer to this is zero, you are not doing your job. This is not good management. And with that, I'll open up the floor for questions. We have the handheld mic in this room. If anyone has a question, you can raise your hand and I can try to get the microphone to you. So you started with some examples of various corporations. Have you had experience with organizations that separate sort of HR management from technical leadership? Well, first of all, yes, definitely. And the different companies kind of do this in different ways. If you started managing in the 1980s and your organization is still stuck there, I call this metrics management, where you have your HR manager and project lead you need to report to, this can work great if they both know what they're doing and they actually talk to each other. It really depends how you implement this because quite often, but it is known to happen that these two functions don't talk to each other. And then you have your functional lead who's sure you're going to deliver a feature by the end of the week and is planning on the next big feature for the next year while your HR manager knows that you're going on vacation for this week and you intend to transition to product management so you won't be doing the next feature. I think it is okay. It is a valid structure of management, but communication is key. First of all, the HR manager has to communicate with the functional leads or technical leads, either you may call them. Second, the HR manager has to at least have a notion of what's going on. You can't have these conversations where the tech lead says, okay, we're gonna have your programmer doing this and that and the HR manager kind of blankly stares and so on. Yeah, good idea. And can we have logging on that, please, also? You have to, the HR manager has to at least have a say and at least understand what's going on. So this can work. I think it works really well if you have really good technical people and really good HR managers who are really good at talking to each other. Usually in my experience, you just add spuffs here. HR manager can just be bad at our job. Technical manager can just be bad at our job and even if they're both great, but they then talk to each other, you have another spuff. I'm not a fan, but if it works for you, great, more power to you. I think we still have about five minutes for questions. Does anyone have questions? If that does conclude questions, I'd like to remind you all that, I believe lunch is going to be starting. It's gonna be right outside the doors. Can we all thank our speaker? Thank you all for your time and if you're interested, feel free to reach out or hit me up late outside. I'll be the only person in a purple synopsis shirt. Really easy to spot. Thank you again.