Try Before You Buy

Right to Hire, it’s like “Try Before You Buy” in the contract and consulting world. Apparently some employers think it’s only for their benefit, when in fact it’s a two way street.

I once engaged in a 6 month RTH engagement for approximately 3 months. In this case red flags started rather quickly, yet I gave ample opportunity in case what I was seeing was related to the new person mentality.

What is “the new person mentality” one may ask? It’s a rampant viewpoint that many long time employees have that nobody else knows anything, many times showing complete disregard for past experience or accomplishments. I do not know what propagates this viewpoint, but it appears to be a multifaceted psychological response.

The reason, as relayed to me by the organization, was that they were bringing me in to improve on-premise deployments, help facilitate cloud migrations, help develop a Master Data Management program, and take over management of their database team.

The first day on the job I was integrated into a plan to upgrade 12c to 19c, 12c was slated to go out of support the following month. The plan here was to deploy new servers and migrate all 12c databases using the Oracle Datapump utility. It was an uphill battle to change the vector to taking a more modern and proactive approach.

Essentially having to “prove” this worked was interrupted and put on hold multiple times at length in order for an existing DBA and Systems Architect to continue testing the “new server and datapump methodology”. This difficulty was only a sign of things to come.

The number of failure points when deploying new database servers greatly increases as compared to upgrading an existing system, especially with a large number of hard coded scripts and one-off deployments. The hard coding of scripts became another angle of contention.

I began to take notes of the problems I was having in regards to trying to engage. One peer in particular was choosing to work around me and cause problems. This was obviously a red flag that was intensified by an “in your face attitude” from the said peer

Attempting to garner some sort of insight from the next level manager that I reported to resulted in a response that I needed to find a way to work with this person. Another red flag, as I wasn’t asking this manager to get involved, engage in some punitive action, or reprimand, however was looking into insight as to what was going on with this individual.

This was obviously not an interpersonal working relationship problem. This was someone going off script and causing problems by doing whatever they wanted with no concern or conceptual understanding. This trajectory had the potential for catastrophic results, and there was a side concern of who would get blamed. Would “that new person” be the person to blame? It would not be the first time I have witnessed such strategy.

My being a portion of this endeavor provided concern over how these problems were being interpreted. After all, I was on a 6 month consulting engagement that was expected to convert to a database leadership position. I was even informed to approach the position from that viewpoint out of the gate.

What would make a peer, who is well aware of why I was there and what I was supposed to be doing to act in this way? Why was I getting no support when trying to engage the direct manager on what was expected of me with what was going on? What was the end goal here? As the questions and red flags began to tally, so did my concern over whether this would be a long term environment conducive to my career and longevity.

These concerns culminated when a production database outage was caused by this same person. It was not a critical system, thankfully, but when I wanted to perform a file system backup and upgrade all in the same outage window I was told that this could not be done and would require a separate change request approval and outage window.

I created a change request and as soon as it was approved the peer announced that we were not going to perform the work during a normal maintenance window, however would do it this weekend. This was going to now occur five days before the approved window. Apparently we could not backup and patch in the same maintenance window, but we could obtain an approval for a maintenance window and do the work on a weekend five days prior?

This peer then proceeded to get with another DBA and schedule the backup to happen over a weekend outside the pre-approved maintenance window. When I inquired on this and specifically asked what the business need was to have an employee work on a weekend, when we already had a pre-approved time slot during a maintenance window, I was told “there really is no business need other than I sometimes put on my PM hat to make things happen”.

That was very telling, because he also put on his PM hat and had the same DBA place the database in archive log mode, which resulted in an outage a couple days later when it filled up the archive log space and caused an outage.

This was my final red flag that this was not a good fit for me. I notified the manager that I would not be able to apply for the permanent position as I wouldn’t be able to accept responsibility under these circumstances. I also said I would be happy to transfer knowledge and help out to keep things moving, preferring to make it an amicable departure.

I was called by a representative at the agency that placed me and informed that “the angry and threatening email I sent was not well received, they wanted me out of there instantly, and I was to go nowhere near any of their employees or facilities”. The way this was delivered portrayed me as a some sort of threat, yet I was initially trying to protect the organization, it’s systems, and provide an amicable transition.

I learned a long time ago to keep copies of emails I sent, and detailed notes. I was nothing short of professional with no animosity, or anger whatsoever, and even extended an offer to help transition and keep things moving. I became the bad guy, which reinforced my resolve that this was not going to be a good environment and that “try before you buy” is not a one-way street.

Admittedly, I do not know how much of this was from the organization itself or just a posture being taken by the placement agency. There was a planned one-on-one meeting the next day where I had hoped the manager and I could discuss the problems culminating with a successful move forward.

I had decided I could not apply for the permanent position and nothing gave me any sign that it would be any different once I was in said position. Maybe the outcome of the meeting could have changed that, however with the tact that was taken, one can easily suspect not.

Prior to my decision, which had been made before the outage, I had sat down and listed out my concerns for self analysis:

  • I was being engaged to implement change and improvements, but that cannot happen without upper management support.
  • There was an employee that was ignoring anything I said, recommended, or promoted and doing whatever they wanted.
  • An employee that would have been one of my direct reports was made to work on a weekend for no reason, other than another employee said he sometimes needed to put on his PM hat and make things happen.
  • This alluded that any PM could make something like that happen.
  • It appears that I would have been powerless to effectively manage a team and protect them from such whims as someone putting on their PM hat.
  • Would I also be giving up my personal time and weekends on the whim of a peer or PM who just wanted to put on their PM hat?
  • This also alluded that a PM could override and ignore Technology leadership and best practices and the department head would support them over the technology leadership and staff. That is always a red flag!
  • I was pressured, by the same peer, to delete and recreate a database over an authentication problem. This turned out to be a simple and easy fix once I was able to engage a support representative from the vendor.
  • Another long term DBA refused to adopt better scripting methodologies, stating that it would not work with Oracle.
  • The overall interpretation appeared that although upper level management wanted change, it was not going to provide any support, much less feedback or insight.
  • When discussing my concerns with the agency that placed me at this organization, two different representatives tried to inform me that I was the problem.

At the end of the day, maybe I am the problem, but I did not cause an outage and had the foresight to try and prevent what was inevitably going to happen.

I tried to engage, and it went largely ignored and pushed off on me as my responsibility.

Of one thing I am certain, past experiences in a similar environment tells me that not only was I the problem, but I also had no idea what I was doing. Want to buy a bridge?

It was obvious that they did not need someone like me.

The moral to the story, RTH and “try before you buy” works both ways…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s