Shawn O. was not used to bright lights, smiling faces, or greetings like “hi Shawn, how are you today?” In fact, just about anything that wasn’t specifically intended to bring pain and misery to all had become foreign to him. It was simply par for the course. Shawn, after all, was an Oracle DBA. And not just any Oracle DBA, but one who sat on the company’s Database Code Review Council.

Like at many other Oracle shops, the Council at Shawn’s company was responsible for defining policies and procedures to make it virtually impossible for any developer within the company to make changes to their databases. For example, if a developer wanted to change, say, the columns retrieved from a single SELECT statement, he’d have to fill out a ream of paperwork, venture all the way up to the top floor, find his way to The Council’s chambers, humbly plead his case to The Council’s members – each of whom would be ensconced in darkness, wearing their traditional Oracle DBA robe – and then repeat the process several times after The Council ridicules him for missing paperwork, too little whitespace, too much whitespace, etc., and rejects his request for change. It’s just the way things work.

A New Opportunity
That said, imagine Shawn’s surprise when a former developer colleague called him up one day to see if he’d be interested in a different Oracle DBA job. Apparently, the developer’s company was looking to “Oracle-up” and invest big in a real Oracle installation. And really, what Oracle installation would be complete without its very own Oracle DBA?

A few days and a brief, two-minute phone screen later, and Shawn was at the new company, interviewing for the position. It all went extremely well: he barely had to say his name and they were sold. Shawn was offered more and a Senior Oracle DBA position, and did the only logical thing: he took the job. After all, who wouldn’t jump at the chance to create his very own draconian Code Review Council?

The new company was different. They had things like bright lights. People smiled and offered one another friendly greetings. They didn’t have things like the Pit of Despair. There wasn’t even a single oubliette for those who dared to break the build. But fortunately, the company was willing and ready to change that. After all, that’s why they hired an Oracle DBA.

Making Change
Unfortunately, change was not so easy. First came the money problems. Their plan to develop a “large Oracle cluster” was scaled back to a “medium Oracle cluster” and then, finally, to a “single Oracle server.” Worse still, their development strategy had gone from “cutting edge” to “barely holding an edge,” leaving things like continuous integration and quality assurance to fall by the wayside.

And that’s when the second problem – the cultural clash – started to occur. Shawn fought arduous battles with developers over formal code review, query tuning, and access restrictions. The developers insisted upon changing things immediately and fixing problems later, while Shawn demanded a rigorous QA process. Naturally, this led to a lot of heated arguments, a whole lot of swearing and bad-mouthing, and, usually, Shawn conceding his position.

After one of the more intense database code review sessions Shawn received a “one-on-one” meeting request from his boss. The subject was simply “Behavioral Deficiencies.”

Shawn had a gut feeling about what the meeting would be about: his strict policies and gruff attitude were simply unacceptable, and that he’d need to either shape up or ship out. And he knew exactly how he’d respond: there’s no way he was going to compromise further, as he was already operating in DBA-lite mode; heck, he even stopped dimming the lights and wearing his robe to code review meetings; in fact, they’d need to shape up or he’d ship out.

After three eternal hours, Shawn went to his boss’s office for his “Behavioral Deficiencies” meeting.

“Hi Shawn,” his boss started, “take a seat please.”

Shawn nervously sat down. He was still prepared to rattle off his “no, you shape up” retort, though not as confidently as he had fantasized.

“I’ve been reviewing some of your emails as of late,” his boss paused, “and I have to say, we’re a bit concerned. I’ve printed out a handful here, why don’t you take a look yourself.”

Still not saying a word, Shawn flipped through the small stack of paper. Each page had several highlight marks, and each word that was highlighted was either “I”, “I’ve”, or “I’ll”. Shawn let out a confused, “ummm…”

“Okay,” the boss started again, “so you see what I’ve highlighted? Do you notice something a little off there in your email?”

“I, uhhh,” Shawn mumbled, “ummm, well…”

“You don’t see it, do you?”

Shawn paused for a moment.

“You need to use the word ‘we’ more often. Look here,” his boss pointed to a highlight, “you say ‘I've put these policies in place’, but what you really need to say is, ‘we've put these policies in place.’”

“Okay,” Shawn raised his left eyebrow, “we?”

“Exactly,” his boss responded, “the word ‘I’ is just too negative. You are a part of us, and we make decisions for us. Even if it’s just you who made the decision, it’s really us who made it.”

Shawn stared blankly, trying to figure out what exactly his boss was saying.

“You see, Shawn, what we do is all about the team. One big team. Synergy. We know it feels like your DBA team against the development team – but really, it’s all just one big team.”

“That makes perfect sense,” Shawn said half-sarcastically. After all, he was the only Oracle DBA in the company. He expected his boss to crack up any moment.

“We’re just really concerned, though, that you’re not thinking team. Obviously, we’re all individuals, but we – you included – make up the team.”

“Got it,” Shawn replied. Unfortunately, though, his boss didn’t seem to hear that, or any of his subsequent “okay,” “will do”, “gotcha”, “allrightythen”, “okie-doke”, “you-betcha” responses. For the next thirty minutes, Shawn’s boss continued to lecture on the importance of team.

Finally, just before Shawn had heard all that he can take, his boss wrapped things up. “But what this all boils down to, is that we want you to feel free to express yourself in the manner of ‘we’ as opposed to using the word, ‘I’. We just think it would be better for the synergy of the team and for your own personal benefit to express yourself in that matter.”

Though Shawn had long since run out of thanks-we-get-the-point phrases, he replied with the thrice said, “understood!” He returned to his cubicle and took a few minutes to breathe in the absurdity of the last hour of his life. At least the good news, Shawn figured, was that there was no issue with the harsher and harsher policies he was implemented.

Just then, an email showed up his inbox. It was from one of the developers, was marked high-importance, and had the subject line, “EMERGENCY DB CHANGE - PLEASE RUN SCRIPT NOW”. Shawn wryly smiled and clicked reply.

“We apologize, but per the new Database Emergency Change Procedure we established, we are unable to run this script from an email request. Per the procedure, please request an emergency change review meeting, and we’ll be happy to review your change.”

On any day prior, Shawn would have probably just run the script and demanded that the developer follow procedure next time. But that day, he was instilled with a new sense of Oracle DBA Team synergy. After sending the reply, he dusted off his Oracle DBA robe in preparation for the code review. It was time, once again, for the Database Code Review Council to meet.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!