10 Ways Managers are Wasting Their Developers' Potential

Devaluating the company in the?process

Managers and software developers often have strained relationships. This may be related to a clash of perceived realities. Many managers strive to maximize the capacity of their teams. Developers grapple with the complexity of building software products.

This clash of realities is an important reason for many harmful interactions between managers and developers.

Here are ten ways managers are wasting their developers' potential. Grab your bingo card and check how many are a reality for you!

1. Making promises to stakeholders without the developer’s consent

Let’s start with this gem:

“Good morning! I just had a meeting with our client. They want us to build their onboarding app. We agreed to have it ready at the end of the year.”

Whenever you hear a manager uttering such sentences, you know you are in trouble. Someone else made promises you have to keep without your consent.

As absurd as it seems, it happens all the time. The prospect of generating more revenue is too alluring to refrain from promising things that are way out of order.

2. Defining the?solution

Many managers used to be developers themselves. What they absolutely should not do, is continue playing that role. It’s not up to them to determine how the software is to be built.

It is truly demotivating to be told to build the software in a certain way. Even when the manager merely does this as a proposal, this may be toxic due to the power dynamics. Not every developer will openly argue with the manager.

Even worse are the managers with no software background, but still have the audacity to propose solutions. How do they get it in their heads that they would have more know-how than their developers in their speciality? Not to mention the fact they stepped over the line of their own responsibilities.

3. Persuading developers to reduce the estimates

It always baffles me how managers can doubt the estimates of their developers. Normal behaviour would be to accept the developer’s assessment of the complexity of the work and the efforts to create the software.

But many managers believe it is in their right to tighten the screws and start a bargaining game to reduce the estimates. This is wrong in many ways:

• it dismisses the authority of the developer on how to build the software
• it is a sign of distrust
• it puts pressure on the developer to reduce the estimates

When managers start this game of haggling, the consequences are disastrous. And developers will be the victim of the power game.

4. Considering estimates to be?promises

Before a company decides to invest time, people and money into an endeavour, it is logical that there’s an understanding of whether the investments have a decent shot at being worthwhile.

In predictable environments, where you know what needs to be done to achieve the intended results, you can do a thorough analysis and then have a good understanding of the expected investments.

As an example of a predictable environment, let’s look at building a house. You typically start with an architect making a design. From this, it is possible to understand what needs to be done in what order and for what costs to build the house.

This traditional way of creating a thorough design, followed by a detailed plan which is followed meticulously, doesn’t work for software products. Because software development is complex work and software products reside in a complex domain.

And in complex domains, you don’t know what will happen. You may have an idea of how much work it is to create a software increment. But most of the time, you will see that your estimate is not in line with reality.

You need to embrace the uncertainty and verify your assumptions regularly, rather than holding on to the estimates you made before you knew what you learned. As a result, estimates can never be considered to be promises. Only as the best guess of the work at hand with the limited information you had at the time.

5. Allowing people to disrupt the developer

Software development is creative work that requires focus and time. A developer works best when uninterrupted. Every time developers are interrupted, they are taken out of the momentum of their work. Apart from the time the interruption takes, there’s also the added time it takes to get back into momentum.

But time waste isn’t the only issue of disruptions. It also impacts the morale of a developer. It is frustrating to be pulled away from your work this forcefully.

Managers that allow interruptions to happen on a regular basis may not realise how impactful this is. But they better learn quickly as it is a major morale killer.

6. Adding work on top of the planned?work

Whenever developers commit to working on a set of activities or achieving a specific goal, it is bad style to add stuff on top only a few days later. What’s more, often the manager has the audacity to expect the team will continue to commit to the original plan and also to the extra work.

Sure, there may be new insights that may impact the plans. But this should not result in extra work and as a result extra pressure on the developers. There should be a trade-off. Something needs to drop first before other work can be added.

This may look straightforward. But somehow, managers everywhere continue to do this anyway. Which is mindblowing.

7. Asking for quality shortcuts

Software development is complex in nature. And this means that you will learn something new while doing the work. New insights that have an impact on the planning. And in most cases, this will lead to unexpected additional work.

The new learning due to the complexity will have an impact on expected delivery dates. You could do something about it by reducing the scope, and delivering less than planned. But I have seen many managers respond in a different way, by asking to skip portions of the work, often the testing.

Arguing that the developers know what they are doing and testing generally doesn’t uncover many errors, they are asking for quality shortcuts.

By asking for quality shortcuts, these managers ignore that a working quality product is more important than delivering “in time”. Delivering a faulty product in time will haunt you in the end. Your users will not be happy.

8. Pushing to work?overtime

Another alternative to aim gaining time is to work overtime. Or such is the reasoning of many managers. But this is ignoring the fact that working overtime may push the developers beyond their limits.

Developers should work at a sustainable pace. This is a pace of work that allows them to be effective. Pushing them beyond their sustainable pace will unavoidably lead to errors, leading to rework and eventually delays.

Pushing people beyond the sustainable pace will not make them faster. And on top of that, you run the risk of burning them out.

9. See failure as bad, not a?learning

I have many unpleasant memories of having to tell my manager that we had to delay our delivery date due to something unexpected while we were developing our product. And then getting a lecture that he expected that I would be more professional.

Software development often is complex. It is a creative process where the developer will learn along the way. Assumptions you may have had at the start of a journey may prove to be incorrect. And that is fine. It is all about learning and then adapting to incorporate the learnings.

Too often, managers see these learnings as failures. The developer should have analyzed the topic better to avoid unexpected setbacks. But in a complex environment, you don’t know what will happen. It’s impossible to predict. And every new learning helps to move towards the goal.

10. Taking the?credit

And then, when we are at the end of the journey, having delivered the software solution to the client, the manager takes all the credit. Without them, this would not be a success.

They will be sure the customers and the organisation know this. Their role will be largely overstated at the cost of the developers.

Don’t put up with this behaviour!

Are you a developer and do you recognize your manager? Don’t put up with this behaviour and demand change. Because these anti-patterns aren’t only hurting you, they are also hurting the company. Because this is not the way to create value and help the company grow.

You may have people that can help you to bring these changes. Perhaps there’s the option to align your Scrum Master or an agile coach.

Are you a manager and do you recognize this? Are you also killing the creativity and autonomy of your developers? And hurting the company in the process? It’s not too late to change. Embrace the notion that software development is complex work. And foster your teams instead of bullying them. I guarantee you will see the positive results quickly.