So you have your development team, you understand their positions. You set up a healthy, productive general environment around them to exist in. Now it's time to talk about the day to day and week to week steps that you need to take an active interaction with each of them. So let's talk about the very beginning of a new developer's time at your organization. And before a new dev joins Tighten,

of a new developer's time at your organization. And before a new dev joins Tighten, the first thing we wanna do is make sure that they have all the physical equipment they need to do with their job. So that starts with a laptop. I've chosen MacBooks for everyone, although we do have a few devs who opt into Linux. We set a general price range for what we expect those laptops are gonna cost.

We set a general price range for what we expect those laptops are gonna cost. But then the developers can ask for different specific configurations of certain things as long as it falls within that price range. And it makes sense that if somebody else is gonna have to adopt this laptop, it's not gonna be completely crazy configuration. Occasionally a developer will bring their own machine and that's fine.

Occasionally a developer will bring their own machine and that's fine. We don't require people to maintain a work and a personal computer. Um, I understand why you might wanna do that. Um, because you know, if you fire somebody, you're not gonna give them three weeks to get all their work off the machine. But we're not in a state where I have to be really stressed around that.

But we're not in a state where I have to be really stressed around that. Um, even if I were to fire someone, I would still say, Hey, your passwords don't work anymore, but you have a week to get me the machine. Get all your personal stuff off. And that's often everything when people first get set up. But occasionally they need help setting up, uh, an office that's actually good for their, you know, physical self. You know, they might need an office chair,

that's actually good for their, you know, physical self. You know, they might need an office chair, which we encourage them to buy refurb or sometimes they need a desk, which we help them buy affordably. Or sometimes instead of setting up their personal office at home, we help them with the membership to a coworking space. And because we're not paying for a physical office, I'm not so bothered by the cost of individual coworking spaces

And because we're not paying for a physical office, I'm not so bothered by the cost of individual coworking spaces or individual, um, you know, chairs and things. 'cause if I had a physical office, I would be paying that for everybody and it would be costing a lot more on everyone's first day. Every dev is scheduled for an onboarding call. And that onboarding call is usually at least two calls. There's one with our people operations manager, which is basically our hr,

There's one with our people operations manager, which is basically our hr, but often they also do a call with some kind of a technical lead where it's me or it's Keith, our director of engineering, or maybe just one of the technical leads, lead programmers. We get 'em a copy of our handbook, which I doubt anybody reads the whole way through, although I'm sure I'm not supposed to say that legally. But also we have a programmer's handbook,

although I'm sure I'm not supposed to say that legally. But also we have a programmer's handbook, which is the much more practical, here's how we do code styles, here's what tools we use here to prep. It's sort of like the, the early version of those, you know, claw.md or uh, cursor.md files that tell a an AI how to, how to code. This is a much more robust one that's meant

that tell a an AI how to, how to code. This is a much more robust one that's meant for actual human beings and I think most people read that one. Um, from there, my top priority is to make sure that they are as in as possible as early as possible to the day-to-day operations of the company. So we want them to be assigned to a project even just as a shadow. We want them to be per programming so they can kind

to a project even just as a shadow. We want them to be per programming so they can kind of see what our coding is like. But they can also build relationships who are not with people who are not in leadership. They wanna meet people who are not meet so they can have like comfortable casual spaces to learn on the job and get a sense of what being a tight-knit developer is really like.

and get a sense of what being a tight-knit developer is really like. I do wanna make a quick note about creating an environment for productive development. The majority of the things I think belong in the question of how to manage developers. We've already covered in how to set up a healthy developer culture, how to set up an environment for maximum developer productivity and even how to structure the positions of a dev team.

to set up an environment for maximum developer productivity and even how to structure the positions of a dev team. Managing developers is about managing people and it's about creating an environment and expectations for their flourishing, for their growth, for their productivity. So I would definitely recommend checking out those videos because I think that managing developers well is more about setting them up for success than it is for building structures and organizations.

setting them up for success than it is for building structures and organizations and systems for managing them. That said, there are pieces we can focus on for how to effectively manage our developers. There are some systems that we can build. So first let's talk about how to track and encourage developers' growth. I wish I was someone who had some really deep and intricate systems for managing my developers' growth.

I wish I was someone who had some really deep and intricate systems for managing my developers' growth. And I can tell you the magic 1, 2, 3 formula and I, I don't, but I can tell you what I do. First, I try to make sure I get to know the people who work at Tighten, especially when they first start there. I wanna get to know them through the application process in those first few weeks. So that means from day one, I have an understanding of where they're coming from and where they're heading.

So that means from day one, I have an understanding of where they're coming from and where they're heading. Including what motivated them to join Tighten in the first place that often kind of lines up with their career goals. Then twice a year we check in to ask among other things, what do you want from your job at Tighten going forward? And what are you trying to do with your career? This helps me understand their higher goals. Are they trying to be a LeadDeveloper?

