How to Make Sure Your Developers are NOT a Single Point of Failure

When I wrote "Your Developer is not a Single Point of Failure" there was definitely push back from managers, suits and other C-Suite denizens. Without a doubt, developers can be single points of failure. I would be lying, if I did not acknowledge the "historical blame" lies mostly at the feet of developers for the belief coders are single points of failure. Too many software developers built ivory towers of code for the sake of job security. Too many businesses were held hostage to custom algorithms only a handful of people could decipher...perhaps only ONE person could!

An answer on how to prevent this and not get taken advantage of by unprofessional or unethical developers launched many software development methodologies, design patterns, and project management careers. This blame drove most small and even medium-sized businesses to outsource development, integration and automation to consulting firms and contractors. An on-staff developer became a very expensive luxury for most businesses. There was just too much overhead to supporting development within the business.

Nonetheless, the on-staff developer when properly engaged and managed still remains an incredible luxury. The synergies which are possible with on-staff development are marvelous. Nonetheless, properly managing a developer can be difficult. There are many things which can make management difficult, and the most damaging are unethical developers holding businesses hostage to their spaghetti code algorithms. However, in 2020 it is far too easy to prevent this from happening.

What I wrote in "Your Developer is not a Single Point of Failure" details many of the other causes of the situation and most of them can be characterized as developer mismanagement.

In any case, businesses moved on from this blamestorm. Businesses put the management of mercurial coders into the hands of others. Even honest and ethical developers who worked themselves into obsolescence realized many businesses could not support the need for endless development of new algorithms without the business case to do so. They went out and started tech consulting firms. Of course, this scenario solved all the problems too.

No, it did not solve them!

Automating businesses and writing code even for the low-code/no-code platforms is still happening. Things have gotten very very complicated in unexpected ways. The costly overhead of hosting an on-staff developer has been eliminated in many businesses, yes. Unfortunately, this has been replaced by costly outsourcing contracts to consulting firms and complex configurations and processes related to enterprise-level software packages. The long-term licensing and subscription costs of these low code/no-code platforms rather than owning the code is costly as well.

Despite the complexity, there are some very simple actions to prevent a business from being held hostage to on-staff or outsourced developers. One must understand the technologies involved, but only at a high level. Such understanding can be gleaned by asking the correct questions. What language is being used? What operating systems, platforms and/or clouds are being leveraged? How is your business' data being stored and backed up? Where is the source code and how does it get built and deployed to "production"?

The business should be operating its own source code repository for all the source and configuration code the business requires to operate. Annually, but more often at first, an audit to make sure the source code builds and builds to deployable and functional software. The costs of test-driven development become more justified when such builds become complicated disasters which breaks production. Also, the business should be operating its own data backups and understand how to do a restore. There should be some redundancy of staff or contractors on these fronts to make sure the business is not held hostage to one individual's or firm's knowledge, be that code or configuration.

There is no doubt the low code/no-code solutions have made significant in-roads into 21st-century businesses. Software and hardware have become sufficiently modular to allow for smart people to put together workflows without code. Once these workflows are hooked up, business can be done and profits banked. Often, there are gaps which are filled via sneaker net and an Excel CSV. With so many outsourcing firms and an excess of technology workers, this business model worked fairly well, but times have changed.

These cloud platforms and ERP systems are development eco-systems unto themselves. Their arcane configurations become the tribal knowledge of some on-staff person OR the business is constantly hiring ERP consultants. Also, there always seems to be a need to build out the last 5-10% of some workflow automation or business process implementation with a little script or code to "duct tape" things together. The challenge now is to identify where there is "code" or configurations your business is dependent upon.

This is one reason why the business needs some kind of central tracking system related to tech issues and support. Having a ticketing system means you have a central location for all the "problems" or support calls happening internally. Even if you are opening support tickets with different vendors a central location for the business to see open tickets across systems and departments is an absolute necessity. This will help the business identify systems needing closer attention as well as possible "customizations" (in code or configuration) which require support.

