As you can likely imagine, there are just as many things that I want you to not do as there are things I want you to do in your engineering management career. And even in these previous videos, I was often not just thinking what has worked well for me, but what have I seen done poorly and how do I flip that into a positive. But the thing is, it's not always enough just to talk about the positives. Some of these things need to be explicitly called out as problems and dealt with directly. And sometimes even that's not enough, but we at least have to start here by

with directly. And sometimes even that's not enough, but we at least have to start here by saying hey, these are things, please stop doing these things and call it exactly what it is as we do. So I've got 12 examples. I split them up into four different categories, leadership issues, team issues, technical planning issues and the wrong responses to problem.

technical planning issues and the wrong responses to problem. So let's get started with leadership issues. Now I've talked about this in a previous video, but I want to mention it again because it is so common. The leader of your technical organization needs to be someone who is technically competent. And what I mean by this is someone who is at the most senior level of the engineering

And what I mean by this is someone who is at the most senior level of the engineering organization or the programming organization or whatever else. So not necessarily the CEO, but the director of engineering or the director of technology or the CTO should actually be a technologist, not a manager with a little bit of a hobby for technology. Preferably, the leader of your engineering organization should actually be an engineer.

Preferably, the leader of your engineering organization should actually be an engineer. If it's a programming team, preferably their leader should be a programmer. And it's not impossible to build a productive team with a non-technical leader of the technical organization, but it's asking for unnecessary pain. When the person who's tasked with representing the needs and the concerns of the programmers at the company doesn't actually have any experience programming or not just programming, but the

at the company doesn't actually have any experience programming or not just programming, but the like the non-technical aspects of the programming experience, like having to balance speed and stability or to take on technical debt to hit a deadline or to let go of the desire to code something beautiful for the sake of caring for the needs of the business and not having the experience of doing those things is going to make it very difficult for that person to

the experience of doing those things is going to make it very difficult for that person to both advocate for that, but then also to know when it's appropriate to push back. I would say the most acceptable compromise here is when you have a senior level leader of the technical organization who honors and respects the most senior actual programmers in that organization so that if those devs say something is the case, the leader believes

in that organization so that if those devs say something is the case, the leader believes it and goes to bat for them. Oh, the number of times I've seen this one. It's most common with younger companies, startups and scale-ups and what happens is they've used one tech stack to get this far. They built MVPs and proof of concepts and, you know, what feels like kind of maybe smaller more throwaway stuff and then time comes for them to get all grown up and bring

maybe smaller more throwaway stuff and then time comes for them to get all grown up and bring in a C-suite and often a CTO and they neglect to get a CTO that actually works in their existing tech stack. So new CTO comes in who seems really compelling in the interview process and the first thing they do is say we got to throw away at everything. This is all terrible, but the good news is I've got some programmers from my

they do is say we got to throw away at everything. This is all terrible, but the good news is I've got some programmers from my last job, all bring them in and we'll rewrite the whole thing in our favorite tech stack. What they're missing here is a lot of things. First of all, usually they didn't just build MVPs and POCs, but they actually built the initial core version of their application, including encoding a lot of business logic into this application.

logic into this application. Additionally, usually the existing team members are now going to have to get booted out because A, they're not, you know, your people and B, they don't work in this new tech stack. So you now you've lost those people that you built relationship with and you've lost all of their knowledge and experience. And what happens is these startups usually end up basically regressing six to

all of their knowledge and experience. And what happens is these startups usually end up basically regressing six to 12 months as soon as they do this. And the CTO is going to promise they can knock it out in a couple of months. And they never do, like never ever once in the history of time has that CTO's promised that they can rewrite the whole thing and it's going to be faster and better and it's going to be real quick, you know, and it actually happened.

and it's going to be real quick, you know, and it actually happened. It's just not a thing that happened. So don't fall prey to this. If you have a tech stack and an application that works and it's been supporting your company up to this point, find a technical leader in that tech stack to get you through the next phase. And if you're still having trouble with that and that tech stack is Laravel,

phase. And if you're still having trouble with that and that tech stack is Laravel, hit me up. I will find you someone before I let you throw your whole thing away. Ah, the Superman senior developer. Most of us have met at least one of these people in our time as developers. That's a traditional kind of 10x developer able to handle every single problem, work in every single context, you know, work in every single language. They're amazing, right?

in every single context, you know, work in every single language. They're amazing, right? Like everybody loves them, right? A careful examination usually makes it clear that while this developer is incredibly productive on their own, they're usually incapable of working on teams or building systems that anybody but them can or wants to maintain. And it may not be intentional, but intentional or not, it's slowing down the productivity

And it may not be intentional, but intentional or not, it's slowing down the productivity in the entire team and honestly the technology growth of the entire team because they slowly take over every single piece of the technology layout until every single thing has to go through them or one of their systems. These people often talk about how much they wish that wasn't the case. You know, oh, my hours are so long, it's so hard to take a vacation. And so you maybe end up even feeling grateful that they're doing all this and

You know, oh, my hours are so long, it's so hard to take a vacation. And so you maybe end up even feeling grateful that they're doing all this and awful and rightfully so. They're probably working really hard. But in the end, your organization can't scale and it can't be healthy if so much is tied in one person. You have to work to the point where eventually every employee, no matter how productive, is

You have to work to the point where eventually every employee, no matter how productive, is not able to be the choke point for your entire organization or your company or your systems. On the other side of the developer capability spectrum, one of the most common issues I see when folks are building new development teams is that they load them full of entry level or junior programmers. And usually this is just out of a desire to get cheap labor combined with how

level or junior programmers. And usually this is just out of a desire to get cheap labor combined with how easy it is to find less experienced devs and sometimes mixed with, you know, a little bit of good intentionality for helping with the hiring pipeline and also joining in a little bit of just in expert hiring where sometimes smooth talking juniors are given roles as if they weren't juniors.

as if they weren't juniors. But in the end, you have an entire team of liabilities. They drag the small remainder of your capable programmers down. They waste money and they make the whole team look bad. And therefore, they cause all sorts of issues from there that then negatively affect the few capable programmers you actually have. And they're far too much of a force for your experienced devs to be able to wr angle them

And they're far too much of a force for your experienced devs to be able to wr angle them and mentor them, especially not while actually writing their own code. Bringing on junior programmers is great. It's a valuable action both for your team because of what they bring to you in terms of perspectives and growth potential and also for the industry and the programmers themselves. For your team, juniors are the people most likely to bring fresh perspectives because

For your team, juniors are the people most likely to bring fresh perspectives because the longer somebody's been coding, the more likely they are to be from the same background and the same set of experiences everybody else at your organization. And the industry is better because we'll never have people who make it past junior unless someone, somewhere, is willing to hire juniors. So junior programs or press programs are great, please do it. But that doesn't mean you can just fill in your entire team with them.

So junior programs or press programs are great, please do it. But that doesn't mean you can just fill in your entire team with them. It's just not going to be functional. Keep it measured. I've said this before, but one junior to two experienced programmers at most. Along the same vein, another common cost-cutting tactic employed in development teams or in place of development teams is when folks hired cheap, often offshore developers to do the work.

to do the work. And the thinking often goes, if these developers cost one quarter my normal developer's salary and they'll probably put out like maybe half the value, I've won, right, to X the productivity. Look at how economical I am, but the problem is even if those developers were giving you three quarters of the output at a quarter of the cost or even maybe the same output in

three quarters of the output at a quarter of the cost or even maybe the same output in terms of numbers of lines of code at one quarter of the cost, it's still not worth it. And there's a reason these developers are cheap. It's like buying a cheap car or cheap food or cheap clothing. It looks the same on the outside, right? But when that cheap car breaks down in two years or when your cheap food gives you heart disease, when your cheap clothing falls apart and is made of plastic, you

you heart disease, when your cheap clothing falls apart and is made of plastic, you understand why it's cheap, right? Like you're not dumb. You're capable of saying, I know that this thing is cheap because it's made of these bad materials and I've been willing to make that compromise. The same is true for hiring cheap contractors. There's a reason they're cheap.

The same is true for hiring cheap contractors. There's a reason they're cheap. The output may look fine in the outside, although it doesn't always, but they 're going to cut corners. They write spaghetti code. They build unsustainable architectures. They miss security concerns. It's not worth it. Hire capable developers and pay them what they're worth.

It's not worth it. Hire capable developers and pay them what they're worth. All right, I keep saying this, but the Mythical Man 1 is also a very common issue. This one's so common in fact that Fred Brooks wrote about it in an essay in 1975. Yes, we were writing computer programming books in 1975. The general idea is that you have a computer programming project that's running late. Let's say you've got eight programmers with two months left of deadline before

late. Let's say you've got eight programmers with two months left of deadline before months left to work. So what do you do? Will you add eight more programmers? Right? If eight of them are going to take four months and 60 of them should take two months, right? Unfortunately, that's not actually how it works out.

months, right? Unfortunately, that's not actually how it works out. As he writes in his essay, it's sort of like saying it takes one woman nine months to make one baby. So why don't we just take nine women and have them each take a month and we'll have a baby at the end, right? But unfortunately, it doesn't work that way with babies and it doesn't work that way with

But unfortunately, it doesn't work that way with babies and it doesn't work that way with computer programming. And there's a lot of reasons for this. One of the biggest factors here is because the increased costs for onboarding, for communication, for inter-dev friction just in general in terms of numbers of people, those are all issues all the time, but they're especially problematic in at the end of a late project.