This helps me understand their higher goals. Are they trying to be a lead developer? Do they wanna start a product company one day? Are they just focused on learning specific tasks and specific skills? Right now, at the beginning of the company, I was able to hold weekly one-on-ones with all our devs. But at this point, my one-on-ones are with my senior leadership team and Keith, our director of engineering holds one-on-ones.

with my senior leadership team and Keith, our director of an engineering holds one-on-ones with each individual developer. But somewhere, someone in your organization needs to be checking in all the members of your team regularly, probably weekly. And those one-on-ones aren't specifically for the benefit of leadership. They are helpful to um, you know, understand that the dev is doing well,

They are helpful to um, you know, understand that the dev is doing well, but they're not to run some specific type of agenda. They're more for creating a space for the developers to be heard, to plan and to express their own goals and to ask for help. And while one-on-ones are a great opportunity for mentorship, they're not the only one I would definitely recommend aiming to add other mentorship opportunities, whether formal or casual.

recommend aiming to add other mentorship opportunities, whether formal or casual. Uh, for example, having a lead on every single team gives a focus for the people on the team to have someone ask questions of uh, someone they can look up to, someone that they know is actually kind of looking out intentionally for their growth. Um, but one of the things we also do in one-on-ones is identify people.

Um, but one of the things we also do in one-on-ones is identify people. And in our annual reviews buying reviews is to find people who are explicitly looking for mentoring and find other people who are explicitly looking to offer mentoring and making sure that we pair them up together. And speaking of pairing, even when it's not explicitly a sort of mentory pairing, just any kind of pair programming even across different

even when it's not explicitly a sort of mentory pairing, just any kind of pair programming even across different projects is incredible opportunity for developer growth. And it's not always just the juniors learning from the seniors. It can often be across, uh, you know, ability levels, uh, because people have different experiences and different approaches and have tried and experienced something different. Much of the ways that we support our developers' careers

and experienced something different. Much of the ways that we support our developers' careers happen in the ways that I was just talking about. But there are some other things you can do as well to support their careers. You definitely wanna make sure your team has access to all the best learning materials. So books and video courses and conferences and other opportunities to grow. We've got a library of books we've purchased in video

and other opportunities to grow. We've got a library of books we've purchased in video courses and everyone on the team has access to a LaravelCast account and attends LaravelCon every year. And that's great for learning, but we also wanna help their careers advance in other ways. So we're gonna encourage our developers to speak by holding internal lunch and learns and we're gonna help them apply to meetups and conferences. We're gonna encourage them to write by making space

and we're gonna help them apply to meetups and conferences. We're gonna encourage them to write by making space for them in the Tighten blog. And we're also gonna support them and encourage them to stream, to build tools publicly or do whatever else is interesting in them by giving them 20% time every week to work on things outside of their assigned client work. And those things are all really valuable for the advancement of their careers, both in terms

And those things are all really valuable for the advancement of their careers, both in terms of their development abilities, but also in terms of people seeing what they're doing out there. 'cause people's public reputation is often very valuable for developers' careers and it's good for us as well to have our developers doing things out there. I mean like, uh, we've often had clients come

to have our developers doing things out there. I mean like, uh, we've often had clients come and say, Hey, a quarter of the Ric Con speakers this year are from Tighten, so you guys must be doing something right. It looks great for our clients, but I also just want my developers to succeed. I want them to achieve their goals and I'm honored to be a part of their stories. And we all get the chance to see these people

and I'm honored to be a part of their stories. And we all get the chance to see these people who we see enough potential and to obviously be a part of our, our company, of our organization. And so we should also want them to see some benefit other than just a paycheck. Like how can we help them move further in their careers? And whether it's within our organization or not, it's still an awesome thing to do.

And whether it's within our organization or not, it's still an awesome thing to do. I've spent most of this episode and honestly most of this course talking about how to make things go well with the assumption that if you do it right, it always will. But unfortunately for some reason things can eventually go south. Very few people never have a problem with one of their employees.

Very few people never have a problem with one of their employees. So hopefully you've hired well enough that when things go poorly, it's not intentional. But even the best hiring can't save you from some issues at some point. So when you have an issue with the developer, it's best to get the information you need to address it and then address it head on right away. The longer it takes, the bigger it builds,

and then address it head on right away. The longer it takes, the bigger it builds, the more resentment there might be. The more opportunity for miscommunications. If a developer isn't doing their job well or they did something they shouldn't have, you need to ask around as quietly as possible to as few people as possible to get what you need to learn from a context. And maybe that, that you don't have to do it all, but either way directly bringing it up either on their next

And maybe that, that you don't have to do it all, but either way directly bringing it up either on their next one-on-one or just take a call right then if it's bad enough. Nine times outta 10. If you have a healthy culture, they'll be honest about it. Sometimes it's something they're aware of and they even agree with. You work together to find a resolution, whether that's a change in their assignment.

You work together to find a resolution, whether that's a change in their assignment or working together to build support structures for them to grow in this thing. But if it's a big enough issue that they need some, if it needs a formal structure around ensuring they grow or if they respond in a way that makes you worry that they're not taking it seriously, or if you ask them to change this thing before and now they haven't, it's time for a pip.

