Software developers and management

Being a software developer myself, it is always interesting what I discover managing other developers. It gives you perspective into behaviours which you have seen in yourself, your team, product owners and businesses.

Software developers are seen as the mushrooms of a company – they get fed pizza and coffee in a dark room, and turn this into software. It’s also unknown what happens in this room, yet we see features, functions, new solutions and problems getting solved.

Larger organizations tend to have a development or project manager who liaises between business and IT. This stakeholder management is sometimes insufficient, as the round trip of getting the needed information could take longer than the business owner would like. 

The product owner's relationship with the developers

In some cases, it becomes more convenient that the product owner contacts the developer directly. Yet, the impact is seldomly understood.

In some cases, such as a specific incident it makes perfect sense, for the product owner to contact the developer directly, yet not everything is such an incident. For example, if one person cannot log in, it is not an incident, but if the whole company is coming to a standstill due to a system being down, it changes the scenario. 

When developers tackle complex problems, focus time is needed to get code done. It has been explained by some as ‘the zone’ or ‘the zen of programming’. In case of interruption (though only 2 minutes), this zone is destroyed. 

It can take up to 45 minutes to get back into the zone. 

I personally found it better to have a set time to get feedback from developers. all questions can be asked, but feedback should be expected at the set time. 

Time management

We know that business owners want deadlines on delivery, but few developers are able to give exact timelines, especially with constant interruptions. 

For this reason, many developer teams take the agile approach. Points are assigned to a ticket, and then a certain number of points are agreed upon for a sprint of 2 weeks. 

It happens at times that the developers work strange hours. When they are in the zone, they could work through the night and have an amazing finished feature the next morning. 

Developers can easily also lose track of time and deliver something that was never asked for. For example, adding filters on tables and making obsolete fields configurable. 


Developers like to code according to spec. In some cases, they can give estimates, but cannot see certain issues such as API integration issues and incidents that push the deadline forward

In my experience, it often happens that the spec and what the client requires are not the same. When the client is presented with the code according to spec, the requirements are changed so that it fits the requirements of the client better. In some cases, the underlying data structures need to change, and in others, UI design patterns have to be broken to accommodate the new changes. 

This tends to cause developers to make rude hand gestures and resign a job. 

To manage this is a delicate situation. It’s best to try to understand the reason for the developer pushing back. In some cases, there is a valid reason, whereas in others the product cannot function as intended without the new change to the original spec.

Finding bugs

When a bug is found, the terminology of communicating the issue is exceptionally important for a developer. One should never say things like ‘the issue is still there’ or ‘this is broken’ or type EVERYTHING in all caps. A better approach is to show the developer the problem and ask them if this is a bug – or if this is the intended behaviour. In some cases, it is how the system should function, and the product owner forgot about the business rule.  

On the other hand, I cannot deny that developers are sometimes overly sensitive and have an emotional connection with their code. To tackle this is challenging at the best of times, as this indicates dedication and personal involvement in the success of the product. 

It’s highly recommended to have a bug and issue sheet that is supplied to the developers at a given time, and not in pieces throughout the day. 

Crisis management

Incidents happen.

Some are bigger incidents than others. 

When speaking to a developer about an incident, they will be able to tell you how serious it is. Though we would like to believe that what we see is the end of the world, it might be a single case.

Developers require a lot of information to tackle a problem. In many cases, the business owner has no idea what these things are. This could include a video, phone numbers, user Ids, time that it happened, screenshots and so forth. 

If the business owner has no idea what needs to be supplied, ask the dev – but try and get as much information as possible. I find that it’s sometimes challenging for business owners to find the details required. For example, if an end-user of a mobile app is having issues, it’s difficult to call them multiple times and ask for screenshots, phone model information, app version and which brand of toothpaste they are using. 


Working with developers can be a sensitive issue. 

Managing clients can be challenging, especially when they require certain details immediately.

Finding the middle way is challenging, but is the only way to move a project forward with speed. 

Simply be effective.


Leave a Reply

Your email address will not be published. Required fields are marked *