Here’s something that has bothered me for a while – being able to manage a software team which involves keeping on track with new developments whilst still supporting our existing customers.

First, a quick look at the history of the team and how we have managed these needs, then I’ll describe our current situation and add my thoughts on what we should be doing.

Many years ago, I worked as part of a software development team who worked on development contracts for customers. This placed emphasis on specifying the work to be done upfront, producing defined deliverables and test plans to confirm acceptance. Support involved agreeing to fix any reported defects for a fixed period – typically 6 months from delivery. Anything extra was chargeable and generally that was enough to stop any further support requests. One theory would be that we wrote better software “in the olden days”, but that isn’t one I would subscribe to.

The big change for the company and the development team was producing our own product. Initially, this was sold through a 3rd party who did a fantastic job of documenting, installing and supporting the product that whenever a defect came through to the development team, it had already been investigated, diagnostic information collected and was ready for a developer to resolve.

Once that layer of support was removed the quality of defects rapidly declined and developers had to get more involved in just figuring out what the issue was. Resolutions often just involved informing the customer of the correct way to perform an operation or the need to adjust external components not provided by us. However, we didn’t have many customers and this extra load was not too much for the team. We could offer amazing levels of support – just imagine ringing a company and being able to speak with the company expert (the person who wrote the software) about your particular issue!

This was fine for a while until we got too many customers! We couldn’t handle the amount of questions coming in without seriously affecting our ability to develop new functionality. We lacked the documentation, the installation skill and the support personnel to deal with this load.

I’ve outlined the 3 issues right there, so addressing those should be easy right? Wrong! It’s a huge cultural change to address those issues. We have taken steps in the right direction, but we still have a long way to go. We have an Operations Manager with a dedicated installation team and a full time support team. We have a Pre-Sales team to help bridge the technical gap and prevent some of the installations issues before they leave the design stage. We also have a Product Manager to help address the lack of documentation, but the increase in customers is happening quicker than those new roles and teams can keep up with.

Some indication of how much of an issue this has been can be seen in my previous post on changing managers. The first Operations Manager didn’t have enough of an impact and so we are now trying a second manager.

As part of the support team we have 4 developers seconded to the Operations Manager. This creates an issue, how does the Operations Manager manage software developers? Isn’t that the role of the Software Development Manager? Perhaps a more helpful question is why does the Operations Manager need a team of developers at all? Well, our software isn’t perfect, so we accept that a certain level of development is required to address the needs of our customers, but that still doesn’t answer the question.

The reason the Operations Manager needs software developers is that Operations is woefully under staffed. We are using developers to investigate and resolve issues that don’t need a developer to resolve. We are asking them to answer the telephone, we are asking them to fill in gaps in the knowledge that should have been documented, we are asking them pre-sales questions, we are only partially using them as developers.

But isn’t support and the happiness of our customers important, so don’t they deserve to talk to the experts and not a clueless call centre operative following a script? Sure, if you can afford to do that, then go ahead, but as we’ve seen that way of working doesn’t seem to scale. However, I believe a customer would be equally happy talking with a specialist skilled in the art of communication who is equally capable of resolving their issues. It is those 2 skills that a customer requires – good communication and the ability to resolve their issue. Communication is not always a developers strong point and many issues do not require code changes to resolve.

We have a Product Manager tasked with delivering functionality into the product, but they have no developers with which to do it. So, why would an Operations Manager tasked with installing and supporting our customers need developers? The simple answer is they don’t.

We should recognise this issue, recognise that the time of developers covering support is over and make plans for moving them back where they belong – under the control of the Software Development Manager. To do this requires a drastic increase in personnel in Operations. Emails should be dealt with on the day they arrive – not 2 weeks later. Customers shouldn’t have to ask 4 times for a status update – they get them when they have been promised, and developers can once again focus on resolving faults that have been thoroughly investigated and documented.