A Software Development Manager’s Guide To Beginner Mistakes

R&D managers, when first stepping into the role, tend to make the mistake of choosing one of two extreme management approaches. Each of these comes with its own set of challenges – and its own set of organizational waste. And that’s the last thing you want to create as a manager.  

So if it’s your first time as a manager – or you simply feel like brushing up on your dev managerial skills – how can you keep delivering awesome tech for your company while keeping your team safe?

Understand Which Approach You’re Dealing With

When it comes to software development, dev managers, when first entering the role, tend to adopt two common types of ‘anti-patterns’, or as we’ve dubbed them, ‘bad management practices’. These are commonly used processes, structures, or patterns of action that often seem legitimate and easy to learn from but are usually counterproductive and ineffective (i.e. spaghetti code or God class). The more we know these, the better we can learn to handle them. These two patterns are:

1. The Guardian –  this manager does everything to protect their team from anything outside of the R&D

2. The Pleaser –  these managers focus on having their team deal solely with putting out fires for the rest of the company to keep everyone happy.

For obvious reasons, neither of these is ideal. 

The Guardian

This persona in this bad management practice is called the guardian. Their team is their top priority. They focus on preventing interruptions that waste their team’s time on any other issue than the internal work of their team, such as fixing bugs immediately or joining a meeting with a client that requires more technical knowledge. Typical examples of the way they speak often sound similar to: “We’re building features here”, “R&D is expensive”, or “let us do our job.”

This type creates external organizational waste as well as internal R&D waste. Not only do they create a situation in which other teams aren’t being supported – causing others to search for workarounds that often take more time and resources – but also create a situation in which they aren’t helping deal with the actual fires that pop up in the R&D team itself.

The Pleaser 

This is the other extreme, in which the manager prioritizes new requests to keep building relationships instead of his team. This kind of behavior includes actions like fixing bugs that are not urgent, supplying a quick response to every client, etc. This type of manager believes that his team can – and should – fix everyone’s problems. You’ll often hear them saying things such as: “Oh, that sounds urgent” or “I’ll deal with that immediately.” 

When we speak about relationships, we know that every type is different. However, here we are specifically speaking about internal work relationships. For example, how relationships between R&D members differ from relationships with colleagues surrounding R&D – account managers, support engineers, product, and even sales. These external forces obligate managers to consider their opinions and current needs. 

This managerial type will probably create internal organizational waste for his team. One of the effects of this waste is R&D burnout, which in turn will cause the R&D team to handle less of the load from other departments. Another effect of this managerial method would be the growth of technical debt. 

We can see that in the long run, the aim to please will actually harm those same departments. It can also create an unfulfilled roadmap that prevents product innovation and create a lot of internal waste.

Natural instincts 

At some point, tensions will arise between making the company happy, keeping your team safe, and doing that without littering everywhere. As a new manager, facing unexpected urgent challenges can cause a lot of pressure and sometimes can even make one feel attacked in a new relationship. This unknown situation brings us back to examine our basic instincts: fight, flight, and freeze.

The two first mechanisms help us adopt an immediate reaction without any further thinking. Imagine for a moment you’re in the middle of a jungle with a lion in front of you. This unexpected stressful situation forces you to react immediately to save your life. The first option is to immediately run away or fight the lion. It requires a quick, unconscious response. 

Similarly, going to these two extremes as a first-time manager helps us decide how to react and whether to fight the threat or run away. There is a third choice of freezing and doing nothing, but obviously, that’s not recommended in the slightest. 

Finding the middle ground

Managing is ever-changing and stressful, primarily for new engineering managers. Falling into the embrace of one of the two ‘bad management practices’ is easy – especially when they look like success. Yet, to not only solve – but get ahead of – these problems, we need to understand exactly what we’re working with. There’s no reason your organization should suffer just because you don’t have all the cards out to play. 

So what do we do? First, take a look at the reasons that a manager tends towards an extreme. Did they decide to become a manager to care mostly about their dev team? Is important for them to fix the organization’s problems? Then, understanding the root cause enables us to think of the messages we’d like to transfer to our team and colleagues and try to change this tendency. 

Being aware of these mistakes can help turn you (or finetune you, since obviously, you’re awesome) into a better manager and ensure your team – and company – are always performing at top velocity.