Top 5 Mistakes That Make Developers like Their Managers a Little Less

September 24, 2015 Guest Authors of WhiteSource

Software development is a team effort, but software teams are made up of managers and developers.

All’s well about being a part of one big productive team, but friction begins to surface the moment the players, managers and developers, start chasing their goals. While both groups work towards accomplishing a joint mission, their goals (surprisingly) don’t always seem to align so much with each other. A developer might worry more about hitting deadlines, while a manager will think hard about meeting business objectives.

Such conflicts are common, and if they are not handled properly, they can have a serious impact on the motivation of the software developers and the overall company business.

In this post, I’m listing the five biggest mistakes that managers can make to create friction with their software development teams.

#1 Using Estimates in a Destructive Way

As managers, we need to know how much it costs to do something and when we can expect it to be done. And that’s why we ask developers to give us work estimates. We use these estimates when we figure out the budget, scope, and schedule of a software project.  This approach has two problems:

1. Estimates are only estimates

Even you know that your developers have no way to know for sure how long they’ll take to do a job. There are things that aren’t under their control — like unexpected issues among all the other things. Even your most experienced and trained developer will face this issue while giving an estimate. Sure, they will give you a crude idea of how long it will take but can’t tell the exact timeframe as technical problems are unpredictable.

Further, if you happen to consult a developer who’s not familiar with the problem domain, you cannot rely on his/her estimate as he/she has no problem domain knowledge.

2. Developers know their estimates will be used to set their deadline

One main reason for seeking estimates is to set deadlines for your team. Since your developers know that, and they also know their estimate is not accurate, they usually multiply their real estimate by some X factor. This “X” is their estimate of risk in a project delivery. This issue can be minimized if you can get your developers to trust you to not abuse their estimates, but it’s part of our human nature to protect ourselves.

Moreover, if a subcontractor is also a part of the scenario, you can further expect a bureaucratic management process (and a lot of “X” kind of variables in the estimate equation).

What you should do: Estimates can be a useful tool for managers, but it does not encourage cooperation.

Setting a deadline is a way to tell the developers that they need to get the product ready to ship by then, and it’s actually a great way to motivate them to get things rolling. But if the developers have to play hard to catch up, they might start cutting every corner. When this happens, they write code that is hard to maintain because it’s full of hacks that helped them to meet the deadline that you  set. This means that while the current deadline will be met, adding new features and maintaining the existing features could become slower.

I think we should find a better way that emphasizes cooperation, and I believe that #NoEstimates can provide answers to some of our questions.

#2 Forcing/Forbidding Automated Tests

Automated testing is a topic that can cause a lot of friction between us and our developers if we don’t handle it properly.  There are two main approaches:

1. Meeting a test coverage goal

If we force developers to write automated tests because we “must have” 95 percent test coverage, they will meet our requirements, but their tests might not be as useful as we think.

One classic example of an automated test that is written only to satisfy a code coverage limit is a test that doesn’t assert anything. Such tests don’t mean anything because they can fail only if the tested code throws an exception. The problem is that the tested code can fail and not throw an exception. Another reason is that they give developers a false sense of security because the only way to know that a specific test is useless is to read its source code, and developers don’t do this (if they don’t have a reason to).

Our decision to get 95 percent test coverage can frustrate our developers who end up wasting a lot of their time writing meaningless tests simply to reach the code coverage limit.

2. Let QA worry about testing

If we forbid developers to write automated tests because writing them takes too much time, and we think that testing belongs to the QA department, our developers will end up shipping legacy code from day one. This might sound a bit melodramatic, especially because our developers seem to be very productive at the beginning of our software project, but my experience has taught me that if our application has no automated tests, its code begins to rot over time.

This will dramatically increase the time it will take you to release new features or fix bugs. The signs are that your developers cannot change existing features or add new features as fast as they used to and that most changes cause bugs that are noticed after the application is deployed to the production environment or during QA testing (no early discoveries).

What you should do: Our mistake is to think that our developers are more productive when they don’t have to spend any time writing automated tests. Or, assuming that 95% test coverage will lead to a high-quality product.

At the beginning of a software project when the code base is small, and the developers don’t have to touch the code that is written by other developers, automated tests do not seem very productive. When the code base gets larger, and the developers have to start modifying unfamiliar code, the code base of our application starts to rot, and you need automated tests to maintain your code.

If you share the reasons behind your decisions with your developers and let them decide the required level of automated testing for each stage, then you should find the most productive approach for automated testing. You should also be sure to give them enough time to implement it when budgeting your project.

