 Engineers suck at managing people. This is a statement that most of us have heard before. I have heard this many of times during my career. I guess that most of you have heard it as well. This, in fact, is a statement that is a myth. In my opinion, it's actually busted already by managers that we have in the field. And actually, I'm going to bust it even more today. However, before we jump into the topic, who am I? I'm director of engineering for last a little over a year in Spoton. Previously, I was Python developer for more than 10 years, also taking some management responsibilities. So I'm just after this transition that I'm going to talk about. This knowledge is fresh, so it should be good for all of you. But before we start with the management part, let's go through the engineering engineer's career path, which starts with junior or intern position. This is the time when you are learning how to code, how to build solutions, how to solve problems. Also, you are being coached by more experienced developers about what's good and what's bad. This gives you a possibility to actually focus on coding, focus on learning about technical skills. You don't actually need to think about anything more. You should be getting tasks that are pretty precise. You should be able to work on the solutions under guidance or more of more experienced developers. After some time, this can be a couple of months, a couple of years depending on the person, you are becoming mid-level developer. And this is the time where you are getting a bit more independence in your actions and also you are getting in touch with business part a little more. You start to understand how your decisions, how your actions are going to be reflected at the business side, so how it's going to be visible for the customer. This is also the time when you are still are going to be coached by more experienced developers, seniors, architects, whoever you have around you. Afterwards, after some time, you become a senior developer. This is the time when typically you are no longer being coached by anyone. Instead, you are coaching younger developers. And also you have much more visibility into what you are doing, how it's being reflected on the business side. Also, it means a little more meetings for you. However, this is not crazy amount. Yet, it's very important to have a bit of business overview when you are in this position. And what's happening next? There can be two things that will be happening. You can be taking one of two paths, actually. First of them, technical one. This is the path where you become staff engineer, principal engineer, architect. You still get your hands dirty with the code, with the solutions. You are busy with actually providing solutions to problems that are brought to you by business people, by your support, generally from outside the world. But you are still a very technical person, and you get your hands dirty with whatever you do. The second path, it's people management. And it starts with team lead position, not the tech lead, because tech lead can be still somewhere in between. And then you go up towards engineering manager, director of engineering, whatever else is being called. And this is the path we are going to focus later on. Of course, first important topic here is that nothing is being written in stone. You can switch or pivot the paths that you take, whatever you like. If you feel that technical path is not for you anymore, because this can change, you can jump to the people management. If you feel that being manager is not for you and you just burn out, you can change to technical path. Also, some may say that this is very artificial division. However, in many companies, I would say around 80%, the higher you go in hierarchy, the better pay you get. So this is the reason why most of the people actually are going higher in the hierarchy just to get better salary. Of course, for the sake of this presentation, I assume that we are choosing the people management path. And the first step is becoming a team lead. You are still expected to be coding or doing some technical work during this time. However, you have also some people management responsibilities. Sometimes it's running one-on-ones. Sometimes it's taking part of the project management responsibilities. Sometimes it's helping team with fixing some problem or running some brainstorms. It depends from case to case, but in general, you are part coder and part something else. And before we jump into strictly management, I want to talk a little more about why engineers are being taken or perceived are people that cannot manage other people. This is coming from stereotype. That is hurtful. That is not actually true, but it is. So let's talk a little about this. And it says that engineers are introverts, that they are antisocial, that they are not creative, that they are geniuses, on the other hand, or wizards even. And of course, Big Bang Theory Serious didn't do a good job with fixing the stereotype. On the other side, from my perspective, about being introvert, yes, some of us are introverts. I am introvert myself. But it doesn't block anything. It doesn't make anything harder. About being antisocial, as we all can see over here and over the internet, we are not antisocial. We are here to socialize as well, because we are coming here physically. About being creative, absolutely not. As Leonardo Giordani said at his talk about the architecture, development is art and science. Of course, this is not art in a meaning that you see someone painting the code or singing something. But still, solving problems requires very creative thinking. So in my mind, coding is act of creativity. About being geniuses or wizards, no, we are not unfortunately. I would like to, however, we are just thinking differently. We know how to solve problems with code. We know how to solve problems with technology. And this is how our brains work. And that's it. This is end of the stereotype. As I said, it's hurtful, but it's there. So let's say you accepted or asked for the position of the engineering manager. And what now? Because your responsibilities are changed greatly right now. Your role right now is not to code. Your role now is not to deliver actual solutions. Your role is to make your team or your team's lives easier to do their job the most efficiently and the best as they can. Of course, this means sometimes guiding them. Sometimes it means protecting them from too many meetings, for example. Sometimes it means disabling some decisions that may hurt the business, actually. Right now, you are working with the business so much more that and you know much more context about what particular decision would do to the business side, to the customers of the company that you are working for. The best example here is a lot of developers, myself included, have a time in their lives when they want to rewrite software that doesn't work as intended or is just poor quality. However, when you switch to the role that is closer to the business, you realize that you cannot stop the factory for half a year, for a year, because you want to build it from the ground up. It doesn't work. You will lose all the customers and you can close the company this way. So these first months or weeks can be confusing or frustrating for you. There is nothing bad about it. This is a new situation for you. And this is something that is very normal for everyone. We need to learn how to actually thrive in this environment and how to excel in it if we want to continue our way in this path. Of course, it doesn't have to be everyone. We can always pivot our career path. This is also the part, the beginning, where you can become crazy or evil the most easily. This is because of the fact that you may get a bad habit or get some wrong behaviors or you may be doing something randomly without having a reason for doing it. So this is the part where you need to be the most careful. And these are the questions that you are going to be answering all the time. You are going to answer these questions for your teams. These are going to be the questions that you answer for your supervisor, sometimes for your customers, sometimes for some random people that you meet. And actually, you will talk so much more with business part of the company than you used to talk before. Also, you are responsible right now for your team's result. You are not responsible for individuals anymore. You are responsible for your team or your team's output. This means that if team member A will do something wrong, your supervisor will not care about this. You will just get the message that your team did something wrong. So this changes optics a little. Also, there are two the most difficult part of being a manager. First of them, people are non-binary. There is no zero and ones. There is no black and white when talking about people interactions. Or there is, but very little. And you cannot expect two persons to behave the same when given the same task because they have different history, different experience, different knowledge. So everyone would behave and understand you differently. Of course, the better you get in sorting out this gray area into something that is closer to one side or the other, the better outcomes you will get. So you need to work a lot on improving yourself with solving the challenges. One of them, the biggest one, is communication. As I said, there is a lot of gray area because a simple statement, how fast can you deliver this project? This is actually a question of the statement. But it can mean so many different things. From one side, this can be actual question asking for timeline. And the expected answer is within a month. From the other side, someone may actually use this question as a way to force you to deliver something faster. So you see that there is a lot of gray area in communication that you may need to deal with. There is one big point when speaking with people. As I said, we all come from different experiences. We have different history. And we also come from different cultures. So this is something that you need to take into account as well. That other people may be just thinking differently because of the culture that they were raised at. Of course, between Europe and US, there are some lingual differences that you need to be at least aware if not using them actively to solve some communication challenges. Also, across the country, I come from Poland and between North and South of Poland, you can also spot some significant communication differences. This is something that I will continue a little more later, but absolutely differences in communication between people are key to success as engineering manager. So the question is, how to get better, especially in the beginning? The easiest answer, yet the wrong one, is practice, practice, practice. It's wrong one because, as I mentioned in the beginning, when you start, you can get bad habits. You can start taking bad decisions because you don't know actually what you are doing. Sometimes you know, but most likely you would not. So how to get better? First step, in my opinion, is get a good mentor. This can be a person in your company. This can be your supervisor. This can be your manager or completely other person that is managing people, not necessarily within engineering area, but you value this person for work that they are doing and for the results that they are delivering, and for people that they just are because everyone can have this kind of mentor different. Second point about getting better is to get professional training. For a price of $2,000 or $3,000, your company can pay for it, most likely. And you can go to get professional training about communication, about what to do, about what not to do. And this actually pays off so quickly and return on investment is so high that any company would pay for this kind of training for you happily, of course, if there is a budget and you are not very early-stage startup. The third point that would help you to get better, also pretty cheap one, is start reading. Actually, there is a lot of books. Instead of reading, you can watch YouTube videos or whatever, get some knowledge from external sources. Reading, it can vary. You don't have to read only people management books. One of these books is Amped Up that I can recommend. It's very nice to read. But from the other side, you also can read things like subtle art of not giving a fuck because this work is very demanding for your brain, for your mental health. And if you will not start giving something up in your brain, you will become crazy or evil pretty quickly. So you need to learn how to deal with this pretty quickly as well. There are three main tools that I recommend you using. Of course, you don't have to, but I think it's a good idea as engineering manager. So first of them is Calendar. This is the tool that we all hated as engineers. Really, any meeting in Calendar, for me, it was the bell saying, no, I cannot code. I will be taken out from my flow, from my zone. Absolutely not. Now, after this switch, Calendar actually may become your main tool of work. And actually, don't use it only to schedule meeting after meeting after meeting after meeting. Actually, use it a bit more wisely. Use it to actually structure your days the way you want to look, how they want to look, and to get everything in there. Of course, it means getting some meetings. But of course, you can put some focus time there. You need focus time only for yourself to think about problems of your teams, about potential solutions. Sometimes you need to prepare something for your boss. Sometimes you need to prepare something for the business side. Use Calendar to block some time for it. Otherwise, some other people may basically book you completely, and you will be nowhere with other things that you have to do as well. Also, very simple tasks like getting a lunch break. Don't forget about eating. Come on, you can see managers having meetings back to back without any lunch break. And how can you survive? How can you think creatively without eating food, without providing yourself energy? Use Calendar for that as well. Second tool you are going to use. I already mentioned that is communication. If you don't want your discussions to look like talking of these two sheep, you need to actively learn how to communicate with other people. And this doesn't mean only actually talking, but general soft skills. Because not only what you say matters, but also how you say it. All the body language matters. Being empathetic fact matters. So knowing how your contacts would respond emotionally and how they would understand what you are saying, this matters a lot in the work of the manager. Also, listening is the key. I mentioned plenty of times during this talk that you will be talking a lot. But actually having a conversation doesn't mean speaking a lot. You need to listen first, listen actively, and focus on what you are hearing, and then actually answer if there is an answer needed. There is plenty of meetings that I am at, that I am presented, but I don't say a word or almost a word, because I'm just there to make sure that they go as they are expected. For example, if someone says engineers suck at managing people, this is the time for you to speak up and actually deny this, because this is something hurtful and you shouldn't allow other people to spread this information. You should be example of fact that is not like that. Third tool that you can use in your work as engineering manager is actually leaving some room for some coding. This helps you with resetting your brain to situations and to paths that it used to work for years. Because remember from the beginning of the career until you became engineering manager, you are coding for years. So this is something that your brain knows already and you probably still enjoy solving puzzles and solving riddles that are related to coding. So help your brain by just having sometimes a coding session. It doesn't have to be during working hours, however it can be depending on your situation. It can be side project, path project. Actually I would recommend this way of having some side project because as engineering manager you are not supposed to code and if you take a ticket and you block someone else, this is your fault only. So please think twice about taking any regular development work as engineering managers. Of course coding is only an example of a hobby. So you need to have a hobby to reset your brain. I mentioned coding specifically because this is something that your brain knows and it will help you with resetting after having tough day as a manager. And my final advice is don't be afraid. As engineering manager you will fail sometimes and this is something that you have to learn on. You shouldn't be afraid of making a mistake. Typically this is entry-level management role so your mistakes shouldn't do a lot of harm to the company because they should be corrected by your supervisor, they should be caught by your supervisor and actually unless they cause some significant financial loss or unless you breach a law you shouldn't be receiving any personal consequences about it. And remember again, you can always take a step back and pivot your career path. If you don't feel that this is your thing you can always change the path that you are following. Thank you, this is it. Do you have any questions? Wonderful Jacob, on time. Perfect. Do we have any questions from our audience present today? Thanks for the talk, it's really good. So I work in quite a small team so it's difficult to get experience managing people. If I want to experience coding I can kind of work on an open source project or do some stuff in my spare time. Do you have any strategies to gain experience in management in that situation? Yeah, so first step is becoming a team lead and this is the easier part because I was in this kind of limbo myself for two or three years when I wanted to do the switch but I wasn't able to. You just need to get correct combination of where you are currently, what you are doing and what are the possibilities for you to grow. I was lucky enough to get to the company that was able to promote me because I asked for it basically but you need to do some active research about if it's possible within your company or sometimes you may need to switch the company even and this is it basically. You need to actively look for it. Thanks very much. Do we have any questions from our remote audience? It was really a great talk. What do you think about getting the proper social skills to take a managing position? Is it difficult to grow a proper social skills from the engineering perspective? I don't think so. I was an engineer for 10 years and I was not actually trying actively to grow these social skills. Once you realize that you would like to follow this path I think something would click in your head and you will start gaining this knowledge. Of course reading some books. There is a good book, Phoenix Project or the Unicorn Project that you can read as well. That is somewhere around this area but talking more with people that you know within your current company will help a lot then talking with people that you don't know at the conference here for example would help even better. And this is it. This will grow in your naturally. Thank you. On the topic of feedback. Do you have any particular recommendations or resources or anything you can share? Giving positive feedback is always nice because it feels good for you and for one that you are giving the feedback to. Giving negative feedback is always difficult for everyone because you need to use empathy to make sure that the other person would take the feedback exactly the way you intended to give. If it comes to resources about this I don't have anything specific in mind but there is like a lot of books about communication, giving feedback. A lot of courses, YouTube videos so there is plenty of choices to actually start with this topic but it's not easy. Like there is one thing about reading about this and doing this is completely different. Thank you. Thank you. Hi, thank you for the talk. Just if you're on the fence about maybe becoming an engineering manager is there a way to kind of expose yourself to some of the responsibilities without sort of taking a leap and going into that position or would you kind of recommend just trying it out and like you've mentioned you can always switch careers later? So from my experience I was doing quite a lot of engineering manager responsibilities as a team lead so this is definitely the way I would recommend to stay in a team lead position for a couple of years and see if what you are doing actually is good for you if you feel good with it and if you decide so then this is the moment for you to take the step of faith leap of faith and try becoming a manager full-time in my opinion. Thank you. Thank you. Yeah, okay. So folks we don't have time I'm sorry we don't have time so Jacob will be available of course the hallway you can form a line in front of him maybe you can take numbers to ask him questions so can we have another warm applause and thank you Jacob for the great talk.