Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

How to influence others? Expand / Collapse
Author
Message
Posted Saturday, March 8, 2014 2:21 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, April 29, 2014 6:47 AM
Points: 319, Visits: 783
I have often found myself in the past facilitating groups of less experienced individuals in building data warehouses.

One thing I have found the most challenging was trying to convince some of those involved that the way they wanted to do things was not the best way. For example ignoring some of Kimball's basic guidelines such as snowflaking when it's not necessarily required, making everything type 2 scds as no one wants to spend time doing the analysis or doing it this way 'because that's the way we've always done it'

Unfortunately the people offering up these things are the ones who have been at the company the longest and have the loudest voice!

Sometimes though it is difficult to find a specific reason why you shouldn't do something one way over another. Often these are the fundamentals seasoned dw developers take for granted and are never brought into question.

Have you guys had similar experiences? And if so what have you found is the best strategy to adopt in these scenarios?
Post #1548998
Posted Sunday, March 9, 2014 11:26 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 10:42 AM
Points: 35,769, Visits: 32,438
The only way to influence those that can be influenced is to be right and to be able to prove it without question. As the old saying goes, 1 test is worth more than a 1,000 "expert" opinions.

The only way to influence those that can't or won't be influenced is to give them the opportunity to fail and be patient. Notice I did NOT say "set them up for failure". That could hurt the company and your reputation. If what they're doing is truly a bad idea, they'll fail on their own. Be prepared to pick up the pieces. I've actually worked jobs in parallel so that when someone fails, I have fully tested code ready to rock at the drop of a hat. I don't do that to make myself look good, either. I do it as a concerned employee that earns his pay and has the welfare of the company at heart. Sometimes it takes more work than it should but it does have its future rewards. The manner in which you tell them "I told ya" will weigh heavily the next time you try to influence someone. The best method is to not say anything like that. If they don't already know, then you telling them isn't going to help.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1549065
Posted Monday, March 10, 2014 2:24 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, April 29, 2014 6:47 AM
Points: 319, Visits: 783
Very interesting response Jeff. I guess a lot of people on here would echo your comments.....and like to have someone who you describe working in their team!

I guess the key thing is to not get frustrated when you feel people are going down the wrong path no matter how hard you try. As you say the trick is let them go and make their mistake and be ready to help out when it does all come crashing down!

Post #1549138
Posted Monday, March 10, 2014 2:50 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Thursday, December 18, 2014 12:52 PM
Points: 13,636, Visits: 11,509
aaa121 (3/10/2014)
Very interesting response Jeff. I guess a lot of people on here would echo your comments.....and like to have someone who you describe working in their team!

I guess the key thing is to not get frustrated when you feel people are going down the wrong path no matter how hard you try. As you say the trick is let them go and make their mistake and be ready to help out when it does all come crashing down!



The problem though might be that the system might not crash and burn, but that it performs on a sub-optimal level.
You mentioned a lot of SCD2s (most authors do encourage that though, since SCD1 throws away all history) and snowflaking.
The result might just be that querying becomes more complex and slower, but it still runs. Maintenance will also be tougher. It will be hard to prove that you have an alternative design that is easier to query (ok that is easy to prove), but that is also faster and easier to maintain.




How to post forum questions.
Need an answer? No, you need a question.
What’s the deal with Excel & SSIS?

Member of LinkedIn. My blog at LessThanDot.

MCSA SQL Server 2012 - MCSE Business Intelligence
Post #1549141
Posted Monday, March 10, 2014 2:57 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, April 29, 2014 6:47 AM
Points: 319, Visits: 783
@Koen yes, they were just a couple of many examples.

The difficulty comes when you are attempting to prove in the design stages that their proposed solution will be more difficult to maintain, overly complicated, harder to work on and take longer to add new functionality. A lot of those things are not as easy to quantify and are subjective.

Most of the people who have been challenging in this way do not see the benefits of designing something in the way I suggest as they have no had the experience on working a similar solution.

Without actually building and working on those solutions these issues will never be realised.


Post #1549143
Posted Tuesday, March 11, 2014 6:03 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: 2 days ago @ 5:55 AM
Points: 155, Visits: 285
I've learned to follow four simple rules in my IT career:

1. Be honest.
2. Be direct.
3. Be polite/professional.
4. Don't take it personally if your ideas are vetoed/changed.

Practice these and you'll earn the credibility to influence others when it hits the fan and you're asked how to correct it.


____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
Post #1549684
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse