To build a healthy, productive culture for your devs, it helps to first identify behaviors that can have a negative impact. Even with the best of intentions, certain anti-patterns can contribute to a toxic culture and result in lower developer productivity.
Here are 15 engineering leadership anti-patterns that might be inadvertently hamstringing the success of your team:
1. Expecting bug-free code
When perfect code is the expectation, developers become more worried about messing up than building a successful product. This has the unintended effect of creating fewer PR releases as devs are holding back instead of shipping frequently and continually improving.
Bugs and broken code are normal parts of the development process. In fact, they’re expected when dealing with tight deadlines and expedited delivery. In most cases, the “wrong” line of code delivered on time is better than the right line too late.
That being said, technical debt can become a real problem for dev teams as more interest builds. One study found that the average developer spends 42% of their time on tech debt, with the cost of bad code coming to $85 billion annually.
So you shouldn’t expect perfect code, but you also can’t afford to let the tech debt build up. That may mean increasing headcount or adjusting expectations about what your team can deliver within a given timeline. Look for improvement opportunities in your process rather than just expecting perfection from your devs. There will always be mistakes, but they’re a necessary part of innovation.
2. Punishing failure
Failure is a necessary and inevitable part of the software development process, and it helps developers learn from their mistakes. Engineering leaders often fail when they set a hard line between failure and success. When you punish those who stray into failure, it sets an example for your other devs. They’ll stop taking risks, and they may even quit.
Or instead, you can welcome failure as a learning opportunity. It shouldn’t be ignored or sugar coated, but it should be embraced. A blameless culture is more conducive to meaningful developer growth. Give your devs autonomy, but keep them accountable. Devs should feel safe enough to fail and encouraged enough to keep trying.
3. Sidestepping their request process
This kind of behavior sends a signal to your devs that your time is worth more than theirs. If you need to put out an immediate fire, make that clear to the team, and thank them for the quick response. But if it can wait, go through the appropriate channels such as opening a Jira ticket. There’s a request process for a reason, and bypassing it can feel disrespectful to your engineers as it disrupts them from their high-priority initiatives.
4. Interrupting their deep work
When starting or resuming a task, it can take some time to get back into the swing of things. This is especially true for software developers, who are more impacted by interruptions than other professions. It can take them even longer to regain context and resume a previous activity. The constant change in focus can also leave devs feeling drained of energy. We call this context switching, and it can really hurt your team’s productivity.
That’s why it’s so important to protect deep work time. Devs need uninterrupted time throughout the day to solve tough problems and build amazing features. Without it, they are more likely to adopt unhealthy work habits, ultimately leading to burnout. We recommend at least two-hour blocks for Deep Work.
5. Micromanaging them
Devs want to be trusted to do their jobs. Any sign that that trust isn't there is a critical sign of a toxic engineering culture, even if the intention is just to help. Instead of micromanaging your devs, set clear expectations, provide the tools and information needed to fulfill those expectations, and trust your people to get it done.
Software engineers are often told what to build and how quickly to build it, with little discussion about what it will actually take to get it done. Trust that your devs know the best way to make something work, letting their knowledge help guide your projects.
6. Abandoning them
Giving developers autonomy doesn't mean leaving them alone and never checking in with them. In reality, that can cause feelings of isolation, lessen visibility, and increase knowledge silos. Some engineers want leadership to just get out of the way, but others want more active guidance on team processes and individual growth. (The latter is more true for junior devs, as our seniors tend to fall into the “get out of my way” category.) Work with your team to find out what autonomy means for each dev, adjusting your communication to their style.
7. Being indecisive
Gray or dark gray. The question has plagued your mind for weeks, annoying your devs in the process. If you care about your devs’ time, make up your mind and get to the point. Don’t drag out changes. Need to change a color? Just write a ticket that says, “change color.” Devs don’t need long essays or back-and-forths. They just want to know what needs to be done.
If you’re shifting priorities, making mid-sprint design changes, or adding work after planning is complete, you risk angering your team and throwing off their work. Scope creep also puts pressure on your devs to get through a higher volume of work, which can compromise quality and lead to bugs. If you must, make sure to adjust the project scope to account for them. You may still upset your devs, but at least you’ll be following the scope change process.
8. Disregarding their business impact
Non-engineering business leaders have a tendency to isolate developers from the world beyond their code. The longer they stare at code on a screen, the more disconnected they’ll become from your business objectives, which contributes to a toxic engineering culture. In time, they’ll start seeing things in components and PRs, unaware of how they’re contributing to the product.
Though many devs are content just living in the code, they also want to feel like part of the “big picture” and see how their work is contributing to team and company success. Failing to connect their efforts back to business and team goals could leave them feeling isolated and unfulfilled, contributing to burnout.
Try to find a healthy balance between tedious tasks and projects that feel more meaningful. Recognize work on things like bug fixes and their crucial role in keeping the business running, while providing additional opportunities to work on projects with more visibility.
9. Excluding devs from decision making
Devs want to be included in conversations about their work. By making changes without consulting your team, you risk alienating them. They might feel like they lack control and that their voices don’t matter in the process. Including developers in early project discussions gives them a say in the amount and type of work they’ll be doing, which helps keep them accountable. It also gives them an opportunity to point out hidden implementation costs, design challenges, and synergies with other projects. Be as transparent as possible throughout the process to make your devs feel included.
10. Wasting their time in pointless meetings
It’s difficult for devs to fit in deep work when their calendars are clogged with meetings. Some meetings are necessary and serve real value, but others can drag your devs through hours of meeting hell. It’s not the meetings themselves that they can’t stand — it’s the waste of time. Consider the following tips to keep your meetings relevant and minimize workday interruptions:
- Avoid “FYI” meetings for your team. If they don’t really need to be there, or you can give them the notes afterward, then don’t invite them.
- Limit cross-team/all-hands meetings, and rotate members so not everyone has to attend.
- Truncate meetings by five to 15 minutes. It will give your devs time to transition between meetings while helping create a culture of brevity.
- Remove short fragments. Schedule meetings closer together to avoid gaps and free up longer blocks of time for deep work.
11. Canceling 1:1s
As you rethink your meetings and get rid of those that aren’t serving a purpose, consider this tip from our devs: don’t touch the 1:1s. Done well, weekly 1:1s provide a valuable forum for career planning, roadblock removal, and big-picture thinking. They should be held regularly to establish a greater sense of rhythm and importance.
If you need to cancel, make sure you reschedule. Just don’t write them off as less important or come unprepared. Work with each dev to set an agenda prior to the meeting.
12. Giving them too much/little work
Devs don’t want to be overwhelmed with work, nor do they want to be bored. Too much work can wear them down, eventually leading to a drop in productivity — and worst case, burnout. Too little can leave devs feeling like they’re just wasting their time — also leading to burnout and a toxic engineering culture. The secret here? Appropriate time allocation.
Your devs also don’t have to be overloaded with work to burn out. Feeling like they’re not doing enough to make an impact can also leave them depleted and apathetic. Try giving your devs more say in the amount of work that they’re doing. Including them in early project scope and allocation conversations can help them feel more empowered and accountable.
13. Assigning them only unfulfilling work
Most devs want to work. But they want that work to be engaging and purposeful.
You won’t get a dev’s best effort if they’re only working on bugs or KTLO activities all day. You have to balance these often less desirable tasks with more meaningful, high-impact work. Create opportunities for them to get more involved in projects they care about. They’ll be better engaged and grow in the process.
14. Giving them unrealistic deadlines
Of course you want it tomorrow — everyone wants everything right away. But between the meetings, messages, new dev interviews, and more, something has to give. Ask your developers what they think is realistic. Either extend your deadlines to give them enough time, or create space on their calendars by replacing unnecessary meetings with deep work blocks. You can also cut scope by deferring some of your product features if necessary.
15. Taking them for granted
Even in tough economic times, qualified devs are in high demand. Check in with them to make sure they’re still getting the most from their work, and have open, honest conversations about their impact and goals for the future. You can’t stop all of your devs from leaving, but you should still try. Don’t make the mistake of thinking they won’t leave or don’t have other options.
Want to retain your devs and keep your teams efficient? Now you know what not to do. Taking steps to build a healthy engineering culture is critical. Check out some additional resources below designed to help engineering leaders enable their teams to spend more time on important work.