all the time, but they're especially problematic in at the end of a late project. And so if you were saying, oh, we've got a rush, rush, rush, rush, rush, rush, you've got to onboard eight more people, you got to add two X the amount of communication capacity and process workflow and split the things up well. So they're not stepping on each other's feet. It just doesn't end up actually working. And while Brooks Law is primarily about late projects, and I think that is the

It just doesn't end up actually working. And while Brooks Law is primarily about late projects, and I think that is the place that is the best way for us to consider it, I think it's also very applicable in a lot of ways, not 100% to non-late projects. Each project can support only so many people, so large of a team before it costs more time and money to handle the process and the communication and the workflows than it did to actually

and money to handle the process and the communication and the workflows than it did to actually benefit you in terms of cost by the speed that you're getting from having this team. Overall, the actual productivity and speed is not increased while your costs are increased. It's not worth it. And so basically, the recommendation here would be, first of all, don't think that adding more programmers is going to make your late projects not late.

that adding more programmers is going to make your late projects not late. It's just not going to work out and you're stuck. But even on non-late projects, consider the fact that there's an ideal size for each project and adding more people is not free. And there's kind of a weight of, you know, the size that project should be before it has to get so heavy that either it can't be productive at all or it now needs to get

has to get so heavy that either it can't be productive at all or it now needs to get big enough to support that heaviness that you've added. Now, how often have you seen a company adopt microservices or Kubernetes or whatever the latest fat is just because their hero doesn't, you know, they saw a talk from AWS, which is a multi, I don't know, trillion dollar company or whatever, and they preach microservices so then we should use microservices too, right?

microservices so then we should use microservices too, right? The thing is AWS, for example, has like a hundred times more developers than you. Their problems are not your problems and so their solutions should not be your solutions. And I just like it's very clear that a team of five does not have the same issues or the same options for resolving their issues, the team of 500 has. So you need to work within the constraints and the benefits of the specific

same options for resolving their issues, the team of 500 has. So you need to work within the constraints and the benefits of the specific team you have today. So like, for example, with microservices, sure, it's great when you have 50 people working on auth alone for auth to be a separated service that they own, right? But what if auth is one of 22 concerns one developers responsible for? The only impact you make by changing the microservices for auth and other things is your deploy

The only impact you make by changing the microservices for auth and other things is your deploy stories harder, your development feature branching story is harder, your communication across your team is harder, and even individual features or bugs are twice or three times as hard to manage because you're now going to have to deploy and coordinate and synchron ize employees across four different code bases to fix that one feature. The cost and the friction of deploying development across your entire stack is

across four different code bases to fix that one feature. The cost and the friction of deploying development across your entire stack is significantly impacted. Why? Because you saw some big company doing something that doesn't make sense for you. So this is another one we've covered to some degree in previous videos, but it does merit another mention in this section is painfully common that when a company has a really strong

another mention in this section is painfully common that when a company has a really strong delineation between the product side of the company and the engineering side of the company, at some point product is going to start looking at the desires and requests of the engineering team as being more concerned with their nerdy late obsessions than with the success of the business we should all be shared in. And they are not always wrong, but the worst and unfortunately most common

business we should all be shared in. And they are not always wrong, but the worst and unfortunately most common outcome from this is that addressing technical debt gets thrown in this pile of things those nerds are always asking for instead of stuff that actually matters. And that's a huge issue for the company. The good news is if leadership is reasonable, it's usually pretty easy to con verse your way out of this.

verse your way out of this. You connect managing technical debt with reducing risk for the company and you usually can get some approval for it, but it's still an extremely common problem and one to watch out for. We often talk about shiny object syndrome as devs kind of like obsession with the latest and greatest and we treat it sort of like a ADHD hyper focus thing, right? It's like the dog and up who's like squirrel and just constantly distracted and

and greatest and we treat it sort of like a ADHD hyper focus thing, right? It's like the dog and up who's like squirrel and just constantly distracted and jumping from focus to focus. But shiny object syndrome can also be a bigger issue in the planning and architecture phases your development, not just in the day-to-day life of individual developers. It's because when time comes to decide how you're going to structure a new application or a new section of your application or whatever else, there's often a tendency

application or a new section of your application or whatever else, there's often a tendency to assume that newer technology means better technology. So we could use server-ended HTML for this front end, but obviously next JS is the answer because it's newer and better and greater and sexier, right? Like that's just what we need to do. But one of the most important aspects of deciding the tech stack for either an existing application

But one of the most important aspects of deciding the tech stack for either an existing application or a new piece of application or whatever else it is, is what is your team already familiar with? And if it's a new section, it's not just what is a team familiar with, but is what is the rest of the application built in? And I'm not saying you shouldn't ever modernize when your existing tech is at a date or that

And I'm not saying you shouldn't ever modernize when your existing tech is at a date or that your dev should never learn new technologies, but I would say air on the side of caution. If a new tool is the new sexy, it's exactly that. It's sexy, so your judgment may be impaired and a little bit less pragmatic. And it's new, so your developers aren't as experienced in it. There might not be as much support and tooling around it compared to the tools that you already have in your application.

that you already have in your application. Now, shiny object syndrome is about picking something sexy and new instead of the tried and true. But it also has a cousin, which is picking something more complex because you have a problem and your current system is simple, so obviously the answer is complexity, right? Pro tip, that's not almost ever actually the answer. Just because your server rendered system, your simple models and controllers

Pro tip, that's not almost ever actually the answer. Just because your server rendered system, your simple models and controllers and yagney system or whatever else has a problem, it doesn't mean that the simplicity is the problem or that complexity will actually solve the problem that you're having. So for example, just because your models are poorly organized, it doesn't mean you need to move to repositories, maybe just organize your models. Just because your directories are getting a bit full as your model count grows,

to move to repositories, maybe just organize your models. Just because your directories are getting a bit full as your model count grows, it doesn't mean you need to go full DDD, maybe just organize your folders a little bit better. When you run into a problem, the first step is to try and solve it inside of the existing system in the simple system that you have right now as is. Otherwise, you're just going to be bringing all the same problems you had before that

Otherwise, you're just going to be bringing all the same problems you had before that came not from the system that you ran necessarily, but from your team's ignorance or lack of effort to actually fix it, and now you're going to inject all those problems into, you know, wait for it, a more complicated system that has more friction, that takes more effort to maintain, that's harder for new developers to learn, but you didn't fix any of the problems

to maintain, that's harder for new developers to learn, but you didn't fix any of the problems in the first place. So the first thing to do is try and solve the problem in the original system before you look at anything more complicated. Similar to the tendency to reach for complexity in our code, when our simple apps have coding issues and architecture issues, development leaders also have a tendency to reach for

issues and architecture issues, development leaders also have a tendency to reach for process complexity when our simpler processes show any issues at all. So let's say you're struggling to keep on top of tasking, what are we going to reach for? You might assume that the next thing to reach for is immediately jump into hiring a Scrum Master and spending the next nine months trying to retrain the team on the Sc rum development

Master and spending the next nine months trying to retrain the team on the Sc rum development format. But instead, take a moment and lead, and I don't mean that condescendingly, but I'm saying don't delegate the figuring out what the next step is, there's a pause. Talk to your team, figure out what's going wrong and ask yourselves, can we solve these problems in our current system, just like we didn't code, you know, the client complains

problems in our current system, just like we didn't code, you know, the client complains that you're not getting enough update information about your team's process. So sure, you could immediately adopt a massively complex ticketing system that promises Pixel Perfect Burndowns and requires your entire team to rework every aspect of how they pick and track tasks, or you can ask your team to write a few bullet points and slack at the end of the day about their work.

slack at the end of the day about their work. It's not that all process is bad, but all process comes with the cost. And just because it's complicated, or expensive, or has a little trademark sign after its name doesn't mean it's actually going to solve any of your problems that you had before. And here's our final common mistake, which applies not just to development leaders but to all leaders.

leaders but to all leaders. This mistake is talking a very good game in some way or another about how the team is about your family, about how you have some kind of flexibility or understanding or bonus or whatever, something that makes you feel good in showing that you're a cool boss and you're making a good place for everybody to work. And then when it becomes expensive or difficult to actually provide that thing,

you're making a good place for everybody to work. And then when it becomes expensive or difficult to actually provide that thing, backing out. It's so fun to be the leader everybody loves when it doesn't cost you anything to be the cool boss. But you and I both know that it's just taking advantage of a system that's already stacked in your favor as the leader. If you want to talk about something you're going to offer your team or

in your favor as the leader. If you want to talk about something you're going to offer your team or something you're going to save them from, be ready up front to back up your promises when it's hardest to do so. So don't commit now unless you're willing to keep it up when it actually costs you something. And that's it, both for this list and for this course. And I so hope that this course has been a valuable experience for you.

And that's it, both for this list and for this course. And I so hope that this course has been a valuable experience for you. And something I've shared here has either helped teach you or helped validate something you were already doing or something you already believed. But you're walking away feeling like I am more capable or more confident in my leadership than I was before. If you have any questions or any concerns you need help in your journey, hit me up.

If you have any questions or any concerns you need help in your journey, hit me up. I'm @StopForMat on Twitter or if you really need some help directly, hit me up mat@tighten.com. I would love to help.