Well, planning is a common one. It's rare that teams actually manage to estimate the time needed properly, so projects end up overrunning like crazy. To some degree this is inevitable (software planning is hard after all), but for the most part, it's due to poor planning, failing to push back on developer estimates and generally not understanding the work needed.<p>Hence we get things like:<p>Manager: Hey Bob, how long is this new feature going to take?<p>Bob: 2-3 days max<p>Manager: Okay, 2 Jira points it is<p><i>2 weeks later</i><p>Manager: Bob, where's the feature?<p>Bob: Well, the library we use didn't have the feature we thought it did, and there were more features in the brief than we imagined, and browser compatibility was mixed for the JavaScript API our code depends on...<p>All of this probably could have been caught during the planning stages, but it wasn't.<p>Other things they often get wrong are:<p>- Not knowing what the client actually wants, or letting themselves get sidetracked by constant feature requests. Seen plenty of projects sink into the abyss because days were spent building the wrong thing, or overly optimistic sales guys promised the world and management didn't push back on it...<p>- Not checking in on the work people are doing, and letting projects fall apart. It's obviously a fine balance between 'checking in with people too often' and 'checking in with them too rarely', but I've seen team leads pass off work to individuals/small groups, then fail to check how things are going until everything's on fire and 2 weeks behind schedule.<p>- Not being willing to teach or train staff. Obviously you need to be qualified enough to do the job, but there should be chances for growth anyway.<p>- Not hiring enough staff. This is often a sign the company is floundering or layoffs are on the way, but if ex employees aren't being replaced and no one's been brought on in years despite a growing workload... that's probably not great leadership.<p>- Not getting staff out of their comfort zone/giving people a chance. This is something I've seen with teams where 1 or 2 people are classed as senior devs, and lots of others are classed as junior ones. The former get all the challenging, interesting work, while the latter get saddled with the boring gruntwork. This hurts the latter's career prospects big time, and gives the team a high bus factor due to the overreliance on a few 'star' performers.<p>- Micromanagement in general<p>- Hiring people who aren't the right fit for the team/work, or who aren't qualified for the role in question<p>- Not firing people who are underperforming, or toxic. The latter is probably worse really, since not only does a toxic environment put people off doing their best work and make good employees want to leave, but the negative consequences of the toxic individual leaving are often way overblown. Yes they might be popular or talented or someone you've personally been friends with for a decade, but they're definitely not irreplacable.