 All right, we're gonna get started. Hi everybody, welcome to Developer to Manager, a survival guide. This presentation is targeted at people who are currently developers and are becoming new managers either because they've recently been promoted or because they're considering becoming managers in the near future. If you are looking for a more challenging management topic like doing a team turnaround with a team that is struggling or scaling a team over time, this is not the right talk for you because it is aimed at that first moment when you ramp up and take on these new opportunities and responsibilities. So first, a little bit about me. My name is Kat Kuhl, I am the Director of Solutions Consulting at FFW. Before that, I was the Director of Technology at CHIEF and Agency in DC. If you've got questions about the presentation or if you just wanna talk about it because I love nerding out about this topic, you can find me at webbykat basically everywhere, Twitter, Drupal.org, the Drupal Slack, you name it. So I started coding when I was about 12 years old, like a totally well-adjusted middle schooler would totally do. I've been working professionally in this industry for about 10 years. Initially as a developer, then as a project manager, took a brief break to find myself as an English teacher in South Korea and then I came back to being a developer. I got promoted to being a director about 2014, actually like the week of that DrupalCon in 2014. And I went from managing a small team of developers to over time managing a much larger team. We went from about seven people when I became the director at CHIEF to 28 people by the time I left and went to FFW. So in that time, I worked with a lot of new managers after initially being a new manager myself and the advice that I'll give you in this talk is a lot of the same advice that I gave them. So if you have just moved into management or you are considering moving into management, by the way, there are seats up front if you wanna be those people who sit in the front. If you've just moved into this, you might be feeling a little bit nervous. You might be a bit unnerved by the prospect of having people's careers and livelihoods whether they get promoted directly in your hands. You might be wondering if you'll do a good job with that very different kind of responsibility. And you might be wondering how you're gonna handle it the first time you hear people complain about the boss and you'll remember that the boss is you. So if you do have these feelings, you might be a little bit like me because this is a dramatic reenactment of my reaction to getting told that I was gonna be becoming director about six months sooner than I had been planning on. A lot of people jockey for this promotion. I did not jockey for it. And in fact, I was actively terrified of it because I knew what a giant responsibility it was and I didn't wanna screw it up. So new managers face a lot of pretty unique struggles. First of all, when you get promoted, you might feel like you are expected to have all the answers. And unfortunately, you kind of are because like in our industry, this is not like a gigantic industry of massive companies usually. There's not usually orientation for becoming a manager. There's not usually a talk where the HR person sits you down and explains to you how it works. Usually the type of training you get to do this is entirely dependent on how seriously your manager takes it. So if your manager wants to talk to you about like establishing healthy boundaries with your team or what sort of management styles work and what don't or the terrifying prospect of giving your first performance review, congrats, like you actually get some training. But more often managers tell you set up some one-on-ones, give them some feedback, it'll be fine, don't worry about it. Oversight is also pretty limited because managers who don't take that initial training part seriously often also don't take checking in to see how it's going seriously. They don't come to you and say, hey, how are you doing? What are you struggling with? And they also don't go to your direct reports and ask, hey, how's Cat doing? They mostly assume that if nothing goes wrong, then it's all gonna be fine. But just because you've got limited training and limited oversight, it does not mean you have limited responsibility because your boss is still gonna expect you to be able to report on how your team is doing and your team for some reason is still gonna want guidance from you. So you have to figure it out pretty quickly and you have to figure it out on the job. So if you do have a manager who's interested in this or a mentor or a friendly HR person who wants to take you under their wing, they might talk to you about two major types of challenges you have to overcome early. And the first is learning how to communicate like a leader rather than like a team member. And the second is shifting your focus from developing code to developing people. So first, let's talk about communicating like a leader. Up until this point, you have been a member of a team. You're probably a pretty critical part of your team, realistically, if you're considering moving into management or have been promoted. You might have even been mentoring the people around you either formally or informally. And to be successful in this management role, you have to accept that your communication style is gonna need to change and your relationships are gonna need to change. There is no magic bullet for getting the promotion, getting the raise, and then still relating the same way to the people around you. So the sooner you think about how you wanna change these relationships and what you want them to become, the better off you're gonna be in your new management role. As a developer, your team relationships tend to be very collaboration-based. You are all in this together. You might be the most senior front-end developer on your team, but you might be working with another junior front-end developer, a back-end developer, project manager, a designer, and you're all pulling together to get the work done collaboratively. If you have input on what people are doing wrong, you're probably giving that feedback pretty indirectly. If you are not the manager, you don't walk up to someone and be like, look, I need you to change how you're doing this. Instead, you say, hey, it would really help me out. If you would think about maybe doing this instead, or if the problem is really severe, you might go to their manager and talk to them about what a person needs to do differently. And finally, those big picture process problems on the team are the manager's responsibility, even if you, as a developer, are providing input on what could be done differently and how the team could evolve. The manager is ultimately accountable for it. But all of this changes when you become a manager. First of all, your relationships become based on your authority. You are representing the bottom line. You are representing the company's performance and you are answerable for the team's work. Your feedback becomes very direct, now you do have to walk up to people and say, look, I need you to handle this differently and you need to be very direct about it. And thirdly, those process problems are still manager issues, but now you're the manager, so that's fun. So as a manager, you get a lot of control over how the team works, and this is really exciting. You get to fix problems at the business level, rather than at the code level. And if you are a certain kind of manager, a certain kind of brain, this is really rewarding for you. Ultimately, teams need people that are willing to say, I know we've been doing it like this for a long time, but it's not working and we're not competitive anymore. So we have to start doing something new. And they need people who are willing to tell them, I know you want this promotion, but in order to get it, I need you to do these concrete things over the next six months to a year. So giving those messages successfully relies on developing different communication skills than the ones that you had as a developer or as another type of practitioner, though I'm gonna focus on developers just wanna know. And you need to find new ways of communicating and giving those messages. So first of all, I like to set the stage, both when I became a new manager and now when I take on new individual direct reports with a transitional one-on-one that goes pretty in-depth about how we're gonna work together. This helps you turn subtext into text because we all come into those new management relationships with these assumptions about how we're gonna work together and what the other person needs. And they're often like dead wrong, speaking from experience. So I divide the transitional one-on-one into two distinct parts. Where first of all, you talk about your vision for the team and how you think the team needs to operate. And then secondly, you talk about what you both need from each other as manager and as direct report. So if you've been part of the team for a while, you probably have a sense of what it's really struggling with and what it's really doing well. And this is your chance to bring that to the forefront and say, you know, as we work together, I really wanna make sure that we are improving our code review process. Like right now it's sort of weak and it's a priority for me to make this stronger. Or to say, right now we're really struggling with this concrete part of Drupal development and our processes keep going off the rails. So I wanna put a lot of focus here. These next two questions are like my favorite part of any transitional one-on-one because you can see people breathe an actual sigh of relief when you start talking about them. Talking about what kind of management styles make you more successful and less successful. Who here has had a manager they really hated? Okay, who's had a manager they really loved? Okay, it's really interesting that the loved is more than the hated in this group. If you had managers that you really didn't like, the odds are that you know why. That there's a particular part of their style that just flatly did not work for you. And if you've had managers that you really loved who could unlock the best in you, the odds are that you've taken note of what they did that you want other people to do as well. So in these, you give the team permission to tell you about them. Most people tell me that they hate being micromanaged, that they hate constant check-ins. But every once in a while, someone will tell me, I wanna be able to bounce things off you regularly. Like I'm struggling with this and it's really important to me to have your ear and to feel like if I am you and say, hey, can I talk this out, you're actually gonna be okay with that. Similarly, some people will talk about how the most important thing to them is the ability to have ongoing advancement and to know where they really are. And other people are really happy where they're at. Like they just wanna come to work and keep doing what they're doing. So part two of this is talking about what motivates them and what their goals are. So your job as a manager is to get the best out of every person that you work with. And this is a lot easier to do if you know what they consider their best to be. If there are particular parts of their job that they really love, parts of their roles that other companies that they really loved that they're not getting here, bringing that to the forefront gives you an opportunity to correct around it. And talking about their long-term goals and where they wanna be as their career advances and even putting a timetable to it, which some people have, give you a sense of what they expect and how you need to help them move forward. And finally, I strongly recommend leaving some extra time to talk about something off script. Like a question that you are not coming to with an agenda. Just asking what is the most important thing you think I should know about you right now? So I've gotten things ranging from, I just had a new baby and I'm struggling with my hours. So I'm working kind of an unconventional schedule but I'm still completely putting in my time to, I really am looking to move up in the next few months. I know where I wanna get and I've been struggling to get there so I really want you to tell me what I need to do differently to people who are concerned about working together in a new role because we had a relationship as peers before and they're concerned about how to make that jump because you know too much about them. So that's how I approach transitional one-on-ones and I can say that while they, you often feel like they're gonna be awkward and you're following a script and you're literally like reading a list of questions, this is the most satisfying way to start out a new relationship because you're not going into it with assumptions like you're afraid of what the other person thinks, you're giving them the opportunity to get it on the table and then you are orienting around that. So secondly, I would highly recommend learning how to use multiple leadership styles and multiple communication styles. You might naturally be a highly democratic leader who sees a challenge come up and then says, hey guys, this challenge is facing us. How are we gonna band together as a team to overcome it? You might be what's called a pace setting leader where you set super high standards and you say, this is the pace we're gonna follow, like let's all get behind it and make it work. Or you might be a coaching leader. These styles are taken from an article, an article taken from a study called Leadership Gets Results by Daniel Goleman. It was from the year 2000, which is a throwback, but management is one of those fields that it's a little easier to take lessons from the year 2000 than it is in say, development. And they studied about 4,000 executives and they took notes on the sorts of leadership styles that they showed, boiled it down to six styles and then noted the effects that all of these had on the team. And the six styles that they identified were these. First of all, highly-affiliative leaders. They care about people. They are the people who will say, like we need to build strong relationships on this team. I see you guys working late. I can't necessarily do what you do, but I'm gonna order a pizza and I'm gonna stay with you while you do it. They often struggle to give really negative feedback to their teams, but they build crazy loyal teams because the teams genuinely feel like they have their backs. Authoritative leaders lay out this vision and then they say, come with me. Here's how we're gonna achieve it. And they motivate people toward a shared common goal. They have a unique ability to figure out what organizations need to do in order to adapt and change and then to motivate people to come with them. And coaching leaders are focused on developing individuals. So they help you figure out how to overcome your weaknesses and how to deepen your strengths. And they work really well when people know that they need to improve and are game for doing that and it really doesn't work if people don't wanna change or if they're like, I'm doing good enough. What are you talking about? Coercive leaders lead through giving orders. They show up and they say, do it. And they expect you to do it. And if you don't, then you can often have a challenge. This style works really well when a team is in crisis and they need to turn around because they're doing something that's been really wrong and really unproductive or unprofitable. But in the long run, it really squelches teams. It like shoves down creative thinking and it can really be problematic. We've talked about democratic leaders a little bit so I'm not gonna belabor it too much. But they, this style can lead to endless meetings and people feeling really rudderless because every time something comes up they're like, guys, let's get a conference room and talk about this. And we've all been in like the two hour meetings, right? And finally, I can hear that we have. Paysetting leaders are the do as I do type. They are often promoted because they are really good at their jobs. They show up and they expect everybody else to be as good as they are. So in this article, Goldman argued that we misjudge leadership styles when we think about them as a function of personality. So I really like people, therefore I'm an affiliate of leader. Instead, he says that we should see them as strategic choices and pick the right leadership style for different situations. So a lot of people do lead on just one style but if you can figure out how to trot out other styles when they're needed, you deepen it a lot. So a highly democratic leader who sees her team struggling should be able to lay out the vision of an authoritative leader and say, let's work together to make this happen and delegate tasks actively rather than waiting for people to pick them up, like tasks at a scrum meeting. A naturally coaching oriented leader who's dealing with a recalcitrant employee who is not listening to feedback should be able to become more coercive and say, I need you to do this if we're gonna be successful here working together. So what I would tend to advise is figuring out what comes easiest to you, like which of these styles really resonated with you, thinking about how to get better at that, sure. But then focusing on the other part, like I naturally am super into coaching. I love coaching people. I'm also a bit of a pace setting leader, so I'm glad I read this article early in my career because it talked about how it can crush a team. Um, awkward. So both of these are focused on raising the standards of how people work together, but both of them can really struggle under certain conditions. So I had to consciously work on my ability to lay out a vision and motivate people toward it and I had to consciously work on my ability to be a bit more coercive when people's performance was failing and give them very direct feedback that we'll talk about in a minute. So when I started trying to pick up these other styles I wasn't as good at, I would spend a lot more time writing out my thoughts and really preparing for meetings beforehand, even role playing with mentors and managers that I trusted. And this ultimately prepared me to be able to switch between them when I needed to in more crisis situations later in my career. And finally, the next part of really improving your communication is figuring out how to have the deeper conversations. Rookie managers are often really nervous about getting vulnerable. They're nervous about hearing something that they're not expecting. So as a result, they sort of skip past this whole level that people desperately need from them. So if you're asking, hey, how's it going? And someone says, it's going fine. Yeah, it's been a good week. And you let that go. Like you have no business being disappointed when they quit later and you weren't expecting it. You have to find a way to dig into what people aren't saying and force those conversations a level deeper than the standard project day to day. So there are three ways that I like to do this. And the first is setting aside one meeting a month to talk about people's goals and their progress from their weekly one-on-ones. So after I do reviews and set up goals and feedback for people, I check in once a month to see how it's going and give them an opportunity to talk to me about more big picture things that have come up for them. I also encourage people to talk about what they're really proud of rather than just the day to day because we naturally come to our managers when something's wrong, right? We come to them because we need intervention or we need reassurance. And that can mean that every time someone comes into your office, they're talking about something that they're struggling with. And it can mean that you wind up losing the ability to really see what they're good at and what is motivating and what situations they shine in. So setting aside time and telling me, I want you to tell me about something that you're proud of, it gets better results in the long run and keeps that conversation focused on what is motivating, not just what is problematic. So finally, if your employees are really unhappy, like just don't run from these conversations. They are really, really important. So I tend to set up conversations after really tough projects to talk about what went wrong and what people can do differently in the future. When I'm not part of the project, this has like no emotional impact for me. When I am part of the project, it is the literal worst. I am the kind of person who is like a textbook overachiever, like psychotic perfectionist. So I can tell you the first time I got a B in school, I can tell you the first talk I gave that bombed. Negative feedback just stays burned into my brain. And a lot of rookie managers are like this. They start like dreading that negative feedback and running from it. And in the process, they become really brittle and fragile and then they fail. Alternatively, they can decide to confront their mistakes, head on, learn from them and adapt them. So on my toughest project, I was managing three people, three developers, and I was also the person who was the team lead. I was overseeing the project work. And the client made a bunch of requests as clients do and Scope started getting sort of out of hand. So Scope was not something that I could directly control, but it was something that really overtaxed the team. So the team started burning out. And then when the project launched, I was like, awesome, we got through it. We're all gonna move on. We're gonna forget about this. It's gonna be great. But the reality was that these three people were still pretty demotivated and they were still, they didn't feel great about starting new projects and we're sort of afraid the same thing would happen again. So I steeled myself. I set up a meeting to talk with them about what worked and what didn't work. And I listened and it sucked. Most of their feedback was about the project, but some of it expressed really like respectfully and it was great, was about me and how there were ways in which they felt like I hadn't protected them effectively or I had talked about the project in ways that made it a little harder for them to do their job and like veered too positive when I should have had the like, okay, this sucks, but we're all gonna get through it together, sort of tone. So if I hadn't had that conversation, I wouldn't have learned anything about how these particular ticks that I had affected my team and also these people might not have recovered. As it was, they all like, we all rallied, we got through it, we did a second phase with that client and then we moved on and they're still at the company now. So I would strongly recommend that you do dig deeper and get comfortable hearing feedback that you don't love because it makes you much stronger and much better as a manager in the long run. So to recap, communicating like a leader by setting up transitional one-on-ones, learning to use multiple leadership styles and having these deeper conversations will really take you a long way in changing your communication from a developer style to a manager style. But that second challenge is starting to develop people, not developing code. So the bad news about developing people is that they're super buggy. They have a lot of variables. They do not do what you want, you cannot Google Dresch commands for them, it's terrible. The good news is that if you have a certain kind of brain seeing people grow over time is a lot more rewarding than seeing functionality grow over time. So as you become a leader in this way, you no longer get judged quite as much by the quality of the solution that you put together. You get judged instead by the quality of the team that you build over time. So you get judged by whether they are doing good work, whether they are growing individually, they're better off now than they were a year ago, whether they are sticking around, like if your whole team quits, it's usually bad. If they as a unit are able to take on harder and more lucrative projects over time, this is a really different set of metrics than does it work and is the client happy. So you have to really think about how you want to position yourself to get these results. And the two things I'll talk to you about are delegating and giving really constructive feedback. If you've been promoted to a management role from a development one, it was probably because you were really good at what you did, probably because you were a solid developer, maybe even a senior developer, and you were probably pretty undaunted by challenges that can really mess with other people's heads. So promotion into a leadership role in some ways is the ultimate recognition of your abilities here. But as Carol Walker's article on saving rookie managers from themselves, which is a catchy title, right, covers, they, managers often fail to grasp that this is no longer about how good they are, it is now about how good the people that they work with are. And they stop looking for, they should stop looking for these opportunities for personal achievement and start looking for the opportunities for other people to achieve. So as your scope expands, you become responsible indirectly for a lot more things. So if you're managing three people and they're on two projects, all of a sudden you're indirectly responsible for six more projects. Or if you are picking up people who are more responsible for other avenues of the same projects you're working on, you're now responsible for more parts of that project. And it's really easy to say, like, I mean, I know this person's struggling, so I'm just gonna tell him how to do it or I'm just gonna do it myself rather than waiting for him to screw it up. And there are a couple of different reasons why you might wind up not delegating it instead keeping this work for yourself. The first is habit. We've covered this, you're a good developer. You wanna keep doing good development work. The second is feeling like you need to perform tasks to demonstrate your value to your manager, especially if you are struggling with a new management role. You might want to work on this really cool project that has a lot of visibility and get the credit for it. Third is what I like to call the group project syndrome. You are afraid that if you give work to the people on your team, looking for a diplomatic way to say this, they're gonna screw it up and then you're gonna get blamed. So instead, you wind up acting like you did possibly on a group project in high school and college where you just keep the really challenging stuff so you don't have to worry about them not having it done at the 11th hour. And finally, the one that I struggle with the most personally, you see that the team is already overburdened and you don't wanna give them more work than they can handle. So you wind up burning yourself out and running yourself into a hole so that nobody else has to burn themselves out and run themselves into a hole. And you wind up asking yourself, what was a weekend and why am I not having them anymore? Why is the janitor always leaving the building before I am? This is based on a true story. So other than your sanity, there are some compelling reasons to push through this and figure out how to delegate and delegate well. It helps each member of your team grow. It increases their job satisfaction to feel needed and valued. Like if you only get the easy assignments and someone else keeps the hard ones, it's not hard math to realize you're not valued and that you're not trusted. And if someone is giving you those challenging pieces and trusting you to run with it, in the long run you feel much more like a vital part of this company. So those two things together lead to more retention, which is good, cause then you don't have to retrain a bunch of people. And that scales the work that your team can do over time, giving them room to expand beyond just what you can micromanage and instead act independently and take on more than you ever could have been involved with yourself. So these are all good reasons to retrain your brain from, it's gotta get done right, so I'm just gonna do it, to, that sounds like an awesome opportunity for Alice. Like she's been, these projects convince me that she's gonna do well with this task, so I'm gonna let her run with it and give her this opportunity to achieve rather than taking it for myself. But if you want to do this, but you're still saying, hey cat, like that's really great in theory, but in practice my team can't handle the same kinds of tasks that I can, this is what I recommend for delegating responsibility without just delegating any insight into the project. You do have to start out by delegating, this is not negotiable, just do it. You then have to set milestones for check-ins. So for some tasks, this might be once it's completely done and you're ready to release it to prod. For other tasks, it might be once you've met with a client I want you to come back and talk to me about how you're planning to address it and for others it might just be part way through. But at those check-ins, you need to meet with your team members and have them present their work to you rather than you like looking at their code or looking at their tickets and asking them questions. The point is to get them taking responsibility for presenting to you rather than you taking responsibility for dragging information out of them. And then you correct just the critical problems. It's not a big deal if they do something differently than you would if it's not meaningfully like a problem. So you only wanna focus on what they really need to know. And then you answer the questions that they have. But I will note that when I started out, people were coming to me and asking questions and I was just answering them as fast as they could ask them. And now what I say more is, what have you tried so far? And have you tried Googling that? To train people to come to me when they are a little bit more sure that what they're dealing with is something they need help with, not just coming to me so they don't have to put in the creative thinking themselves. And then finally, if they've done great, tell them that. Like there's nothing more rewarding for people than hearing, you did awesome with us when it's something that they have struggled with in the past or just when they're overachievers and they like to hear it. So this process taken together helps the people who work with you hone their critical thinking skills and their presentation skills. And it also keeps you aware of how tasks are really going until you're ready to take the training wheels off and say like, you've killed the last three projects that we talked about, you can just run with us. Like you don't need to brief me on it, just go. And that's a really fantastic feeling, especially if you are a coaching leader. So now we come to the second skill and the last one we'll talk about because it's the biggest. Giving constructive feedback. How many people here have done a performance review? Have given a performance review? So you've probably had that moment when you are having to tell someone, this is really like, you really need to improve this. And sometimes you've even had the moment where you're saying, you really need to improve this or we're gonna have to let you go. These conversations are not fun. There is really no way to make them fun. But what you can keep in mind instead is that being nice about what people need to work on is not the same thing as being kind to them. If I could go back in time and talk to my 2014 self, this is the advice that I would give her because at times when you, as a developer you're lacking authority over the work of the people around you and you lack responsibility for their career. So you don't get to control whether they get promoted, you don't control whether they get laid off. You can give feedback about their performance but you don't ultimately act on it. But as a manager you do. You are usually the person determining when people move up. You are definitely involved in conversations about when it's no longer productive for them to be at the company. And if you aren't giving that feedback really directly to the people in question, then you're robbing them of the opportunity to course correct or to move up to say, if they don't realize that all they had to do to move into that senior role they wanted was to correct the way they're communicating with their peers, just tell them that and then they can figure out how to move forward. So I like to make sure that performance feedback meets all three of these criteria. First of all, that it is really direct. You shouldn't be trying to figure out what your manager's telling you, it's important. That it is balanced so it's taking into account both what people are really strong in and what they're weak in. If you're telling someone, this has been a problem on the last few projects that you've done, I really need you to work on it, it's a very good idea to balance that with you have picked up these skills so well and I apply some of that to this problem as well. And if you're the kind of person who gives positive feedback, negative feedback more naturally, you also need to take time to really make sure that you're balancing that out. And finally, it should be thoughtful. Don't toss out proclamations about people's performance off the cuff and expect them to take it well. Don't tell people, your attitude's really gone downhill. I need you to work on that. And then get surprised when they ask you, can you give me an example of that? Come prepare to these conversations and think about what they're gonna say before you actually give them the feedback. So if you, it may be helpful for you to mentally rehearse some of the tougher conversations you're about to have. When I was starting out, I would actually script like the opening paragraph of what I had to tell people. And if it's harder for you to react in the moment to management challenges, which like it would be if you're new, then there's really no shame in doing more over preparation to make sure that your feedback is thoughtful. So most importantly, you have to take out the guesswork. If you've had a manager you really hated, you probably hated them in part because you knew that they, you weren't quite doing what they needed, but you didn't know how to fix the problem. You didn't know what you could demonstrate to them that would meet the criteria that they were laying out for you. This leaves people feeling really paranoid and really insecure about their job performance. So by being direct, balanced, and thoughtful, you might not always be saying something people wanna hear, but you can make sure that they know what to do with what you're telling them. One way to make sure that the feedback meets these criteria is to prepare your reviews with a really holistic perspective. I like to reach out to people's peers in addition to providing my own feedback. So I start out with my outline of their major accomplishments and the major things that they're struggling with, and then I talk to their project managers, their fellow developers, people that they're mentoring or who are mentoring them to get more of a 360 degree view of their feedback. In my opinion, companies that take this feedback anonymously and then put it in people's reviews anonymously are doing the worst of all possible worlds because then you're seeing in print what people like or don't like about you, but you lack context completely. So what I do instead is I review and validate the feedback that I get from people, and then when it's positive, I put it in there with attribution. So if, for example, Alexis has been doing a fantastic job, which Alexis always does, by the way, then, and Sam tells me that, then I want to take the time to actually write down, here's the feedback Sam provided, like you did a really great job with this and it made her job much easier and better and have Alexis get to see in print that her work is validated and appreciated. And on the other hand, and this should not need to be said, I'm gonna say it anyway, don't put quotes from people about what other people are doing wrong in their reviews. Just don't. Like anytime someone tells you that a person is struggling with an aspect of their job, it is your job as a manager to figure out how to make that actionable and constructive and to validate whether or not it's actually true. You do not get points for saying some people say that you're hard to work with and not explaining it given context or saying here's what we need you to demonstrate differently. So I have gotten really helpful feedback through this process. First of all, I've gotten people telling me that someone who was like a really great communicator was really struggling with their development work on projects and that the team was struggling to make up for it. I've had people also say that folks whose work I didn't value enough were doing an incredible job on taking the load off their team leads in a way that I wasn't aware of because I wasn't on all their projects. So this helps you get a much more holistic picture of how people are actually doing. And how you present it is actually really important too. I like to start out with feedback on people's accomplishments and then set goals collaboratively with them. So they tell me what they're interested in in the next six years to a month and then I define the success criteria for each of those. So they know when they've actually achieved it and we can review their performance in the next review. I talk about what they should start doing either because if you start doing this, here's how you can move up and here's how it can affect your career positively or because they should have already started doing it and I need them to pick up that responsibility. And then what they need to stop doing, this is self-explanatory, it's corrective feedback, stop doing it. But I also talk about what they need to continue doing and make sure that I end it in that way so that it goes positive, negative, positive and ends on a note of looking forward to the future, not a note of here's what you need to change. But of course, just don't wait for reviews to give feedback. Again, this is something that I would tell my younger self if I could. Conversations are pretty hard to have during one-on-ones and they feel a lot less official because you're not giving printed documentation but it's really critical to have them frequently both because then people get to respond to things and provide guidance, provide context in the moment. Like I know that the designer said that I was being difficult to work with but here's the actual situation. And because they get used to hearing performance-related feedback from you at regular intervals and they don't have a giant backlog of things that you need to talk about at the end of the year when the employee is coming to you saying hey, I've done a great job and I wanna raise. So developing people, again, the things that I would advise you to focus on are learning how to delegate and providing that oversight rather than either not delegating or throwing things into a box and expecting people to run with them. And I would also say that giving constructive feedback is one of the hardest strengths to build but it helps you improve the performance of your team pretty dramatically over time. So looking forward after you have really gotten to handle on these critical things, management is a really rewarding place to be. There's a lot that you can accomplish and there's a huge impact you can have compared to being an individual contributor. These skills set you up to make sure that you understand the effect that what you're doing is having on morale to make sure that you can make changes when you need to. So for example, I had a situation with my team where a new manager had had a problem with the same problem with two different people a couple of weeks apart and it had impacted client work. So I talked to the manager about it. She took responsibility for it and she sorted the problem out but then she came back to me and said, honestly, we've grown too much and I'm managing too many different types of people. I'm managing developers like technical strategists, technical managers and I'm struggling to get the right feedback to the right people and make sure these lessons are self-reinforcing. So I wound up reorganizing the team so that people managed the people who had expertise in what they were also doing. So WordPress developers managing WordPress developers, Drupal front-ends managing front-ends, Drupal back-ends managing back-ends and this created like concrete practice areas so that people could share knowledge more effectively and it wasn't relying on a manager to give top-down feedback every time. Those kind of big changes have a huge impact on the team but they only work if you have these essential communication styles upfront and you've already created this trust with your team. And finally, this helps you build a self-reinforcing team that can run itself and sustain itself without you. So setting key values, setting a mission, making sure that people understand how you judge quality, makes them more able to understand how their work impacts the team and to react to it when they or other people make mistakes. And this means you actually get to enjoy weekends occasionally, which is great. So I'll leave you with this quote about what great managers do. They look for what is unique about every person and then they capitalize on it. They realize that their people are not interchangeable, they're not uniform, it's not like playing checkers, it's like playing a pretty complicated game of chess and their ability to communicate clearly, to swap leadership styles, to deal with different metaphorical pieces on the board and their ability to monitor performance and make changes when they need to can lead to really big results. So I firmly believe that good management is the single most rewarding thing that you can do with your career and I wish you guys luck as you also do it. So thanks for your time and attention today. If you like reading about these concepts, I highly recommend the things over here on the right, especially the Harvard Business Reviews compendium of articles on managing people. You can find me at Webby Cat if you want to, again, nerd out about any of this and I'm really happy to take questions now. Can you anyway, because it's being recorded? So everybody back home can hear. We're gonna do this as a webinar for Drupal Forgot. So if you've missed any of this, we'll make sure this is possible and out there for everyone else. So she can answer your questions online. I believe I've just been voluntold. Do you have any suggestions or tips for a manager on a very small team that also needs to be a developer at the same time? I do. So first of all, for managers who are on smaller teams and are developing, I would say the really important part is figuring out what you can delegate and what you can't. If you are a manager of a small team and you're working with a couple other junior people, the way that you build them up over time is fundamentally different from if you are working with two other senior people. So that sketch of giving out tasks while still providing oversight becomes really critical. I would also argue that you get to know the team much better over time so you really understand what they're good at and what they're not and you're able to counterbalance. So if you're working with, if you are a backend developer and you're working with two people who are stronger in front end, it's okay to take on more of those backend tasks initially and then gradually release them over time to build people up. I'm curious about whether that answers your question. Okay. So if you work on a team and you have several stakeholders that are requesting things from that team, how would you recommend coaching them or helping them to work with those stakeholders? Because I know that that can get overwhelming for them sometimes. So I'm just curious as to how you would recommend coaching them to work with them. Do you mean like people going directly to developers rather than going through a project manager? Yeah, exactly. Gotcha. So first of all, we get a project manager. Yeah. But I would, I found the most important thing for that is building empathy on both sides of the fence. If you have access to talk to those stakeholders about the challenges that your team faces, like if they're actually part of your company, for example, and talking about, hey, if you can handle this in a more official process, like if you can file tickets rather than finding someone and calling them, then we can respond to you better because we have the opportunity to put that into a more normal workflow, first of all. But if you just don't have that option and you need to get your team comfortable with hearing that, getting stakeholder questions thrown at them, talking to them about what the stakeholders are facing and really building that so they understand what they can do with their input is valuable. I find that initially people are more likely to throw out like, yes, I can do it or no, I can't do it. And they can get very defensive or they can get, they can over commit to way too much. So talking them through, when you say that you can handle something and you can't, here's the impact that it has on the stakeholders. Here's a concrete time that this has backfired on our team or when you say you can't do it and you actually can, you reduce the trust and you make it more likely that they're gonna micromanage you later. They're gonna constantly come back. So I think that walking people through the practical consequences is helpful if you can't get that in a more normal process. Any thoughts or tips in a situation where a lot of the normal manager roles are not present? So for example, large organization where you don't have any say over pay, over promotions, over raises, things like that, where it's all an organizational formula that you don't have any say over. Is your question how to motivate people? Or just any thoughts generally on, people ask about things like that. A lot of the advice on how to answer those questions doesn't really apply. So I would recommend, if it's that you aren't in control of the folks, the livelihoods of the people below you, you have to have more conversation with the people above you. Part of what I would recommend is talking to the folks who do make those decisions about the effect on the team of if it is that people are concerned because they're staying stagnant for a really long time and there is no upward mobility for them or that the pay is staying stagnant and they feel that they can get better paid somewhere else. I found that having a practical conversation with the leadership about the effect of having to hire someone new into that role will go a lot farther than you think it will. So I usually start there. And then secondly, working with people, in those conversations with leadership, having conversations about what would have to happen for them to be comfortable making decisions and then being armed with that knowledge when you talk to the folks below you, that's also helpful. If the answer is there is no way for this team to move up and improve, then it's good for you to know that because the odds are that you're gonna have to shift to a model where you are accepting a certain amount of churn and burn or people are gonna cycle in and out and you're gonna perpetually have to invest money in training. And having an organization see that play out can really make changes in how they mentor and recruit talent over time, but in the moment it is a really hard challenge. With all that said, once you have a sense of what people have to do differently to impress leadership, you can have more productive conversations with them and you can also talk to them practically speaking about what they want out of this job. Like if you can't move up from developer to senior developer, what do you wanna leave here ultimately having known? What do you wanna get better at as a result of your time here? And then you can work with them to improve their skills over time rather than working to retain them forever. Thank you. That's a good question. So given that these promotions can sometimes be competitive. Do you have any tips on how you handle someone you were competing with and how you smooth things over because you're now their boss where you were their teammate before and how you prevent them from totally resenting you? Oh, I have no feelings about this. Oh, God. So the transitional one-on-ones really do help because you can get some of that subtext out there. So for example, if you are dealing with a super process-oriented developer who maybe didn't have the vision to lead the team but who has a lot of really good skills that they bring telling them I value what you're doing here and I wanna make sure that I can continue supporting you in doing it. I know this is gonna be a bit awkward but I wanna figure out how we can make this working relationship as good as it can possibly be because what you bring to the team is absolutely essential. That goes a long way. I would also say new managers often feel this pressure to have all the answers with their team and to charge forward saying this is what we should do and I know it's what we should do and consciously training yourself to look at this person and say, here's what I think, what do you think? And making them an ally in your leadership rather than someone that you're perpetually fighting with can also really help. Especially if they are also kind of overachieving, them feeling heard and feeling like they're still able to have an effect on the team and their team themselves up to take that position in the long run can make them more receptive to working with you. In terms of fostering that kind of mentoring atmosphere and good management atmosphere too, this question kind of has many implications potentially but what is kind of like a rough number of how many employees you might see as under you as a manager, as an ideal kind of ratio? Like there's some range and what? This question is so good. Do you mean in order to mentor people, how many people can you mentor before you tip over or do you mean how many people can you manage before you tip over? Right, if we're talking about developing people rather than code, how many people can you successfully develop without failing at your job? It really depends on how much development they need. If you are dealing with a very junior team, I would not personally, I don't like having more than two, maybe three really junior people at once. And I currently am pretty far along in my career. I feel good about my management skills but if you saddle me with a team of like seven people who are all trying to learn their job, there's no way for me to be successful in that because I have to pay too much attention to each person. When I first got promoted to director, I would say that number was closer to one. One maybe two if they're really well motivated. So that said, if people are pretty solid at their jobs and they just need minimal communication and minimal feedback occasionally, you can do a lot of good mentoring people in relatively little amount of time if they're already mid-level. So I would recommend thinking about how much work these individual people are saving you and then trying to back that out of your time. So for example, I once hired someone who was a little bit more junior at the time and they were worried about taking up too much of my time and like they came to me with questions pretty regularly and I wound up telling them like, if I spend 10 hours this week talking to you but it saves me the 40 hours this week I would have spent doing your job, we're still good. So if you can draw a line between how much your day-to-day responsibilities need you and how much time you have left over, it helps. And just one quick follow-up question. Is it, because this talk is going from developer to manager, is project management a crucial skill set that's needed or is it possible to move right from developer to that more managerial role? I would definitely argue you can go from developer to more managerial. As long as you have a strong project manager to keep like the trains running on time, I definitely don't think you need to be a project manager to be a strong team lead. You definitely need to be a project manager too. Sorry, just an opinion. I really liked it but I'm a little bit in doubt what the bounds are of what you're talking about. Is it culturally, geographically, as a manager of remote developers from maybe eight or 10 different cultures, there's many things I would like to poke hole in what you're saying. So could you say something about this? This is maybe a US centric thing, especially the hierarchy. The hierarchy you're talking about in an organization doesn't work in circular organizations for instance. That's very true. I would definitely say this is a US centric talk. I have for the most, almost entirely, managed folks who are based in the US with a couple exceptions. So the way that I see managing people, it is very driven by people who want guidance but who also want some independence as opposed to cultures where it's much more based on deference and respect and you're not gonna get that sort of honest feedback unless you've worked together for years. So I do think that people who are managing an international team have a very different set of challenges. I'd argue that a remote team that is culturally similar, a lot of this does apply. But I think that's a great way to look at this. I'm sorry, if I can just follow up. How would you then apply culture to try and cultivate? Now I really, really wanna give a talk on that. I wish I had a good answer for you on that but since it's a challenge that I haven't faced myself, I would hesitate to give you feedback on it. I do think there's some great articles about that that I'd love to share but I'm sorry, I'm not gonna be the person to tell you that one. As a manager who was originally more of a generalist, I now am in charge of a team with extremely specialized, highly intelligent people that know much more about their subject than I do. Do you have any recommendations for that situation? I would tend to recommend that's one of the styles where a democratic leadership style works pretty well. Coaching doesn't work great, authoritative doesn't work great but recognizing what those people bring to the table and then being more affiliative and more democratic helps. Having a servant leadership mentality where you say I'm here to help you be successful, I wanna hear from you what challenges you faced in this organization and I wanna talk to you about how I can make them better as opposed to I'm gonna give you instruction and you're going to go follow it. It's a subtle paradigm shift but it's essential for a team like that. I would recommend the On Managing People book, the first article deals with that and I think too many bosses, too few leaders also gets into it but it's a really great article on what to do when with high performing teams. Cool, thanks. Any recommendations or how to survive through a company inflection or organization change? So my company is going from a flat organization to a more structured with project managers and onboarding new people. We've grown tremendously over the past year or so and so people are really confused but also the vision and the strategy of the company isn't clear yet. So we're trying things and testing things out. Any recommendations on how to approach that with different leadership styles to kind of help through that inflection point? Has your team been there long? Do they understand the old company well? They, yes they do. They understand the old company well but the new company hasn't been established yet because we've hired a lot of talent and we're doing a lot of projects and trying to move from a production house into a strategic more mechanism, does that make sense? Ah, that does, that makes a lot of sense. I've dealt with something similar. How much access do you have to the people who are determining what the new company is gonna look like? A lot of access. So we've been meeting with them regularly but as we're testing out new strategies and changing, so something basically changes every week or every month. Right. So it's kinda like, well, what? Like we said we were doing this but then it's changed to this and then oh well it's gonna change for this so I'm gonna have like a poor attitude about it type of thing. So ordinarily I like talking about how to keep people happy and how to retain them. In this particular case I would tend to say that you have to accept that there will be a certain amount of attrition. Like there will be people who don't see themselves in the new company or who don't have the patience to make it through that. I think the sooner you accept that your goal is to take the people who are willing to get in line and to wait and to have like the attitude of being comfortable with waiting for some of that change, the better off you wind up being. But that said, for those people, I would recommend talking with them about the major concerns that they have about the organization. If it's that they feel like they don't know how their performance is gonna be judged, then making time to talk to the people who are leading the company to say I really wanna talk about performance reviews. This is how we've judged performance in the past. Can you tell me if it's gonna stay similar? And then either being able to say right now we've got commitment on this, it might change in the future, but we're gonna continue as a team working toward this until we hear otherwise. Or if they're really worried about, I knew how to develop successfully in the old structure but now we're introducing like code review and we're using version control differently then, based on true story, then making it clear to them that as you do add new parts to their job, you're gonna give the coaching to them necessary for them to be successful and really committing to that. Like that's not just words, that's making sure that you identify the high performers who can figure out how to be successful in the new model and then you set them up to do more training with the rest of the team. I hope that helps. Focus on basically company culture and then focus on probably growth plans or something for those people that are willing to stay in this culture. Growth plans are super helpful. Like laying out, right now we've been doing it like this, we're going to add in these new skills, here's how we're gonna get there, setting up like lunch and, well lunch and learns are evil, but setting up meetings not over lunch to talk about how to do something new and have the team start providing training to each other so you marry like the high performers with the lower performers also really helps. Okay, thank you. Good luck. So with that, I'm gonna wrap up. I would also like to put in a quick plug for GovCon. If anybody here is in the DC area or can be in the DC area, there is a camp coming up August 22nd to 24th. This is gonna be right outside DC and Bethesda. It's a three day camp, it's 100% free and the sessions, we also have brochures over here. The session submissions open today so if you want to submit it yesterday, so if you want to submit a talk you can and you can also now register to attend. So sign up because the wait list for this one does fill up. Thank you guys again for all your time. Enjoy the con.