Finally, creating or refreshing the business' disaster recovery plans should reveal all that remains. A disaster recovery plan is essential in today's uncertain environment. A dependency on cloud technology helps mitigate this, but there can still be regional outages. Can the business easily rotate to another AWS region for example to keep critical business systems up? Can the business move cloud-based technologies to a different vendor? Can any of these systems be operated "off-cloud" or are they completely dependent upon large-scale connectivity?

Creating a disaster recovery plan is probably the most difficult part of preventing the business from being held hostage to a developer, contracting firm, ERP vendor or cloud platform. Having the source code and doing periodic builds is vital. Having redundancy among staff or contractors to support the code, configuration and data also helps. However, it is the disaster recovery plan which will pay the most dividends.

The disaster recovery plan can take some time to put together, but the work is very much worth it. The act of creating a "shadow version" of your business' workflows and systems will not only serve as insurance against fire, earthquake, unexpected cloud outages, but reveal the guts of the technical framework the business rests upon.

During the disaster recovery plan, the business will need to identify back up developers, product owners and system specialists. If there is no "on-staff" back-up, hiring contracting firms on retainer is becoming more common. Hiring another contracting firm to help disaster recovery analysis can make a lot of sense, though it will cost more money. Paying for the licensing to allow for a complete rotation of your business to a "shadow system" can reveal many unexpected costs as well.

This is where having an on-staff developer can pay real dividends. The on-staff developer can serve as a repository for MUCH of this information. Earnest developers managed by earnest leadership will always deliver more than outside mercenaries. Unethical or poorly managed developers will not, whether they are on staff or not.

The earnest developer will be transparent about where the source code is and how to build it. The earnest developer will understand the need for a disaster recovery plan and will help create the necessary redundancies. The truly earnest developer will even work with a contracting firm in these efforts. The contracting firm can then act as the developer's backup in case of unexpected absence related to illness, injury or ... they just want a REAL vacation.

I am terribly sorry, but it is the 21st century. This means "knowledge workers" are VITAL!!! Good "knowledge workers" are not stupid which may be the source of some friction between management and technical staff. If leadership treats knowledge workers poorly there can be consequences. This gave rise to so many contracting firms. Knowledge workers can build silos of technical knowledge holding the business hostage, but frankly so can contracting firms and enterprise platforms.

Understanding the technical foundations of the enterprise and how it supports the business model is not optional in the 21st century. SOMEONE on-staff needs to have an overarching view of this landscape. They do not need to understand all the minutiae of the underlying technical framework, but they MUST understand how to create redundancies to buffer the business against change and disaster.

All businesses in the 21st century are tied to some technical framework and implementation. Surely some businesses are SO simple, like running a taxi service, a big tech firm can encapsulate the entirety of the technical model and then just plug humans into their "matrix" of a business model. A company like Uber or Lyft is a perfect example of this version of doing business in the 21st century.

Nonetheless, most businesses still have "uniqueness" to their way of doing business. In fact, it is this uniqueness which can create a market advantage, but also the dreaded situation of having the business held hostage to ONE developer or contracting firm's technical silo. However, a ticketing system, adequate source control, annual build audits or better yet the creation of a disaster recovery plan makes it far more difficult for this terrible situation to occur.

Do these things and the business will be stronger and more resilient to change. In addition, the business will be better engaged with its knowledge workers whether they are on staff or not. This synergy between leadership and technical personnel is incredibly powerful. Not only is the business strengthened, the knowledge workers understand their roles better and how to serve the business model of the company they support.

That is why arguably the biggest and most successful business of the 21st century is Amazon. The aforementioned synergies are extant within one person, the creator, Jeff Bezos. Not everyone can be a coder and an entrepreneur under one hat. Smart leadership can make common cause with its knowledge workers though. These same synergies which made Amazon so successful can exist in any business willing to engage with its knowledge workforce as full partners in the success of the enterprise.