This way, your developers will be aware of their requirements (e.g., schedule, ROI, assume responsibility for their code quality and can decide how they wish to meet these goals. I have noticed that if we give our developers this opportunity, they’re happy to oblige.

#3 Forcing Developers to Ignore Technical Debt

Sometimes, too often, we find ourselves in a situation where we have to ship some features ASAP. This means there’s no time to write automated tests and/or refactor our code.

Obviously, our developers immediately complain that we are ignoring the technical debt and this will transform our application into an unmaintainable bowl of spaghetti code. As managers we know that sometimes the business need justify this ( e.g. beating a competitor), as long as this is a temporary situation that lasts only a few weeks or months.

But how can we get them on-board?

What you should do: Instead of giving exact instruction of what they can and cannot do, explain them that we must ship these features after X weeks or months, and let your developers decide how they will do it. Odds are that your developers are ready to write less automated tests and do less refactoring, but if it’s their call and not something that you enforce, chances are the quality of your code will improve and your team will be more committed towards meeting the deadline.

#4 Taking Technical Decisions Away from Developers

In the end, the manager is responsible for selecting the right technologies to use in a software project. This is why some of us think that it’s a good idea to take this decision away from our developers and give it to architects or *gasp* ourselves. This is an awful idea!

Taking this responsibility away from the developers can:

1. Demotivate them

Most developers will feel they are transformed into typewriters who crunch code which pleases the person who makes the final call and not part of the team. Chances are that they will write ‘good enough’ code, but nothing more.

2. Does not encourage them to learn

If you developers will feel they have no say over your technology selection, why would they want to learn new things? 

3. ‘Foremen’ cannot be experts

‘Foremen’ cannot be the technical experts like their team members and their technical expertise is usually outdated and/or narrow. If ‘foremen’ will choose technologies, it is more likely we will find ourselves with legacy technologies that are hard to maintain and make our recruitment a lot harder.

I argue that we need more foremen. Instead of turning the managers to technical experts, let’s turn our technical experts to mini-managers in terms of responsivity and accountability. Making every team member to a ‘foreman’ may sound like utopia, but I have noticed that if we give more responsibilities to our developers, they can outperform themselves.

What you should do: as Spiderman says “with great power, comes with great responsibility.” If you give your team the power to select the technologies for a project that will affect their daily work, they must also be responsible for their decisions. This means that if they decide to use a new technology, they have to train the other developers to use it or maintain the application themselves. This will lead them to master this technology and invest greatly in finding the right technology. My experience also shows that you are more likely to use innovative advanced technologies if your developers are calling the shots vs. the managers.

#5 Being an Absent Product Owner

As team managers, we have to own up to our projects. And once we fit ourselves in the role of a product owner, a common mistake that we could make can be to become an absent one. Because an absent product owner doesn’t maintain the backlog and define the acceptance criteria of the backlog items, your team members will have to take care of these things. This causes several problems:

  • There is no clear product vision. Because no one takes the responsibility of the product, the shipped product is a combination of ideas that are gathered from different sources.
  • Developers aren’t as productive as they could be because they have to spend a lot of time waiting for answers to their questions that help them specify the acceptance criteria of the backlog items.
  • Because no one’s actively tracking a product’s development to closure, it cannot be released on time because it might not be ready. Typically this also means that the budget gets exceeded.


What you should do: if you don’t have the time to be a proper product owner, then you must give this role to someone else. This is the sensible decision since failing as the product owner means failing as a manager, but delegating your authorities can only strengthen your position.

Now that we’ve looked at the possible mistakes that we’ve made (or perhaps still making), it’s time to look at the one big factor that can make a big difference.

All we need is trust

We, as managers, are responsible to ensure our team meets their business goals. Sometimes, under pressure, we tend to assume full responsibility (perhaps more than we should) and make technical decisions instead of our technical employees (the developers) and therefore discount the capabilities of our developers.

If we just do what we do best, i.e., manage, and get the developers to feel empathetic towards us, we can create the most productive and successful team. It all starts with trust and accountability with and within your team. Let your developers take the call and trust them to stand by it and make it happen.

Don’t forget that it’s a team’s game at the end of the day. And you’re leading the wagon.





Previous Article
Are All Bugs Shallow? Questioning Linus’s Law
Are All Bugs Shallow? Questioning Linus’s Law

In Eric S. Raymond's seminal essay on open source, The Cathedral and the Bazaar, he defines Linus's Law, wh...

Next Article
Top 10 Open Source Myths Busted
Top 10 Open Source Myths Busted

Open Source has been in commercial usage since the 1970s, but sometimes the picture painted by the media te...