June 16, 2015 at 8:03 pm
Comments posted to this topic are about the item Culture Clashes and Arrogance
June 17, 2015 at 2:53 am
The scenario described seemed extraordinarily confrontational. You do not want other folk preventing you from getting your job done, and guess what? Nor does anyone else. Rather than a flat refusal, far better to identify the conditions which must be met in order for the request to be agreed, and translate that into actions for the enforcers, the requesters, and possibly some third parties too. If the conditions cannot be met, then at least the enforcers have tried to help, and the requesters know why they cannot have what they want. Ultimately, being obstructive damages the whole organisation, and damages the reputation of the obstructer. Great things are achieved by collaboration and co-operation.
June 17, 2015 at 4:20 am
Great post. It brings to mind many such situations that I have experienced in the past.
I think what exacerbates these situations is the "urgency" of the project - a looming deadline that the askers had already committed to, not realizing the roadblocks they would shortly encounter from the enforcers. I see it as a lack of respect/understanding for the work the enforcers do: not there just to deploy changes to production, but as an equal partner from the initial stages of a project. Enforcers often have to adhere to strict SLAs and RPO/RTO requirements - having strict rules in place helps ensure they meet these obligations. If a "quick" change brings down production, it will be the enforcers that will have to answer for it to the business, not the askers.
This does not condone "arrogance" on the part of the enforcers, but should help explain why in the heat of the moment enforcers could at times come across as intransigent and hostile.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
June 17, 2015 at 4:36 am
A good editorial that does show the clashes I encounter in my development life all the time. As a small company guy dealing with big companies I have to use charm and energy to make sure changes are expedited as rapidly as possible - and as a dev I do not always have deep resources of those to call on 🙂
Just last week I had a 'The process requires a 5 day lead time and will instantly be rolled back if there is a problem.' Of course there was a problem - they had used the wrong IP address. Fortunately quick action meant I got their team to alter course and use the correct address without another 5 day lead time but you do need constant vigilance...
June 17, 2015 at 4:52 am
A clash of cultures is expected when different groups of people work together. After all, how a group works is considered normal for that group. Other ways of working is therefore not normal to them, but that doesn't mean you should look down on them for being different. If the bureaucracy exists just for the sake of having bureaucracy, that's something I personally can't stand, but if I want or need to work with them, I have to let their process take its course. I don't have to like it and they're certainly held responsible for the impact of their bureaucracy, but the odds of them changing their culture without a major directive from above are low. As has been said many times, culture eats strategy for breakfast.
If nothing else, the bureaucracy serves to create at least one thing: http://www.lhup.edu/~dsimanek/administ.htm. 😛
On the other side of the coin, there's no excuse for arrogance. That serves no purpose other than to damage the relationship between the people or groups.
June 17, 2015 at 7:47 am
Ed, that's the first I had read about that element - nice!
I think the arrogance comes from a combination of being tribal, using aggression to mask discomfort on enforcing the rules, and lack of awareness of how words are perceived - in different proportions depending on the source!
June 17, 2015 at 7:50 am
john.riley-1111039 (6/17/2015)
The scenario described seemed extraordinarily confrontational. You do not want other folk preventing you from getting your job done, and guess what? Nor does anyone else. Rather than a flat refusal, far better to identify the conditions which must be met in order for the request to be agreed, and translate that into actions for the enforcers, the requesters, and possibly some third parties too. If the conditions cannot be met, then at least the enforcers have tried to help, and the requesters know why they cannot have what they want. Ultimately, being obstructive damages the whole organisation, and damages the reputation of the obstructer. Great things are achieved by collaboration and co-operation.
Yes, but all too often the "askers" just don't want to follow the process. I see this frequently.
"My job is to fix (some system) and I don't have time for this!"
Well guess what, the process is there to prevent issues, and the last 20 times you said this, and we let you go ahead, you brought down our entire (network in the data center, VMware infrastructure, wireless network at the hospital, SAN, fiber switches, etc)!
Sometimes the enforcers need to be more patient, and explain things. But once you have done this with the same person multiple times, and that person still refuses to adhere to the policy, turning them down IS the RIGHT answer.
Dave
June 17, 2015 at 8:00 am
Andy Warren (6/17/2015)
Ed, that's the first I had read about that element - nice!
Thanks, but I can't claim credit for coming up with it. I first saw it years ago and it was funny enough to remember.
Andy Warren (6/17/2015)
I think the arrogance comes from a combination of being tribal, using aggression to mask discomfort on enforcing the rules, and lack of awareness of how words are perceived - in different proportions depending on the source!
You might very well be right on those things. I've seen people use aggression to mask both discomfort and a lack of knowledge.
I have another theory to add into the mix. I have nothing to base this theory on other than experience and observation and I don't have any data to back it up. I think some of it comes from an intrinsic need some people have to be right all the time. As knowledge grows, so does self-importance and arrogance. Once someone gains a sufficient amount (depends on the person) , they eventually admit that they don't know everything. Then the arrogance can begin to decrease. I'm not saying it does, but rather that it can. Some of the brilliant people I know are very humble, and they don't have the need to tell you how smart they are. Like I said, it's just a theory. What do you think?
June 17, 2015 at 8:01 am
Welcome to my world!! I work in a highly regulated industry. There is so much paperwork and red tape that a 10 minute change takes 3 hours because of all the paperwork.
I do challenge the enforcers on this and sometimes win when paperwork gets rejected for something missing or "wrong"... Sometimes it is a very good thing and gets the enforcers to go up the chain and challenge regulators.
We also do have conversations about how to make the process better and faster while still being able to fulfill all the regulations.
June 17, 2015 at 9:53 am
Great post, Andy. Having started a new job I feel this intensely. I'm in the role of an asker. Things move so slowly that I wonder how I'll keep my job, as it takes much longer than I'm used to. At the end of the day I don't feel I have a lot to show for what I'm supposed to do. But that's because I'm still trying to figure out who does what, whose back I need to scratch, so to speak. I'm sure as time goes by it will get faster.
More importantly your post reminds me to think of the enforcer. I've got to see it from his/her point of view as well.
Kindest Regards, Rod Connect with me on LinkedIn.
June 17, 2015 at 10:06 am
sql Sarah (6/17/2015)
Welcome to my world!! I work in a highly regulated industry. There is so much paperwork and red tape that a 10 minute change takes 3 hours because of all the paperwork.
It took me 7 months to get approval to gain access to slideshare.net.
As an "Asker" I've switched to describing the problem I am trying to solve rather than the solution I am trying to implement. I then ask the other side how they can help to solve the problem. Where possible I involve the "Enforcers" early on so I can address their concerns early or at least know what I am going to be facing.
The important thing (as an Asker) is to make sure that you know what the change management process actually is. That way you can go before the change management board fully prepared.
What I saw in the "Enforcers" camp was the enforcers actually used the process on themselves for their changes. Eat your own dog food and all that! If you have to use the process yourselves then you make sure the process is as pain free as rigour allows.
The enforcers also had very clear views on who they trusted and who they didn't.
Those who were trusted went through a light weight process precisely because they had earnt that trust. The enforcers had seen that the "trusted" group rarely had a failed change and dealt with any failure rigorously.
Those they didn't know got the general process on the basis of being granted the benefit of doubt. Innocent until proven guilty.
Those with a track record of failed changes found that each failed change resulted in ever increasing scrutiny and insistence on the letter of change management "law" being followed. As an "Asker" I thought this was a perfectly reasonable system. After all the enforcers made it very clear that in the event of a failed deployment it was the enforcers who would recipients of the imperial defecation from above.
June 17, 2015 at 10:14 am
Awesome editorial! Process VS product tends to be a continuum and organizational enforcement changes across time. Experience across time is an amazing thing
Sometimes the focus is on process, after major production failures or security breaches, and other times it's about making changes, like consolidating data centers. Interesting that the dynamics between askers and enforcers don't change.
Question for another Editorial: Where are we headed next? Towards more control or less. The 90's .COM era was clearly less. Do recent security attacks predict more control, or does government and corporate cost cutting/outsourcing indicate less auditing?
June 17, 2015 at 10:25 am
I would think we're in for a world of much more strict change control. After the Feds lost all of their data I would think (and hope) that enforcers would be sent down with the job to crack heads and then ask questions. I am literally blown away at the lack of obvious security protections they did not take.
June 17, 2015 at 10:30 am
Change control is a bit like security: if it's convenient it's probably not doing its job. While I do understand that urgency is often seen as a reason to deviate, in most cases I've seen that's a flawed view: if anything, from my own viewpoint urgency would be a primary DRIVER to follow the process. The more diree the need, the BETTER controls need to be; the other way around is just begging for a system meltdown.
I'm all for working collaboratively to design a change control process that is tailored to the SDLC and/or project, but once you've defined it - there really shouldn't be a whole lot of wiggle room. By all means - have a "normal process template" and potentially a "flaming arrow process"; but once you get much past 3 or 4 potential procedures to get changes through, change control ultimately stops and chaos begins.
I've worked mostly in highly regulated industries and even then you can still design efficient processes to use agile or other such implements and still meet audit controls and other documentation requirements. That said - there shouldn't be a negotiation phase built into each release cycle or your process is just flat broken.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 17, 2015 at 12:26 pm
Great Post Andy.
I have been everything from a DBA at a bank and in the Healthcare industry where there are the tightest controls imaginable and I have worked in environments where you hear things like, "hold on, let me give you access to the Prod DB... let me know if you can figure out the problem." I have seen environments where I had everything I needed to do my job and ones where it was impossible to get what you need regardless of who you speak with.
I have now been in the "Corporate America" since 1996. I have gained enough wisdom to know how to adapt to my environment and know what types of cultures work for me.
Some general rules of thumb that have come in handy include:
1. Be nice and professional to everyone regardless of their position or how much of a douche they are.
Especially as a DBA, you are dealing with people from every department with different agendas, needs and levels of maturity. I was always willing to go the extra mile (e.g. picking up that 3AM phone call) for people who were nice to me and respectful to my needs. Many people out there have saved my butt when they did not need to.
2. Pick your battles wisely; being right is not reason enough to pick a battle.
There are times that you need to go to battle to fulfill a business requirement or the project will fail. Other times you are just right and feel the need to prove it. The former is a good reason but be pragmatic; the former is not.
3. Nobody likes (nor do many people read) long, long Emails.
I have been the DBA sending 3 pages of text to a large audience about why everyone needs to start/stop doing <whatever>; I have received those Emails too. I had a boss once say, "If you can't say it in 2 paragraphs then it's not worth discussing or you need to schedule a meeting". This is for non-technical stuff of course, not documentation.
4. Don't take it personally.
Some people are jerks, others have something to prove. Nothing is perfect once you involve human beings.
5. If you work in an environment with a tight budget and lots of servers - Always be nice to the SAN guys.
Those dudes have too much power man. Best be on their good side.
Sorry for the rant... The coffee just kicked in.
Edit: Formatting and minor grammar issues.
-- Itzik Ben-Gan 2001
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply