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.

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 gonna cover across the rest of the videos. Um, but in this particular one, we're gonna talk about some of the core understandings, the core pieces of what it looks like to create a

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 'cause the section

hiring good people. And it's funny 'cause 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

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

doing and I must make sure it's good enough. And if you just say, I believe that these are good people that are gonna 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 micromanage way, they can't be productive. 'cause they're gonna spend all their time doing things

that micromanage way, they can't be productive. 'cause they're gonna 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 gonna burn out and then they're gonna 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 gonna be able

which is not an ideal outcome for anybody. At worst, they're not gonna 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 strictures and structures? Whereas good leadership is trying

how well do you follow particular strictures 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 gonna make you feel like you're being rewarded for all the wrong things. You're being dinged for all the things

rewarded for all the wrong things. You're being dinged for all the things that you shouldn't be, whereas that good leadership is gonna make you feel happy and satisfied and like you're actually doing a good thing. So that bad leadership is gonna get those good people, even if you found 'em in the first place, it's gonna get them on a quick train out of working where you are. And good leaders also take opportunities to learn things

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

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-ones or even watching well in Slack, often in our context, you're gonna find out a ton about what potential harms are.

often in our our our context, you're gonna find out a ton about what potential harms are to productivity in 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 ham hamper their productivity. I don't know very many developers who wanna show up and just do nothing all day. They wanna show up and feel like their work is respected, that they're seen as knowledgeable and capable experts

They wanna show up and feel like their work is respected, that 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 gonna let you know. 'cause 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.

that actually benefits the end client. And for X, y, and Z reasons I'm not able to. Well great, they're gonna 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 it to work on. I'm gonna do great work on it. And those good people are not

and just say, I know it to work on. I'm gonna 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.

to make everybody more productive and happier while they're at it. I'm gonna talk about people and 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 gonna benefit the productivity of the team. And the first one is hire people who have shown they're capable of learning and teaching themselves.

who have shown they're capable of learning and teaching themselves. If you could 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

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 gonna 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 gonna go so far to help you build systems.

and help them learn trustworthy people and trust them. It's gonna 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 gonna become little powerhouses of their own. And you can spend your time and energy on other things as a leader. And you do wanna identify other potential harms to productivity.

And you do wanna 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.

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 three o'clock

If I need to be going to pick my kids up from the school bus at three o'clock every single day and I'm capable of doing that and just working an extra hour that night, then I'm not gonna be stressed about, oh, who do I get to go take care of the kids? Or what's gonna 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.

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.

Time sheets, you know, reporting the work that they're working on. Emails, oh my gosh, we're covering a gonna 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

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?

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 wanna say that a lot of this is gonna come into videos later about our, uh, process as a company, um, in terms of our, uh, tasking

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, uh, 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.

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. So 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,

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 outta 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 gonna be always free to give them everything they need.

but it doesn't mean that it's gonna be always free to give them everything they need. Second of all, it should be incredibly clear upfront how to spin up a new code base. Clear guidelines, you know, clear set up instructions. Uh, everyone should be able to get a new machine clone down your code base, be up and running in minutes. Third, the processes in your organization should be super clearly defined.

Third, the processes in your organization should be super clearly defined. So what do I do when I check out the code base 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 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, which makes it much more likely that people are gonna write good code. It also shrinks the amount of time they're gonna 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

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 wanna introduce it in this productivity section because setting your developers up for success

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. We'll continue to talk about tools and processes that you can use for productivity.

We'll 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

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.