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 gonna 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 and 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

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's gonna 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

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 gonna do is to draw out your ideal team layout

The first thing you're gonna 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 gonna look like. And you wanna make it clear in this layout who reports

what the structure in this organization is gonna look like. And you wanna 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 gonna be running one-on-ones with all of the developers. So they're all direct reports, but then sometimes there's also gonna be

So they're all direct reports, but then sometimes there's also gonna 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 context they will be. You're also gonna wanna write out, you know, are your teams organized as full stack teams or is there a backend team or a frontend team?

are your teams organized as full stack teams or is there a backend 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.

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 gonna 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 Tighten.

But this is what I have experienced being most beneficial at Tighten. And also most beneficial in teams that I've helped build through Tighten. Small teams of full stack developers, one CTO or director of engineering type leader at the top. And then three to five-ish small teams, each of which contains somewhere between two and three developers. And each of those teams contains one lead programmer.

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 in 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.

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 Tighten and I think it works extremely well. Um, we basically will take, uh, a given feature or set of features and we're gonna assign it to this team

Um, we basically will take, uh, a given feature or set of features and we're gonna assign it to this team and the project manager together with the technical lead, um, figures out, you know, what are we gonna 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-air programming. Each developer can write code, but they also make sure they're reviewing each other's code.

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 gonna be on each project with the lead, but they always have that CTO type person to turn up to and say, Hey, can you take a look over this for me? Or just know that they're gonna be checking in regularly. And we could have grown a lot bigger at Tighten. Um, and we've actually gotten bigger at one point.

And we could have grown a lot bigger at Tighten. Um, and we've actually gotten bigger at one point. But the point we got too big was when this set started not making sense. And I have never been unhappy or in the existence of Tighten, and it kind of makes sense. I remember from what I did before Tighten, I was working with nonprofits about, you know, like how to organize people together. And one of the things we kept learning is

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 gonna be at, you know, three and it's gonna be at 12 and it's gonna be at 50 and 200 at each of these moments. It just, there's kind of like a natural spot where you're gonna be like, you know,

It just, there's kind of like a natural spot where you're gonna be like, you know, it's all gonna make sense and we're all gonna 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 are

there's almost gravity to get to the next size. Those in-between sizes don't always make sense when you are 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, 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.

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,

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 Tighten we have them separate. And this is a technical leader and a process leader. And 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.

code style issues if they come up. They are the ones who are responsible for making decisions about what's happening technically. But whereas the process person is a little bit more responsible for kind of interpersonal interactions, they're scheduling meetings, they are planning, you know, burn down 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

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

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 gonna review code, but I think everybody should review code. Um, I think the most kind of like interactive thing that your technical leader's gonna do outside of, with the internal team is

that your technical leader's gonna 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, at Tighten, we call them project managers. And they are handling a lot of behind the scenes things like meetings and tasks.

And they are handling a lot of behind the scenes 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 wire frames at a a lighter level. We'll put in a a, a professional UX designer if we need.

and wire frames at a a lighter level. We'll put in a a, 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 wanna mention it. I want your top level technical leadership at your organization to be someone who is technical

I want your top level technical leadership at your organization to be someone who is technical and has high power within the, uh, 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 are, let's say, you know, the director

to go to bat for those things. So if you are, let's say, you know, the director or 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 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

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 gonna be able to do what they need to do. So we need those two types of leadership on our teams,

to 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 wanna 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.

There's lots of other different types of team organizations you can consider. And I wanna 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.

So every single member of the team can build frontend and backend versus there's a backend team and a frontend team or even teams, which I think is a little bit better where every team has a backend dev and a front end or something like that. It's because when you're separating teams like that, especially when it's a backend team versus a front end team, you are dividing folks. You're adding all sorts of unnecessary process

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 increases 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 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. 'cause 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 gonna find that the incremental friction cost from each of these, kind of like these boundaries

And you're just gonna find that the incremental friction cost from each of these, kind of like these boundaries between teams is gonna 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.

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 gonna do the work. And so I'm gonna hide the fact that I don't actually know how. Um, on larger teams you end up with, uh,

that I don't actually know how. Um, on larger teams you end up with, uh, you know, I I've said you don't want too much process but our 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

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 at 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?

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 gonna 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.

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've 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

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 'cause 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.

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's gonna define the culture, the technical direction, the standards of your organization.

This person's gonna define the culture, the technical direction, the standards of your organization. So you wanna CTO or a senior technical leader. The only way around this is if you temporarily hide, hire that role by bringing in someone like Tighten 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.

until you have at least one fully functioning dev team working together. And even if you do use folks like Tighten to set that up, uh, you do eventually wanna 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,

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 set up. 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

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

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 real 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.

But you need the team structure that will actually work for your organization, um, whenever possible. Also, instead of hiring in new people 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.

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 gonna stay

organization, there's a path for them for growth rather than just feeling like they're gonna stay in this entry level position forever. And you're just gonna hire senior leaders in Regardless of what needs you define your needs today aren't necessarily going to be the same as your needs five 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 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.