or if you ask them to change this thing before and now they haven't, it's time for a pip. A PIP is a performance improvement plan. Now I know PIPs have a bad reputation on the internet. There's a lot of jaded folks who will tell you if you got a PIP, it's really just your employer finding a way to excuse firing you a little bit later. And I don't wanna say that's not entirely untrue. If you give someone a PIP, there is a baseline note

And I don't wanna say that's not entirely untrue. If you give someone a pip, there is a baseline note that they have to improve something and if they don't, they're gonna get fired. Yes. But a pip given in a good spirit is given with the intention that they understand what to change, they change it, they keep working there, you forget it ever happened and everything's good. So let's talk about what a pip actually is. It's a set of changes you wanna see.

So let's talk about what a pip actually is. It's a set of changes you wanna see and a given timeline in which those changes need to happen, usually agreed on together. Um, accompanied by often actions that they should take in those directions. And often intermediate check-in points. So let's say it might be something like you need to improve in these two ways, in these three months. We're gonna check in once

to improve in these two ways, in these three months. We're gonna check in once a month to make sure you've done it. And here's four steps I think you should be able to take that will allow you to do this. So you're not just kind of throwing it on them saying fix it. You know, you're helping out with that. You build the document together, although obviously you're the primary person building it,

You build the document together, although obviously you're the primary person building it, but you need to make sure that they can see it, they understand it, they agree to it, and then you check with them regularly and evaluate their progress at the end. And hopefully it goes well and you forget this ever happened. Now things are really bad when you have to either fire someone or lay them off.

Now things are really bad when you have to either fire someone or lay them off. The difference, at least in American terminology, is that firing someone means they're at fault. Uh, they're going to leave and you're gonna put somebody else usually in their place. Whereas laying somebody off or I think in other cultures they call it making someone redundant means the job no longer exists. And as an unfortunate side effect,

redundant means the job no longer exists. And as an unfortunate side effect, that means this person does not have a job anymore. But there's a huge difference in the motivation and the implications of both. So first of all, if you lay somebody off, you need to work hard to ease their transition because this is not their fault, right? Give as many weeks as severance pay as you can. Reach out to your networks.

This is just a simple explanation with no code.

This is just a simple explanation with no code.

by having a hard conversation and then cutting off the bleeding. You know, be ready to remove access to anything vital in case they decide to get upset and break things and have all your paperwork ready. 'cause if you've gotten to the point where you have to fire someone, things are really bad and it might be their fault, it might be your yours, it might be both, but regardless it's bad. So rip off the bandaid, regroup 'em on the other side to see

it might be both, but regardless it's bad. So rip off the bandaid, regroup 'em on the other side to see what you could have done better and move on. Okay, let's end on a more positive note. What about when your team is doing especially, well first they should be hearing about it. It doesn't cost anything to tell 'em on one-on-ones or their inner annual reviews or just an everyday conversation that they're doing. Well, at Tighten,

or just an everyday conversation that they're doing. Well, at Tighten, we also have a channel in our Slack called Kudos, where a, which a former team member Marge, created for us with the express purpose of highlighting when somebody does something really well. And it's such a joy to get mentioned that channel, especially because at that point you always see all the emojis responses to that pile up. And because of we're goofs

emojis responses to that pile up. And because of we're goofs and we, a lot of custom emojis, half of them are just gonna be a history of years of custom emojis built with your face in them, you writing, you know, a, a cow or you with a silly hat on or whatever. And it's just a great time to celebrate people for their contributions to the company. And another way to celebrate your team is to go all out when you're together in person.

And another way to celebrate your team is to go all out when you're together in person. I love our company on sites. We do it once a year. And one of the reasons is because I get to completely imply, apply my team with swag and food and drink and experiences and whatever else. And it is such an incredible and enjoyful way to use the company's money to thank the people who are an absolutely vital part of that money showing up in the first place.

to thank the people who are an absolutely vital part of that money showing up in the first place. If you have any kind of a public persona, also be sure to share the shine with your team members whenever they get a chance, because usually you are, if you're that person, you kinda have this public space and people are, the rest of the people are just kind of like the people at this team, right? Um, but it's really great to be able to start saying, Hey,

of like the people at this team, right? Um, but it's really great to be able to start saying, Hey, I was working on this thing and Gear or Mo helped me with this. I was working on that and Tony helped me with that. I was working with this and Marcy showed me this really cool new idea and it, it doesn't cost you a thing. And finally, if you can get budget, it's really nice to send little gifts here or there. Maybe it's a pizza party, you know, once a quarter.

to send little gifts here or there. Maybe it's a pizza party, you know, once a quarter. Or it could be the gift that you give at the five year mark or the end of year bonus, whatever you have poll to do to let people know that they're really appreciated. And there's a ton more that goes into managing developers. This could be an entire series on its own, but between this and some of the earlier videos about creating healthy development cultures, I hope you've got enough to get started.

development cultures, I hope you've got enough to get started.