How to Build a Dev Team - 3 Hour Course

Hey, I am Matt Staer and I built an incredible team of developers at Titan. My goal here is to teach you how to build or improve your dev team. Working through things like how to create a positive and productive dev team culture, how to hire and manage developers and where to place them within your team, how to exist as a dev team inside your larger organization, how to manage other leadership logistics like estimation and finances and more. So, let's jump in. So when my business partner Dan Sheets and I created Titan in the first place, we really wanted to care for people. We wanted to create great jobs. And it wasn't obviously the most natural thing for people to decide to do, but it just really was what we focused in. And we didn't even totally realize at the beginning that that's what we wanted to do. But we brought in a brand consultant to start start figuring out, you know, like who are we as a company and what do we really want to do? And as we started talking about kind of all the the words and phrases that really aligned with us, we started saying, "Oh my gosh, like we have this shared vision of like doing right and doing good." And a couple years in, we wrote it up and we called it the Great Titan Experiment. We said we wanted to create a place we actually wanted to work for. And that's a lot to say cuz we had both worked at places that weren't like that. You know, I want you to come in on the weekend and you know, do your TPS reports. And we were really tired of living life that way. We wanted to find and help create a better way. But along the way, one of the things we found is that if your company and organization is structured around taking care of people and giving them a great place for them, those people who are happy and healthy and and a supportive environment are actually the most productive. They're most effective. So even if your goal in creating a company or a development team is to make a high productivity, highly effective, you know, super expert dev team, it turns out this is still the way to do it. So if you build the best system in the entire world, but you put the wrong people in it, it's not going to do you any good at all. People are the absolute foundation of everything you do in building a dev team. And at Titan, we're really kind of structured around this idea because we understood the people long before we understood the systems. When you look at our core values, the number one core value at Titan is trust comes first. Because if you can't trust the people you're working with, everything else is going to fall apart. And that's true for employees, that's true for bosses, that's true for your clients or whatever else. If you don't have trust, no other systems will work because people aren't going to trust that you're going to follow the system. They're not going to trust that the system actually was designed for their good. You know, the trust really is foundational. And if you think about a bureaucracy, a negative experience that you've had a bureaucracy or you've heard from somebody else having, thinking about the worst policies that they have, those policies come from fear, from lack of trust or responses to bad actions that now they have to protect everybody from. Uh there's a former employee of Titan named Dave Hicking. He's one of our alumni is what we call our former employees. And he would often talk about the fact that a lot of structure in larger organizations is really just scar tissue. you know, some damage happened, some negative thing happened at some point in this history, somebody did something and a person looked at that and said, "You know what I need to do? I need to make a policy to make sure that never happens again." And you, we could see this jokingly when you say, you know, no shirt, no shoes, no whatever else, you know, lots of places. And we laugh when those get a little bit more excessive. You know, nobody can come here with a penguin. Well, what story kind of led to that, right? Uh but when you find yourself in bureaucracies more and more times when something goes the way people don't want they say we got to make sure that this never happens again. They had a person who did something they shouldn't have which is you know obviously a problem in the first place but they respond to that by saying not oh let's figure out why that person was here why they did that thing. They say let's make sure this never happens again. And more and more and more just kind of systems and structures and processes get built on top rather than identifying the core issue which is usually about people and how people interact with each other. And one of the most important things about getting the people equation right is to have good people in leadership, good managers. Uh quality culture does come from the top, from the ownership, from the top level leaders, but it can be degraded if it filters through a bad medium. So if you've got this incredible leadership team with all this vision and all these kind of high quality values and then they pass it on to people who are selfish and inconsiderate and you know make people's lives difficult doesn't matter the ideals that you have if it's not actually the day-to-day life that people are interacting with. And I have a pretty small team you know a couple dozen people and even then I'm at a large enough size that I'm not interacting with every member of my team every single day. uh and so the people that they interact with every day, those are those managers and good managers are going to value their team members and they're going to try and create a healthy culture for them. So good managers are not spending their time, you know, trying to make sure that they look good. A good manager is empathetic and considerate and understanding and trying to make a better experience for the individual people who are under their team. If you're thinking about kind of creating good manager culture and hiring good managers, you can ask yourself, would you want to work for this person? Would you believe that they're going to represent you honestly and advocate for your needs up to your boss? You know, good managers are going to advocate and advocate for and provide for their team. Uh they can be honest to leadership about the team members shortcomings for sure. They can say, "Oh, they might have this problem or that problem, but they're going to do it in a way that is advocating and if it is a real big issue, then they will have spent so much time and energy advocating for the members other team that leadership will know that, hey, if there's something they said that's wrong, they're not going to jump to this immediately. So, this is something we really need to pay attention to. And a good manager sometimes will even fight the boss. And that's that's a pretty impressive thing to find is a good manager who is so strong and intent in advocating for their team that if you, the boss, are saying something, they say, "Nope, that's not the best outcome we have here." Uh, that's someone you want, who's willing to stand up to you. So, you might be saying, "Hey, if it's all about bringing in the right people, who are the right people?" And before you hire anybody or build your team or even evaluate your existing team, it's really important to be able to answer this question of what are we about as an organization? Who are we trying to be? What are we trying to do? You know, what's our kind of long-term values? And it doesn't necessarily have to mean that you're doing like a formal vision casting seminar or a 5-year plan, but the company or the team or the organization should have some sense of why are we doing this? what defines success or failure for our organization. And this will help guide who the right people are because it's going to be the people who are going to fit well within that organization who can be in line with your values. And it can also help you figure out how to evaluate and reward and guide the people who actually work there because you know what they're supposed to be doing what they're supposed to be about. Um it also helps the team be on the same page because you could bring in good people but they have a wide range of how they can possibly be as a person, right? and to say these are the things that we want from you. These are the things that are rewarded and these are the things that are not rewarded helps them understand okay at this particular place in my life at this particular company I'm working at these are the values these are what I should be focusing on and it also helps people know what will not be tolerated and even a very good person can behave in ways that they don't know are out of sync with a company's values because they might be things that are normal to them. It also knows what helps them know what they're safe from and you know you might operate out of some fear because at previous companies XYZ might happen it to you but at this company that is not viable that cannot happen that is not allowed and so now they can operate out of more safety or they can operate with more creativity and flexibility cuz they're not worried about those things you know and we have lots of examples for this at Titan it's going to be different for you but for example at Titan we tell our team clients can't force you to work over 40 hours their stress is not our stress uh we say hey if you are going to hear bad news in an annual review, you're always going to know it long before the review. Nobody should ever worry about showing up to a review and, you know, hearing really bad news in the review. They can be really scary things. They don't need to be for us. So, we're basically just trying to say like what are potential things that can be solved by just communicating what are we about, you know, who are we trying to be? Um, and defining those values in a way that guides our hiring, that guides how we're interacting with our team, and guides what they should be doing and not doing as well. So set healthy expectations, be explicit as possible about them. You know, we've got some core values that we have at Titan that we set so that we can help think about who are we hiring and help those people know what is valued in them. You know, one of them is cancel hustle culture. We're not trying to hire the people who are the 10x developers who are total jerks to everybody around them and ignoring their families, you know. Or we have one that says weird means interesting, which helps us focus on the fact that we actually appreciate having people who are different from each other in their values and their experiences. And also they know that that's something valuable and that they should bring to us. Or we have one that's called you've already made it. You know, we're trying to help people understand that this is not a place where you need to be showing how smart and how bright you are. You're already good enough. So now how can that define how you operate and that helps us think who we should hire and help them know how they should behave or you know go home after 40 48 you know some some sometime in your first couple weeks of Titan you're probably going to have somebody pull you aside say you know I know I know that you're kind of focused on this project but you're limited to 40 hours so please get out of here and don't do that next week. Now having and defining your values is great and it's a very important thing to do. However, it's fun to talk a good game. It feels really good. But everyone has had an experience with a boss or heard a story of one who's talked a good game when it's sexy to be the good boss who's like, "Oh, I'm going to give you this and well, we'll never do that and we'll never we'll always allow this." And then the moment anything is difficult, they roll all of that back. And it turns out it was all just talk. It's almost a tech trope at this point. some VC bro who's a progressive, caring CEO who treats the team like their family until things get difficult and then they treat the team like they're garbage. And so this brings us to the concept of integrity. And integrity has a lot of definitions, most of which have to do with, you know, moral uprightness and doing the right thing. But my favorite way of thinking about integrity is if you were to think about a different definition of integrity. This ship haul has integrity or has lost integrity from, you know, naval things. For me, it's from, you know, sci-fi. Uh, that integrity of the hall means it is consistent throughout. There's no holes anywhere. It is the same level of strength everywhere else. It is, you know, every piece of it is doing what it's supposed to be. It's unified. It's lacking disruption or corruption. And so, that means being the same person no matter where you are or who you're with or what circumstance you're in. You know, don't go back on your word, but also don't say things upfront that it's going to be hard or difficult for you to follow through later. If you don't know you can do that, then don't say it when you're not actually being asked to do it. It means avoiding the temptation to say what people want to hear when you don't know if you can actually back that up. And so we want integrity in our organization at every level. The senior leadership has to show integrity. Our middle management has to show integrity and the individual contributors also have to show integrity. And this all does still come back to trust. Can I rely on you to be who you said you were going to be at the beginning? Now, one thing I found is that all of these things, defining our values, hiring good people, showing integrity, hinge on the culture of communication we've created at our organization. On my podcast, Business of Laravel, I ask business owners to talk about a lot of things, but one of them is what book or books have helped you get to the point where you are today in your business career if somebody else wants to kind of get there too. And you'd think it would be all these kind of like corny LinkedIn style, you know, business analogy books, but the one book that has been mentioned more than any others is one of my favorite business books ever, which is radical cander. And if you're not familiar with the word cander, cander is the word that turns into candid, which if you can imagine someone saying, "Can I be candid with you?" Which means, "Can I be honest? Can I be open or direct or forthright?" you know, it's about speaking the truth to people, not just when it's cool to speak truth, but also when it's not very fun to speak the truth. So, this book is very much about um how business environments s do significantly better uh when people are able to be open and transparent and candid with each other. And uh it's very interesting because at the beginning of the second edition of the book, I believe it was, she actually mentioned how some VC bros again had taken advantage of that and said, "Oh, well, I'm just being candid when they were completely awful." And she mentioned in that first version that the original title of the book was actually compassionate cander. Uh because it's not radical in that you're being a jerk even more than you were before. It's radical in that being candid and transparent and open with people can radically transform the amount of trust and care and safety we have in our workplaces. So what does it look like to apply radical cander in our dev shops? Well, we definitely should set our expectations up front. We should communicate upfront what are we about and what are we looking for? And one of the things that we talk about um at Titan, one of our core values is be kind, speak truth, don't wait. So, we want to focus on uh as soon as there's something that needs to be said, whether it's before someone gets hired or it's on their first day or it's as soon as the problem has happened, we're going to talk about that issue as truthfully and honestly and kindly as possible. And kind doesn't necessarily mean nice. Doesn't mean we're dancing around the truth, but we're not being unnecessarily cruel or unnecessarily unkind. We want to build a culture of transparency, of trust, of safety, where the members of our team have seen the examples that we've set that we're going to communicate. And communication may not be easy every time, but it is the right thing to do. And if we're doing it openly and transparently, it can be safe because everyone is communicating this way. You know, the leaders are communicating this way and we expect everybody else to communicate that same way. So, we're modeling it and we're teaching it and then we're enforcing it. They say this is what we expect of everybody. Everybody needs to be open and transparent and communicate like this. And a lot of this, even though it's kind of like had like a little bit of a somewhat positive, somewhat negative kind of spin, when we think about communication, we still more often assume positive than negative. But what if we're not talking about creative communication or planning communication? What if there's an actual explicit conflict that comes that's come up? Often what happens is when we're trying to build these safe spaces and these kind of nice places, we end up building these kind of nice circles where nobody actually wants to bring up the negative thing or the conflict, at best because everybody's trying to be kind, at worst because they're worried that if they kind of speak up, they're going to get in trouble. And it's funny cuz every new developer that has joined Titan has been surprised to learn that Matt Styer, the Mr. Rogers of the Larvo world, turns out to actually be very direct and frank. and we kind of have this like your first time you get your code reviewed or the first time there's a you know you try to work 60 hours that week even though you've been told not to whatever you know like we can have a tough conversation and being kind and being a considerate person does not mean not being direct and so we definitely had a time in Titans history where as we were growing larger it was becoming more necessary for us to be intentional about our difficult conversations and so I brought the whole team together and we read a book called Crucial Conversations and it was basically a book all about what does it look like uh for us to have these hard conversations, not just the easy ones. I'd highly recommend checking out that book. I wish I could do a whole video on it. Um, but having the skill of how to have healthy conflict and healthy conversations that are difficult and even potentially uh critical or uh disagreeing. Um, it's really important to have a healthy dev team culture. When I say all these things about kindness and caring and safety, what I don't mean is we all just sit around and say nice to thing nice things to each other all the time. What I'm saying is we are all capable of communicating the good and the bad. And think about the least healthy team culture you've been in. It's likely you're frustrated because there's a lack of communication. Uh you're frustrated because the communication that's there is bad. Um you know, sometimes it's a lack of positive communication, but more often than not it's ineffective conflict management. It's ineffective or maybe non-existent communication about difficult things. You don't feel safe or free to say what you don't like or if you do, it's not listened to. So imagine that exact same scenario for that worst team that you've been in. But in that moment, you felt free to speak up because it'd been modeled and proved without threat to your job. And you know it'll be listened to and hopefully even acted on. All right, two more components in this video. First one, mutual improvement. One of the things that's a key focus in the Laravel community that makes it super attractive to outsiders is that the desire to help each other is a really high focus in the community. The most popular thing you can do in the community that it's going to give you the most reputation is teach or help or create. And at Titan, we often hear our clients refer to something they often say is the Titan brain. The way you bring in one developer or two developers, but you get access to the entire team plus the knowledge of people who often used to work there or leadership or whatever else. And so, you know, this is fun because there's a good chance you have the author of the framework working with you or someone who's spoken or written on the project. And that is something we build through lots of very practical steps. We'll talk about some of them later. Things like pair programming and internal talks and 20% time. But the most important part about creating a healthy developer culture that's relevant here is we do it by encouraging people to be helpful to each other and hiring people who like helping each other. this aspect of developer culture where instead of having to compete with each other to prove that they're smarter and they're better in order to worry about their job, they can instead say, "Oh, I have a focus of helping other people. I have a focus of teaching the rest of my team. I have a focus of contributing to my team and to the broader layer of our community allows us to have this titan brain because when somebody has done something, first of all, they're going to share it naturally, which means everybody else either knows it or knows this is the person to reach to. But second of all, even if you're not the developer of the project, you may not be the person getting all the credit, you still want to help because everyone is just there building each other up. And so that's a really incredible opportunity and it's also a safety for people to just be able to help without worrying about how it makes them look. All right, our last one is the most directly practical. You want to offer good benefits to your employees. These are benefits that allow them to care for their family, like flexible hours and good health care. Things that mean they don't have to worry about their family's health or their family's education or their own health. Allow them to focus more on the job that they're doing. It's also the right thing to do. But like from a very practical perspective, it's actually very valuable to having this healthy developer culture. You want to help them learn. At Titan, we do 20% time whereas 20% of your week can be spent kind of building your own knowledge base and what you're aware of and education. We also send folks to Laracon and sponsor them purchasing books and courses and everything like that. Um, and you can also just prioritize the people in the most need when you're making decisions across the company. For example, every single time we have to choose which healthcare plan we're going to work with, there's a little bit of pressure to say, "Let's focus on the healthcare plan that makes it easier for people to handle their investing and minimize their tax advantage." And so far, at least every time, we've said, "Actually, we're going to focus more on the plan that makes sure that people who are in difficult health situations are most likely to be able to take care of themselves versus the tax advant advantageous one." Uh, you really just kind of want to think about like in this benefits world, you know, and that's technical benefits like, you know, COBRA, healthcare, whatever, and also any other benefits. Here are their biggest concerns and try to address them. You know, one example of how we're able to do this is we had several employees who were just constantly talking about they're like, "Look, this 401k thing is cool, but it doesn't really matter to me to save for the future when I'm still drowning in student loan debt." So, we looked into the opportunity for us to be able to give a small amount every single paycheck towards directly towards uh student loan debt. You know, things like that. Or people talking about their difficulty with taking care of their pets when they travel or whatever else. Think through the things that matter and are difficult and are important and valuable to to your team and look for opportunities to care for those for them. So overall, the trick to creating this healthy developer culture is to focus on creating an environment where you yourself would want to go to work every day. If you were this employee, what would you want in a healthare plan or in a style of communication or in a way of handling conflict or in flexibility of work hours or whatever else? Try to place yourself in their shoes. Imagine what you would want and create the environment you'd want to work in and that's going to get you there. That'll make it happen and it's worth it. So, productive development is what people are usually getting paid to do, right? insert money and get back productivity or output. But there's a reason that how to create a productive development team wasn't the first video. Productivity happens in a development team by putting the right people in a healthy place and giving them the tools and processes to do their job. So you can't expect productivity from the wrong group of people with no understanding of the values and goals are in an unhealthy environment. But once we do have those things, what do we set up next? A lot of those individual pieces we're actually going to cover across the rest of the videos. Um, but in this particular one, we're going to talk about some of the core understandings, the core pieces of what it looks like to create a productive development environment. Well, you'll be unsurprised to hear that the leadership of the organization is key to defining the productivity possibility for the people who are actually in the organization. Your leadership should be focusing first on hiring good people. And it's funny cuz the section after this is called people. And if you watch the last video, I talk a lot about people because that's actually the most important part of what we do in creating these productive development teams. Once you have good people, you can trust them. And then once you trust them, you can focus on building environments that are conducive to their productivity rather than putting all your energy into covering your ass, measuring and micromanaging everything that they do, which is a really common kind of first step that leaders take when they don't know exactly what to do is they just try to kind of control. They say, "Well, I must be involved in everything they're doing and I must make sure it's good enough." And if you just say, I believe that these are good people that are going to do good work, then you get to focus on, well, how can I make it even easier for them to do good work versus how can I make sure that they don't be the bad people that I inherently think that they are? So, if you don't have good leaders, your best developers in the face of being treated in that micromanagy way, they can't be productive because they're going to spend all their time doing things to satisfy the, you know, inane desires of those leaders and they'll leave. or at very best they'll do really good work for a while and then they're going to burn out and then they're going to leave or even if they don't leave they're burnt out which is not an ideal outcome for anybody. At worst they're not going to be able to do the good work in the first place because bad leadership rewards the wrong things. Bad leadership is looking for you know metrics you know have you done a certain number of these things how many commits is a very common thing that we see you know how many lines of code you know how well do you follow particular structures and structures whereas good leadership is trying to identify actual valuable output and also care for the people at the same time and so if you are someone who cares about doing good work cares about being honored and respected and being treated you know like a decent human being that bad leadership is going going to make you feel like you're being rewarded for all the wrong things. You're being dinged for all the things that you shouldn't be. Whereas that good leadership is going to make you feel happy and satisfied and like you're actually doing a good thing. So that bad leadership is going to get those good people, even if you found them in the f first place, it's going to get them on a quick train out of working where you are. And good leaders also take opportunities to learn things that they don't even know about in the first place, uh through one-on- ones. Uh good leaders are going to focus on understanding kind of how to say well what are some potential uh harmful potentially harmful things here? What are some things that might get in the way of your productivity and how can we address these things and what are some benefits we can provide to you that will increase your potential for productivity and happiness. And we can talk a little bit later about what some common harms to productivity are. But if you're listening well in your one-on- ons or even watching well in Slack often in our our context, you're going to find out a ton about what potential harms are to productivity and ways that you can be a part of making those harms to productivity go away. And you'll likely find that developers are extremely frustrated about things that hamp hamper their productivity. I don't know very many developers who want to show up and just do nothing all day. They want to show up and feel like their work is respected, like they're seen as knowledgeable and capable experts and then given the space to do so. And so when those things are not happening, which means the productivity of the company, the productivity of the team is being disrupted, they're going to let you know cuz they're like, "All I want to do is just good work that actually benefits the end client and for X, Y, and Z reasons I'm not able to." Well, great. They're going to let you know that and now there is a productivity hamper that you can be a part of fighting. When you hire the right people, they're happiest when they can just flow code, right? When they can just flourish and just sit down and just say, "I know what to work on. I'm going to do great work on it." And those good people are not happiest when they can skip work, right? They're happiest when they can do good work. And so, if they trust you, they can tell you what things are getting in the way of them being able to do their work. And voila, you know, some, you know, actionable steps to make everybody more productive and happier while they're at it. I'm going to talk about people in every single video, so I'm trying to keep it short here, but I would say there's at least two really important things you can do for hiring people who are going to benefit the productivity of the team. And the first one is hire people who have shown they are capable of learning and teaching themselves. If you can see someone who's capable of growing, who's not just sitting waiting for somebody else to bring them along, but they do that work themselves, it's extremely valuable. And then second of all, hire people that you know you can trust. someone you say if I hand this to them and say this is what you need to do and then I disappear and they could just slack off when I come back I know it's going to get done and then take those people and put them environments where you help them learn and you trust them you take good learners and help them learn trustworthy people and trust them it's going to go so far to help you build systems that do not require you to be concerned with how much they know concerned with how reliable they are or anything else because they're just going to become little powerhouses of their own and you can spend your time and energy on other things as a leader. And you do want to identify other potential harms to productivity. I mentioned how one-on- ones are a great space for you as a leader to identify the specific things that are going on with your team, but there's also some very common things that address and concern most people when it comes to their productivity. And so, some things that are very commonly harmful to productivity is being forced to work at times that don't make sense for you personally, whether it's because on this particular day or every single day or a certain period of time, this is just not when you can be productive. uh having to work when you actually need to be caring for your family. It's kind of like a part of that same thing. If I need to be going to pick my kids up from the school bus at 3:00 every single day and I'm capable of doing that and just working an extra hour that night, then I'm not going to be stressed about, oh, who do I get to go take care of the kids or what's going to go? I just say, oh, you know what? I just disappear for a little bit at this time and I come back ready to go and grateful that I have a flexible job. Uh other things that are harmful to productivity, meetings. Meetings are harmful to productivity. all of them. Uh, get rid of as many as you can. Um, anything else that is basically not doing the thing they're supposed to do. Time sheets, you know, reporting the work that they're working on. Emails. Oh my gosh, we're cover going to cover a whole bunch more over the span of this course. Um, but basically anything that is not sitting a person down and saying, "Hey, you're set up well. You're rested. You're not distracted. Uh, now do the thing that we hired you to do." Anything outside of that is harmful to productivity and you should minimize it as much as possible. So let's assume we have a really fantastic work environment set up at this point. How well are your developers set up when they actually sit down to code? How capable are they of spitting out quality application code as soon as they sit down? How much time is wasted at the top of each project or in each pull request or in code review or as they're planning or writing code? There's simple steps that we can take to minimize all of these distractions and frustrations. And I do want to say that a lot of this is going to come into videos later about our uh process as a company um in terms of our uh tasking and then our process as a company in terms of technology and development. So this is just kind of like a really quick taste, but it is relevant uh to this productivity thing. So first of all, don't cheap out on tech. They should have the devices they need to do their work. You know, laptop, keyboard, monitor, chair, whatever the IDE, the SQL manager they want to deal with. These things are like the truck that a truck driver drives every day. You know, like truck drivers, it's it's got the right wheels and it's got the whatever else. Or these are the hammer and the screwdriver and measuring tape and pencil and saw for a carpenter. Yeah, it costs upfront to get those things right. But a good tool does not make a good dev, but it is very difficult to have maximum productivity, if that's what we're talking about, out of your good developers if they don't have the right tools. So that doesn't mean they need the latest and greatest of every single thing, but it doesn't mean that it's going to be always free to give them everything they need. Second of all, it should be incredibly clear upfront how to spin up a new codebase. Clear guidelines, you know, clear setup instructions. Uh, everyone should be able to get a new machine, clone down your codebase, be up and running in minutes. Third, the processes in your organization should be super clearly defined. So, what do I do when I check out the codebase, when I'm branching, when I'm creating or reviewing a pull request? The clearer these things are, the less time and friction there is. The less time wasted and the less friction there is every single time these things happen. And fourth, everyone at the company should know as quickly and easily as possible what good code means and what the minimum baseline is for good code. It makes it much more likely that people are going to write good code. It also shrinks the amount of time they're going to spend uh reviewing other people's code or actually even their own code to make it sure it's good enough. And it significantly minimizes the amount of bike shedding your team engages in, which is basically wasting time talking about what's the best way to do a particular code thing instead of just doing the thing itself. And again, there's a video coming later specifically talking about these factors, but I at least want to introduce it in this productivity section because setting your developers up for success and productivity definitively requires you to have a thought or seven about uh what is the best environment they can be set up in terms of their tech, uh their processes, their code, uh everything. So, more videos across this course will continue to talk about tools and processes that you can use for productivity. I'm sorry I didn't cover all of them here, but they'll we'll get there throughout the rest of this. But this video did cover the most important piece, which is to find good people who are trustworthy, who are capable, who have shown their ability to grow, and then support them in those things. you know, trust them uh instead of spending your time and energy making sure that they do what they're supposed to. Uh give them resources to grow, but basically just let them do their good people stuff, right? And then your energy goes into building the opportunities for them to do what they're already going to do even more, even better. So, you know how to find the right people in theory, but when you find those people, how do you know which roles you're going to place them into? And how do you know who's responsible for what? It's easy to think that too much structure in your organization might take away our ability to be creative and to be flexible in our hiring and our placements. And that is possible, but it's also really valuable and beneficial to define some form of a hierarchy or structure or if you have a more flat team, at least to define some kind of rules and expectations for what your team is going to look like. And this can relieve a lot of stress and prevent a lot of conflict between your team members when they actually know what they're supposed to be doing and who to report to and all of that. And there's also a lot of other benefits to creating a more structured or at least uh defined team shape when your team knows what's coming next in terms of where do they go after this is there an advancement track. So let's take a look at what building that development structure looks like. The first thing you're going to do is to draw out your ideal team layout for your development team. Who's connected to whom, who's on what team, who reports to whom, whatever else. This is less about your existing team layout, not even necessarily about your existing team. This is really just figuring out for the organization that you have what makes the most sense in terms of what the structure in this organization is going to look like. And you want to make it clear in this layout who reports to whom. Uh what defines one job or one team from another. And in this layout, you also probably have some overall hierarchies. For example, my director of engineering is going to be running one-on- ones with all the developers, so they're all direct reports. But then sometimes there's also going to be some contextual hierarchies. For example, a lead programmer will always be the lead on a specific project. And so lead programmer might not be over other people, but in specific contexts they will be. You're also going to want to write out, you know, are your teams organized as full stack teams or is there a back-end team or a front-end team? Whatever organizational systems that you need in order to figure out where are people and where are people in relationship to each other on this development team. Now, let's pause for a minute because you're probably thinking, "Hey, I understand the idea of drawing out my development team." But tell me what I'm supposed to draw here, Matt. You're the teacher here, right? So, I'm going to tell you what I think makes the most sense for the layout of development team, especially when you're working in full stack Laravel. And this could be different in other contexts or even in Laravel teams different than mine. But this is what I have experienced being most beneficial at Titan and also most beneficial in teams that I've helped build through Titan. Small teams of full stack developers. One CTO or director of engineering type leader at the top and then three to fiveish small teams each of which contains somewhere between two and three developers. And each of those teams contains one lead programmer or senior programmer. And everybody's involved in code, right? All three people on the project um are code writing and code reviewing as well. And those leads are more like the architecture leaders and they're the go-to person for technical questions. They're also the primary communicator with project managers or product owners or account owners or what kind of whatever your kind of like non-technical lead is. And they'll also if you have clients, they'll lead the conversations with clients. And so that's what we have at Titan and I think it works extremely well. Um we basically will take a given feature or set of features and we're going to assign it to this team and the project manager together with the technical lead um figures out you know what are we going to be working on what are our tasks that we need to split up and then they sit down and the programmers do the work and they'll do some pair programming and some non-pair programming. Each developer can write code, but they also make sure they're reviewing each other's code. And in the end, the buck stops here with technical quality is going to be on each project with the lead, but they always have that CTO type person to turn up to to say, "Hey, can you take a look over this for me?" Or just know that they're going to be checking in regularly. And we could have grown a lot bigger at Titan. Um, and we've actually gotten bigger at one point, but the point we got too big was when this sub started not making sense. And I have never been unhappier in the existence of Titan. And it kind of makes sense. I remember from what I did before Titan, I was working with nonprofits about, you know, like how to organize people together. And one of the things we kept learning is that there's these different kind of like tiers of the size of an organization where the culture has to shift. And not everybody uses the same numbers, but often they're talking about how it's going to be at, you know, three and it's going to be at 12 and it's going to be at 50 and 200. At each of these moments, it just there's kind of like a natural spot where you're going to be like, you know, it's all going to make sense and we're all going to work together here. But when you start going above that, it starts not working and you need to come up with a new system and a new structure uh for the new size. But also, it's sort of like um there's almost gravity to get to the next size. Those in between sizes don't always make sense when you're too big for what worked at 12 and too small for 50 for various reasons. And so there's kind of like a momentum to get there. and we were we were kind of passing the one size and we're moving to the next size and this this kind of structure stopped working quite as well and I hated it. And I'm very happy that the team size is where it is today. If I had to build a larger team in the future, what I'd probably do is just take this size, like I said, three to five teams, two to three people, and just build multiple units of that size. I really just think that this makes a ton of sense as a team shape. Now in my mind each of these individual teams needs at least two types of leaders and they could be the same person but at Titan we have them separate and this is a technical leader and a process leader. The technical leader is responsible for some of the things I've already talked about. They make architectural decisions. They decide you know code style issues if they come up. They are the ones who are responsible for making decisions about what's happening technically. Whereas the process person is a little bit more responsible for kind of interpersonal interactions. They're scheduling meetings. they are planning, you know, burndown charts or whatever kind of things you need to do. They're handling all the things that have to do with like the work of getting work done. Uh whereas the technical leader is handling the actual work, the the structures and organizations of the work. And the technical leader does not have to be an interpersonal leader. It is valuable for them to be an interpersonal person in some ways because they should also be uh helping the the individual team members on their development team grow. um but it's not their job necessarily to interact with product or with business or with clients. So again, they're setting more kind of like code and architectural direction. Um they're going to review code, but I think everybody should review code. Um I think the most kind of like interactive thing that your technical leader is going to do outside of with the internal team is to participate in planning sessions with the client or with product or with business from a technical perspective. So they do need to at least kind of have that. But again, you've got this process leader. At Titan, we call them project managers, and they are handling a lot of behind-the-scen things like meetings and tasks and timelines, but they're also often handling first-line communication with the client. They're leading those meetings with the client. Uh, personally, I like it that our uh project folks are also kind of a little bit UX capable. They're doing um, you know, they're doing UX diagrams and wireframes at a lighter level. We'll pull in a professional UX designer if we need. And they also manage all of our internal processes, like what are our check-ins, what are our timelines, how are we logging the work we're doing, and everything else. There's one last thing that's not specific to the project that you're on, but since we're talking about leadership, I want to mention it. I want your top level technical leadership at your organization to be someone who is technical and has high power within the organization or high agency. They need to be technical enough to know what really matters to the development team. things like technical debt and they need to be powerful enough to go to bat for those things. So if you're let's say you know the director I guess VP of engineering or the CTO or whatever the person you're not interacting with the day on a day-to-day but the dev team eventually kind of reports the whole way up to them if they're not capable of understanding when you make the pitch that we need to hit pause on product development for a little bit because we're getting you know more and more technical debt um or uh if they are understanding it but they're not capable of having like the leadership level to actually make that fight against other people at other senior levels of leadership they're not going to be able do what they need to do. So, we need those two types of leadership on our teams, but then we need somebody above us who understands and can fight for us. Now, I said this before, but I personally think that the best team is a small full stack team. And I also want to name that they should have at most one junior developer on the project. There's lots of other different types of team organizations you can consider. And I want to tell you why I choose the one I just said versus those. And of course, you can choose whatever makes the most sense for your organization. But here's why I prefer those. So, first of all, I like full stack over divided responsibility. So, every single member of the team can build frontend and backend versus there's a backend team and a front-end team or even teams, which I think is a little bit better where every team has a backend dev and a front-end dev or something like that. It's because when you're separating teams like that, especially when it's a back-end team versus a front-end team, you are dividing folks. you're adding all sorts of unnecessary process and friction for every single feature that gets pushed out, every single bug that gets fixed. There's a lot more back and forth that happens has to happen between each of these and so it drags out those cycles and it includes the time to production. Um, if I have uh everybody's working on full stack and we get a feature definition, we can understand the feature and we can build the front end and the back end and push it to QA and then push it to production in days. It's very difficult to do that when you have these separated teams because each team has to do that same length of process. And so even if it goes from days to maybe just weeks, do that over and over and over again and you're just going to find that the incremental friction cost from each of these kind of like these boundaries between teams is going to increase your cost and your time to do anything significantly. And I prefer a small team versus a large team because in a small team every person does their work. There's no hiding. There's no bureaucracy. You know your job. You do your job. You know who your buddy is on the project. You partner with them on their work on the project. And with larger teams, it's much more likely to have little sections where people are just not getting work done or they're hiding behind the fact that well, I can understand that those three people are going to do the work and so I'm going to hide the fact that I don't actually know how. On larger teams, you end up with uh you know, I've said you don't want too much process but or structure but some is good. The bigger the team is, the more unstructured that team is because now you just have a mob of 12 people all sort of doing the same thing and getting their individual assignments, but there's not clear delineations and and definitions of, you know, who reviews whose code or uh, you know, who does which piece of what or who do I pair with. You know, the bigger the team is, the more it's just a mass of 12 people. Where these smaller teams, it's very clear what role each person is taking on that team at any given moment. And why do I say max of only one junior developer? Well, junior developers add capacity a little bit, but they do that at the cost of the capacity of your more senior leaders. You can't just add four juniors to a senior thinking you're going to get the equivalent of I mean, of course, not three devs or five four devs, but you might think, oh, adding four juniors gives me the equivalent of three more devs or two more devs. What really did is you just got four people who are doing bad work and now you got a senior whose capacity to work is significantly diminished because it's almost a full-time job just manning the juniors. they have in the project. And I I love apprentice programs. I think apprentice programs are incredibly important for us to have a great pipeline for new developers. But the biggest mistake I see is folks trying to save money by throwing a bunch of juniors because they feel like they're really easy to hire um on a project uh together with one senior or five seniors and 20 juniors or something like that. It's not the way to do it. Maximum one junior to every two programmers. Maximum. Okay, so let's say you've just laid out this ideal plan. There's two kind of ways to approach it. Are you just getting started or are you working with an existing team? If you're just getting started, the first person to hire is your most technical person. This person is going to define the culture, the technical direction, the standards for your organization. So you want a CTO or a senior technical leader. The only way around this is if you temporarily hide hire that role by bringing in someone like Titan or a senior level contractor to be your senior dev as you hire more entry-level people. But I definitely would say no juniors until you have at least one fully functioning dev team working together. And even if you do use folks like Titan to set that up, uh you do eventually want to bring that senior person on earlier rather than later. Now, if you're working with an existing dev team, I told you originally to ignore your existing dev team, but now that luxury has passed, I would say if you have this new ideal setup and you have your existing team, the first thing I would say is don't move people into leadership just because of their seniority or because of their technical ability, uh, take a look at your existing team and see how well they do or don't fit into your ideal team setup. And if you have people who don't fit, now is the time where you can take a breath and see, can you kind of finagle them into this new organization, but as a temporary thing, right? Just for this person or just for this person for now, as you work on a plan on figuring out how they can eventually move to where they actually should be. And this might not work for everybody. You may end up just having too many underperforming developers. And it's an awkward situation to be in because this move may you re may make you realize that you need to let some people go. And that's not an exciting position to be in. And I hope that this course doesn't lead to people losing their jobs. But you need the team structure that will actually work for your organization. Um, whenever possible also, instead of hiring in new people, it can be tempting, especially if you just heard me say, you know, like if people aren't doing the job, you know, you might have to let them go. Uh, whenever possible, promote up from within. train people up who are already in your organization and promote them up into higher leadership positions rather than hiring into higher leadership positions who've never worked here before. Um, this gives you the benefit of people who really understand how you work. Um, and also gives you the benefit of giving people the understanding that when they come in at a more entry level at your organization, there's a path for them for growth rather than just feeling like they're going to stay in this entry-le position forever and you're just going to hire senior leaders in. Regardless of what needs you define, your needs today aren't necessarily going to be the same as your needs 5 years from now. So this system can change as your team and your needs change, but also as your understanding of your ideal setup changes. And so you really just need to stay agile, stay flexible, keep asking these questions of what is the ideal setup for your team. For me, the easiest part of running a dev team is finding good people, getting business in my agency. It's a little bit less natural for me, but the people super easy. But I hope that even though it's easy for me, I still can do a good job of sharing how I do it and making it a little bit easier for you. Before it comes to even putting up a job posting, there's two big things you can do to make the hiring process significantly easier. First of all, make yourself known. Get out there, talk about your company, uh teach in your respective area, share, give back, donate, uh contribute, sponsor things, help people know who you are, and also be a great place to work so that they want to work there. As you're building this reputation, it's not just a reputation that you do good stuff on the internet, but that brings attention to you. And then people start asking, well, what is it like to work there? And they can talk to your current employees. And so if it's a great place to work, they'll tell everybody else about it. The second thing is be active in the community just socially. So go to conferences, go to meetups or create your own meetups, hang out on Twitter, watch live streams or connect on GitHub with what the you know who's working on the packages that you're working on. Getting to know people before you need them to come to you does a ton of good for you. The rest of the sections of this video will require you to at least have a baseline understanding of what job you're actually hiring for. Here, it's funny in jobs to be done, we say, "What job are you hiring the tool to do?" But right now, I actually mean the human. What job are you hiring this human to do? What roles and expectations do they have? What are the systems and structures of their team? And if you take a look at a previous video here, I talked about how to structure your dev team. You need to have that structure so you can know what you're hiring this person into. Is it a junior role or senior role or a mid role? Uh is it a CTO? Are they more technical project manager instead of actually programmer? Is it front end? Is it backend? Is it full stack? Are there additional technologies you need to them to be experts at? There's so many things you need to define before you can write a job posting, before you can evaluate if somebody's good enough for that job. So before you even start any of that, what's the actual job? All right. Now that you understand the job you're trying to hire for, you can actually start building your job posting. You want to define the specific job as narrowly as you can. Really kind of talk about what the ideal will be. And we'll build a posting from there. And it might expand out some, but start with who's your dream candidate. Like brainstorm, you know, who could this person be that really provides everything you want? Think about what good code looks like for your organization or a good member of your team looks like and what characteristics do you really value. Like at Titan, we like self-taught fullstack developers who have a whole suite of other interests and experiences who show great attention to detail and are ex extremely capable verbal and written communicators. You know, that's the thing that we're looking for. And so our job posting is going to be asking about those things. And of course it would also be great if they are, you know, experts at DevOps or whatever else, but like those are our kind of top priority things. And then what you want to do is separate out your must-haves from your nice to haves. And you want to make that must-have list as short as possible. And the nice to have list can be literally as long as you want. And your must haves are probably going to be things like Laravel programmer, JavaScript expert, database management guru, you know, uh, you know, Ubuntu manager. you know, the nice to haves are going to be more things like uh you know, stuff that it's valuable, but you don't have to have it. Experience with Azure, um experience with machine learning, can speak Portuguese, you know, whatever else it ends up being. And the must haves often also are going to include some things like the time zone they work from or their working hours, the ability to travel, fast internet, uh you know, a decent camera, things that, you know, if we don't have that, it's going to be actually a deal breakaker. Nice to haves will be other things that are, you know, based on experiences or specifics that, you know, they can learn on the job, but they have less to learn if they have those. And in this job description, you also want to talk about the company. Why would somebody want to work there? You know, the job description is for the job that you're posting, but you want the right people to apply. And the more discerning person, the one you're more likely to want is the one who's going to care more about your company and what's your culture like, what's unique about your mission, um your people, you know, like why are you a better job than where they are right now or the other options they have available to them. And in the same direction, you also want to share about the benefits, but as much information as you possibly can about pay, uh tangential benefits, uh fun aspects of company culture, things that will attract them. Um especially table stakes such as like does it have a 401k, does it have insurance, health insurance, stuff like that, but you know, it really is special and sometimes legally required if you can even talk about the amount of pay that they're going to get or other financial benefits they're going to get. Now, throughout this job posting, as much as possible, you want to use real language. I kind of choked over the word guru earlier, but don't do that. You don't want to use sales bro language. You don't want to call people wizards or whatever else. You just talk about what they do. Uh talk about what they're going to be doing. Um and what you want from them and, you know, sort of describe this person in normal casual language like you talk and also talk about yourself in normal casual language. Here's who we are. Here's what we do. Who's here's who you hopefully are. And here's what you hopefully can do. And the last thing I really want to say is you should set a timeline for the applications and when they're due. Uh the one of the things that's hardest about this process is lack of clarity and explanation of what people can expect as they kind of walk through the application process. And a way you can really help them is to say, uh, all job descriptions must look like this and they must be due by this point. And you can tell even further if you want. You can talk to them about what the entire job application process is going to be like, but you don't have to. In a job posting, at least you should say, "This is what we need from your application and this is when it's due." And one last tip, if you are having trouble writing a job posting, especially if you have multiple roles in your company, uh it's very valuable to write a single kind of like baseline programmer job description and then kind of scale that up and down based on seniority. So for example at Titan if we say here's what a mid-programmer needs uh for a senior programmer we'll modify it to say they can do that without supervision you know without a lead on top of uh you know their code or if we're talking about a more junior one they can say they can do those things with assistance. So that basic job description of just what a normal mid-level programmer can do is often the easiest thing to write first. Lar jobs is the best place to find people who are dedicated to the craft of Laravel for the people who are spending time in places whether it's conferences or meetups or on Twitter or wherever else where they're working together and connecting with other people who do Laravel and they're really focusing on their ability to do Laravel. Well, those folks get into the Larra jobs world because Larara Jobs is sponsoring those things and they're actively involved. So, the best way to find the best Laravel people is on Larara Jobs. So now it is time for you to evaluate job applications. One thing I would recommend doing at the beginning is to find something that anybody, not your most senior hiring person, your most experienced person, but basically anybody who can read can evaluate for and then have them triage your initial applications, assuming that you have hundreds, which is often the case. something like only accept people who live in this area or only accept people who specifically name that they can do these particular technologies and you want to have those folks not just yourself but those folks helping you on a rolling basis. So every day or a couple times a week, have all the triage people look together at all the applications and filter out the people who don't fit those baseline lists. And those folks also should have freedom, especially if you're one of those people, to add some kind of a special label to the people that really excite you, where you go, "Oh, no. This is someone we really want to pay attention to. That'll make life easier later. Once you're done with that, hopefully you're down to 30 to 60 good options. If you have less than 20, that's great. Just have your initial interview with all of them. But you're likely to have 20 plus people who end up in that circumstance. And so now I would go through and spend more attention. And you, the hiring manager, should be the person spending the most attention looking through that list and picking your favorites. And you want to think about things like personality and vibe, uh, their unique experiences or for any other aspects that you know would be valuable in this role that the triagers might not have known about. You know, their history of working at a particular tech stack or uh are you familiar with their reputation or did they make a package that you really respect or whatever else. The the goal is to try and get it down to somewhere between 10 and 20 people at this point. Anyone who's not moving on to the next stage, email them now. A form email to every single person is fine, but don't not email them. Don't leave them hanging. Send a quick email that says, "Thank you so much for applying. We won't be moving forward with your interview at this point." So, they at least are aware that they're not just sitting waiting for you. Um, and I do have one just kind of small pet peeve. I didn't know where to fit it in the talk uh in the episode, but I just wanted to share this now. uh a senior non Laravel developer uh is not a senior at a Laravel job and that's something I'm mentioning at this point because you want to evaluate it and it might look like they're senior you say only accept people who are senior developers who have x number of years well if all those years or all that experience is working in a nonarl space that doesn't mean they can step instantly into your senior Laravel position uh so that doesn't mean don't talk to them but I want to flag that as a concern senior Laravel developers have senior Laravel experience And now it's time to conduct your interviews. Most people have multiple rounds of interviews, often 10 and 15. I would say figure out what works for you, but try as hard as you can to keep it to less than five interviews for every single person if possible. And before the interview, there might be a step you want to take. One thing we like to do is coding challenges where we say, "Hey, can you take home this coding challenge and come back, spend no more than 4 hours on this, you know, so we don't feel too bad about making them spend a week working on something. Uh, give them, you know, hope preferably the ability to do at least over a weekend." So that if they say, you know what, I'm supposed to do this, you know, after I do my day job and then go home and be a parent and then I'm exhausted at the end of the night and try to find time with my spouse and now I have to fit 4 hours in. Give them at least a weekend. Um, and then evaluate that. And sometimes you may or may not have that as a part of the interview process or you might evaluate before you send them to interview. But at some point it's time to actually talk to them in person. And at Titan we do our first short call for that 10 to 20 people that I call the the not an axe murderer chat which is just like a casual conversation. You could call it a culture fit, but I'm a little wary of that. And the main goal is just to say like, can I have a conversation with you? Can you communicate well? Do we actually enjoy being on a call together? If anybody doesn't make it past here, send them a form email rejection right away. Don't hit these next moments of rejection or acceptance without letting them know the rejected people know that they're no longer in the running. Then you're on to a technical interview. At Titan, we go for a short, relatively, well, a relatively short, a very practical interview as close as possible to real life. So it's more going to be about uh reading code which you can do effectively in a call and less writing code which nobody can do effectively in a call with somebody staring at them without access to their normal tooling and everything like that. It's not going to work. So we're also not talking about things that you wouldn't do as a part of the job. So we're not doing linked lists on whiteboards or any of the other kind of Google and Facebook and Apple type challenges that have nothing to do with our day-to-day job. The goal is to find out can this person in a reasonable scenario do the things we need them to do in the day-to-day job. And so find things that have been pulled from actual challenges that you've run into at your job and then ask them about them. And the goal here is to get down to probably three to five people or even less that you could hire. The goal is saying every single person at the end of this, you know, period, I could hire them today. I don't know which one's exactly best, but I definitely can imagine them working for us. Send a form email or even a personalized email to the remainder of your 15 to 20 people saying, "Thank you so much. It didn't work out this time." And then sit down and give these last few people just some time to think about, you know, talk through it with the team, with your spouse. Take a walk. Maybe even do one more interview with other team members so that they can kind of give an input if it's not super clear. And just think about what would it be like to work with this person dayto-day? Who are you excited about joining you? you know what aspects of this process have led you to say, "Oh, I don't even know that this was something I originally valued, but when I've seen it in this person, we want it here." And allow that to help different people bubble up until you eventually know who that one person is that you're going to hire. And finally, you've got your person. It is time to send out a job offer. Now, at Titan, we don't actually send out the offer immediately. What we do is we send out a more informal email to kind of hash out some details. So, we'll say things like, "Let's work on the specifics of the pay if we have not figured them out by now. Let's talk about timing." Uh, one thing I often recommend with people is if you can afford to do so, encourage the person who is joining your team to take one to two weeks off between their previous job and working for you. Uh, it's basically free vacation, assuming they can handle it financially cuz they're not getting paid during that time. But often facilitating when our vacation is going to be can be really difficult, especially in the US. And so it's something that people don't think about that it's actually fine to just wait a couple weeks to join. Uh and usually when we're in the hiring process, we're not absolutely so urgent that we can't afford to wait one week or two weeks for them. And so that's a really great way for them to have a little bit of breathing space, but also for you to get somebody joining you after a few weeks of rest versus after the crazy last couple weeks of transitioning it out of another job. Once you get all these specific details figured out, it is actually time to send out that formal offer letter. So you put it together in whatever tool you're using. It's the the very legal official offer and you know once you get all the details in there you send it out and this should be exciting and also kind of scary. You know we're always nervous when we're sending out an offer. It's like I kind of watch those people waiting to see if they're going to get signed to a football team. And obviously it's not that big of a deal, but we've offered a job to someone who are really excited to join and now we're just sitting here kind of checking our phones every 5 minutes to see if they said yes, you know, and that's it's really a big deal. And I I hope that, you know, folks who apply to our job who are down to those last rounds are also in that same place of like, am I going to get the job? Are they going to offer it to me? So when they say us, celebrate. Celebrate yourself. Celebrate with your team. Celebrate with them. Tell them how excited you are to have them. And then it's time to hand it off to the onboarding team. And you have one last responsibility left, which is to send the the emails to the remaining three to five or two to four at this point, people who didn't get the job, but who you could have imagined working with you. This is not a form email. This is a personal email. These are people who have been through many rounds of interviews with you. You also want to hang on to those relationships with them next time. I mean, the next time you need to hire, do you want to work through 500 applications? Or pick one of these people who you've said today, "Yeah, I'd be happy to work with them." right? And you know them and you've been thinking about your interview experience with them for the months or years it is between. That's a person you want to hang on to their information. So send them a kind uh gentle email where you express your desire to work with them down the road and apologize that it's not this them this time. And now take a break, go for a walk, celebrate with your team. You did a lot of work and hiring is a lot of work. And even though of course the people getting hired or not hired are having a little bit more of an up and down, it's important to understand the drain it puts on you to do the hiring. And so when you're done, you don't just go back to work like take a little bit of time off and celebrate it. You did it. 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-toeek 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 Titan, the first thing we want to do is make sure that they have all the physical equipment they need to do at 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 going to 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 going to have to adopt this laptop, it's not going to be completely crazy configuration. 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 want to do that. Um, because, you know, if you fire somebody, you're not going to give them 3 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. 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, 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 co-working space. And because we're not paying for a physical office, I'm not so bothered by the cost of individual co-working spaces or individual um you know, chairs and things. Cuz 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, 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 them 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, 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 cursor MD files 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 parrot 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. We want to meet people who are not me 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. I do want to 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. 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 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 and I could tell you the magic one 123 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 Titan especially when they first start there. I want to 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 including what motivated them to join Titan 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 Titan 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 lead developer? Do they want to 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 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 101 ones aren't specifically for the benefit of leadership. 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. Uh for example, having a lead on every single team gives a focus for the people in 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 and in our annual reviews by annual 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…

Transcript truncated. Watch the full video for the complete content.