Taking Your Company Private?

[Recently Elon Musk (Tesla CEO) talked about taking his company private. Read how a Zone Leader recalls a situation where a publicly traded company considered going private in an effort to avoid SOx compliance.]

In early August, Tesla CEO Elon Musk indicated he had secured the financial means to take his company from a public traded company to a private corporation. This was around the stock price had plummeted from just under $371 a share down to right above $290 a share a week earlier. Certainly, the memories of the yearly low price of $252.48 were still on his mind as well — not to mention some unfavorable press releases regarding their underlying technology.

By late August, Musk had announced the vision for Tesla to become a private company was no longer an objective. This saga brought back memories the last time I heard a public company talking about going private...just a little over fifteen years ago.

SOx Compliance

Back when Sarbanes-Oxley (SOx) compliance became a requirement for publicly-traded corporations in the United States, I was working with a client that had a mountain of process change before them in order to comply with the SOx regulations within the Information Technology division.

The three main challenges before the relatively small group were:

• A lack of separation of controls

• Developers with admin access to production

• No defined process for application deployments

These challenges, along with the process and implementation changes required in the business areas, led their C-level executives to consider a plan to purchase all the outstanding public stock in an effort to take the corporation private — thus, not requiring compliance to the numerous SOx guidelines.

Overheard at the Office (An Example)

While I was working at the client, it was common for developers to login to the production instance of the application in order to make a quick bug fix or to troubleshoot an issue. They would do this with their same user identification and not a secondary "super" account, that was common for organizations to use from time to time.

Someone from the business would visit a developer at their desk to explain the situation. While sitting a desk or two away, I could hear the conversation as the business user would walk the developer through the production instance to locate the problem. The developer could access the same data which the business was using to demonstrate the issue, which made things easier.

In this example, the developer would open the code from the production instance, make a change on the fly, force a recompilation, then check the issue again. The user validated the problem was solved, thanked the developer and went on to other things. Meanwhile, the developer switched back to whatever was in progress, as if only taking a short break from a current priority.

As a result, a program code change was made directly in production — which would be difficult to track. What's scarier is that the non-production instances of the code did not have this change, which would likely mean the bug would be reintroduced at a later time. There was no ticket to document this work, only a drive-by visit to the developer's desk.

Lack of Separation of Controls

In the example above, a single person was able to make code changes into a production environment without the interaction from any other IT resource. There was no documentation or approval for the change, either.

The developer’s intent was in the right place — fix the issue as soon as possible — but there were no safeguards in place to protect the organization from a malicious change that could be made in isolation. Consider the case where the application was handling financial data, which could lead to one or more parties benefitting from a change put into place without any form of audit or control.

Developers Accessing Production

In that same example, the developer had access to the production instance — without having to change identification. This is another regulation enforced by SOx compliance, since the data maintained by a corporation is a valuable asset. Access to this data can also led to unfavorable results if developers or administrators have full (and likely unaudited) access to the data.

No Defined Process for Application Deployments

Finally, that same example demonstrated how there was no process behind making the change to a production instance. Basically, the developer was able to make the change, force the updates to compile, and be available instantly.

If the corporation maintained a history of their application deployments, comparison of the last known release and the now-current release would not match. If this process could be repeated by just three other developers, there would not be a way to fully know what code was actually running in production.

Next Steps — Estimating the Cost

This IT organization was relatively small at the time and contained less than 80 staff members within all of IT. This was after a pretty significant growth boost (by twenty to thirty full-time staff) from just five years prior. So, as they grew, others began to utilize these same approaches — since the business was expected to get results quickly and efficiently.

Again, their intent and their hearts were in the right place.

As SOx compliance became a reality, a major accounting firm utilized their consulting division to help identify gaps in their processes and controls. As expected, those three main categories were noted as red flags across their IT division.

At that point, a couple project managers began to work together in order to establish a plan to remediate the SOx-related issues. This Waterfall (well before Agile) approach considered costs around building requirements and making the necessary application and process changes.

In the end, the project would be one of the biggest initiatives the IT division had considered in the long-life of the publicly-traded company. It was the first IT-driven project to impact company profitability, which caught the attention of the C-level executives.

Their initial idea was to consider buying back all of the available stock to the point where the corporation could start the process of being a private company again. You can imagine how Elan Musk's directive brought back memories of this situation.

The Real Solution

Throughout this process, I recall there being quite a bit of strategizing taking place — to validate if the estimates were as large as the project managers noted. There were JAD-like sessions held where thought leaders were trying to figure out alternatives to meeting the guidelines without enduring the path recommended by the consulting wing of the major accounting firm.

In the end, the realization was reached where the gaps with SOx compliance were gaps that should be handled at this point of the corporation's existence. While the prior approaches may have worked well when the company was small and growing, there was too much risk to stay the course that was in place. In fact, these changes were things that even a private company should be employing.

In essence, SOx compliance would force the IT division to start functioning as a division of a publicly traded company — with the proper controls, security and guidelines in place that shareholders would expect for their investment.

Conclusion

Since I was a consultant looking in, I have no way to know the actual numbers that were spent in comparison to the original estimates, but the timelines were not as harsh as originally presented. I also believe that adhering to SOx compliance made things better for all parties involved. While the business was not getting instant changes to their issues, the number of bugs being reintroduced dropped dramatically.

I believe adoption to a new policy or procedure is like any other form of change we approach in our lives. There is often anxiety or resistance to divert from a proven pathway. However, once the value is recognized and the change is adopted, it is easier to comprehend and appreciate the new directives that are in place.

Have a really great day!