Your Developer is not a Single Point of Failure

During my years as a coder, business analyst and technology consultant, I have heard many a manager or business owner complain about their on-staff developer. I have even sometimes heard them referred to as a “single point of failure.” At that moment, I know that I am entering a political minefield. My years of experience alert me to the fact that if someone in power thinks their developer is a single point of failure, then most likely the developer is not being properly managed.

There has always been some tension between the “knowledge” workers and management. It is why software development methodologies, like Scrum, Agile and Waterfall, came into being. However when the developer is being demonized in this way, it often indicates the business’ user base is not being properly managed either. It can also mean the person making the reference is themselves the single point of failure.

After all, developers, encode business processes and keep the business from being held hostage to arcane workflows and procedures known only to “special” individuals. Instead, processes are written down in code. The business owns the source code and can hire other developers to work on it if they so choose. Developers are not single points of failure. Developers prevent single points of failure.

Developers mostly only write what they are told to write when they are employed at a business. If what the developer is producing is not what the business wants or needs, then it is EASY to blame the developer. Otherwise more important individuals may have to take the blame for poor focus on goals and poor leadership. If the developer has been on the payroll for any length of time, it seems unlikely their production does not in fact help the business. There is just tension and potentially lack of focus on both sides of the equation.

This tension makes these early meetings with possible clients fraught with danger. You as the software development consultant do not want to blame the business owner for their problems. At least not if you expect to land the contract. Navigating these issues can be quite trying.

What are you going to do as a consultant who has been brought in to streamline and diagnose issues in the applications of technology for a client? Unfortunately, you are now pretty sure the client themselves is responsible for the chaotic situation in their technology department. How can you get the confidence of the business owner without alienating the on-staff developer by buying into the “single point of failure” blame storm?

You will assure the business owner or manager that having an on-staff developer is a godsend in the 21st century. A well-managed developer is worth their weight in gold because they are steeped in your business model. The on-staff developer understands your business and the workflows therein.

Given proper guidance on priorities, the on-staff developer can deliver SO much value, but proper guidance comes from leadership. That means as the consultant you will need to manage the business owner and/or managers as much or more than the on-staff developer. The ideas of servant-leadership become very important here.

For the developer to be successful, they will need clear mandates. The developer needs unambiguous priorities so that they can manage day to day requests along with longer-term projects. This is where the Agile/Scrum software development methodologies come in handy.

Sprint meetings give visibility on the business’ priorities to the developer. Sprint meetings function to keep leadership on track as well because leadership will be forced to COMMIT to some tasks for a given sprint. The daily stand-ups provide visibility to managers and users of the progress the developer is making. This visible progress begins to breed greater trust between developers and users.

The greater trust is what yields the results. Engagement by leadership helps create trust as their mere presence makes others feel they are engaged in important matters and the business cares about these matters, but also cares about them. Face to face meetings are more important than just about anything else in building trust.

All things are possible when there is trust. You as the software development consultant are trying to create an environment of trust. A work world where there is trust from top to bottom usually leads to successful implementations all across the business. Since it is the 21st century, trust in the tech portions of the business can propagate to every level of the employee base. This is how successful organizations can grow and thrive.