Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase 12345»»»

Trust People Expand / Collapse
Posted Wednesday, January 5, 2011 9:42 PM



Group: Administrators
Last Login: Yesterday @ 3:36 PM
Points: 34,362, Visits: 18,572
Comments posted to this topic are about the item Trust People

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1043473
Posted Thursday, January 6, 2011 12:07 AM

Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, May 19, 2016 12:20 AM
Points: 1,333, Visits: 816
Ok, this is off-topic, but I can't help it.

From the original article:
In 4 BC, the Gauls sacked Rome, a horde of individual warriors defeating other individual warriors. But by the end of the Second Punic War, mostly due to Scipio Africanus, the Roman Army was unlike any other in the world.

4 BC? Not really. 387 BCE is the correct date, see for instance
In case you were wondering, the Second Punic War (versus Carthage) saw the march of Hannibal against Rome, and was between 218 to 201 BCE. In my recollection a close call for the Romans, but I would have to look that up some time.

Would be great stuff for a movie, but I digress even further.

Dutch Anti-RBAR League
Post #1043506
Posted Thursday, January 6, 2011 12:36 AM



Group: General Forum Members
Last Login: Wednesday, February 10, 2016 11:50 AM
Points: 6,897, Visits: 13,559
To quote the editorial:
and then let them bend rules, change procedures where it counts

The question is: Who's going to decide whether it counts or not?

Scenario 1:
You're a DBA and a person with proven knowledge of SQL ask you to grant him access to one of the db's around. The DB has nothing directly to do with his job, but he knows there are data in there to be useful for his current task. He wants to lurk around and see what he can use.
There's a written rule involving the owner of the db as well as ther manager of the one who's requesting access. But well, you know him long enough and "it's urgent", as usual.
Question: Is this bending rules or crossing the line?

Scenario 2:
You're a DBA and you're asked to delete a few rows. There's a written procedure who'd need to agree since other systems might still need those data. The person asking you claims "It's the same scenario like last time. And you know how long it took us to get the form signed just to figure that noone objected." The DBA deletes the data (scripting it out before, just to be on the safe side). And this time one of the poeple usually involved immediately is in trouble because he still needs the data. Again: Is this bending rules or crossing the line?

I prefer a system where people can question a process and make suggestions how to improve it. But as long as the process has not been changed officially, the current one has to be followed. It's the responsibilty of the management to listen to such suggestions, take them seriously and to respond within a short timeframe providing an explanation either why the change has been implemented or refected. But I'm a strong opponent of bending the rules since there is no change to draw the line.

A pessimist is an optimist with experience.

How to get fast answers to your question
How to post performance related questions
Links for Tally Table , Cross Tabs and Dynamic Cross Tabs , Delimited Split Function
Post #1043516
Posted Thursday, January 6, 2011 12:43 AM



Group: General Forum Members
Last Login: Today @ 9:13 AM
Points: 42,042, Visits: 39,421
gserdijn (1/6/2011)
Dutch Anti-RBAR League

Heh... off topic a bit myself, I like your signature line... a LOT!

--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."

Helpful Links:
How to post code problems
How to post performance problems
Post #1043519
Posted Thursday, January 6, 2011 2:22 AM



Group: General Forum Members
Last Login: Today @ 1:49 AM
Points: 7,765, Visits: 11,372
After reading the article referenced in the editorial, I don't really know what its auther wants to tell me. Does he/she think agree we we should trust systems instead of genius, or is the message that this may have worked for the Roman army and during the Industrial Revolution, but is not applicable in the modern world?

Anyway, I do have some critical side notes.

First, to base the idea to "trust systems not genius" on the Roman army disregards one important thing - that the idea to reform the army from a bunch of individual warriors with different levels of talent into a well-oiled (figuratively speaking, of course) machine was one heck of a stroke of genius. If the Romans had decided to trust systems instead of genius before the reform of their army, said reform would never have happened.

Second, while it is true that the rigid systems of the Roman army allowed average soldiers to fight lots better than they did individuallly, it equally hampered those who were above average. I think that if the Romans had not defeated themselves by lead poisoning, they would still eventually have lost. Because the rigid system that allowed their army to defeat all other armies at that time, also prevented the adaptability required to cope with new challenges. Because the rigid system allowed the average soldier to bloom, but failed to enable the genius to work at his own level, geniuses would leave the army, keeping only the average soldiers enlisted. And eventuallly, some opponent would have crafted an even better organization for their army, or a new kind of weapon that the Romans had no answer to - and no genius left in the army to adapt to the new challenge.

I have been in jobs where the procedures were too strict for me. Way too often, I knew exactly how a program had to be written - but I could not, because there were rules, regulations, procedures, standards, and whatever in the way. This enabled average and even below-average programmers to create acceptable work, but it also prevented me from creating the much better work I am able to create. Guess what? Everyone working there was either (below) average, or leaving as soon as they found a better job. There were too little above-average people left on the workforce. If it had been a commercial company, it would probably have been broke by now. But since it's a government institution, it instead makes the headlines due to failed IT projects a few times per year, and continues to blunder its way to the next headline.

I think that the ideal company employs people on three levels - with the actual challenge being to find the right people for each layer, to move them to the next layer only when they are really up to the task, and to keep them all happy even if they have no prospect from ever changing layers.

These layers are:
* Management - the smallest layer. These people don't have to do the actual work, and if they are good at their job, they don't need experience doing the actual work either. Their task is to make decisions that affect the entire company or a large part of it. They decide based on information coming from the lower layers.
* High-skilled layer. People here should be highly skilled (note that I write skilled, not educated - though education can be a measure of skill). The right people for this layer are motivated by success (*). That means they WANT to do what's best for the company. They feel hampered by too strict rules and procedures, and they are intelligent enough to be able to improvise.
* Low-skilled layer. In many companies, this will be the largest layer. But there are exception. In a consulting company, the high-skilled layer will be the largest. People in the low-skilled layer are usually motivated by other factors (*) - like feedback from boss and co-workers, or monetary incentives. They often don't feel at ease when left to improvise (and often mess up when they have to) and thrive on procedures that allow them to do what they are good at, without having to improvise.

(*) I am not making this up. There have been studies about motivational factors, and they show that there is a relationship between education (as a measure of skill) and motivation - people with higher education generally are motivated most by seeing how their actions contribute to the companies' success, and people with lower education are generally motivated more by financial incentives. Both categories are motivated by feedback from management and co-workers.

Hugo Kornelis, SQL Server MVP
Visit my SQL Server blog:
Post #1043561
Posted Thursday, January 6, 2011 2:40 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, April 17, 2014 3:29 AM
Points: 229, Visits: 421
I think Hugo has said it all really, it's kind of the 80:20 rule - get the grunts to follow procedure rigidly, which works 80% of the time, then get a few people who you pay to think to deal with the exceptions which don't fit with the procedures.

Of course the larger the company the less chance you have of thinking through the implications of your actions in terms of how it affects other people/departments, in which case you have no option but to work through the mountains of paperwork necessary to make changes.
Post #1043567
Posted Thursday, January 6, 2011 6:32 AM

Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, October 25, 2016 11:39 AM
Points: 393, Visits: 1,092
Great editorial Steve!

I agree with Hugo's response. In the physics software teams, an over-emphasis on process is the path of least resistance. If an entry-level person can do the job, an entry-level person will. This goes to Hugo's hierarchy.

The sad part is this results from an intentional management decision. Processes reign supreme because repeatability, scalability, and predictabillity are easy to sell. These are noble attributes... or are they? Errors are repeatable. Ignorance scales. Failure is predictable. If you look up the address of "process" you find it living nearer the (intellectually) impoverished - not the innovative.

Hugo describes the institutionalization of the Roman Army well. And he's right: a smarter Army would have been able to defend against the barbarians... but it would have been much more difficult to manage.

People do work, not processes (at least in 2011). Processes should serve people, not the other way 'round.


Andy Leonard
Data Philosopher, Enterprise Data & Analytics
Post #1043698
Posted Thursday, January 6, 2011 6:55 AM


Group: General Forum Members
Last Login: Friday, January 30, 2015 7:36 AM
Points: 2,723, Visits: 4,152
How does one define greatness?

I think one never knows they are in the midst of greatness. It takes reflection and historical perspective to determine that something or someone was great.

How does a manager determine the greatness of their staff?

I say never trust people or systems. People are flawed and will always create flawed systems. That's why rework occurs.

Or, maybe I'm thinking of perfection? Are greatness and perfection the same?

Steve, stop making me think this early in the A.M.!
Post #1043716
Posted Thursday, January 6, 2011 6:56 AM

Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 2:03 PM
Points: 1,334, Visits: 3,069
"However by 200 years later, the Roman army was the strongest in the ancient world. How did this happen? Many people believe it was the creation of a set of processes, management, and training that used standards and synergies to achieve greatness."

Many people also believe that was their undoing. We may very well follow the Romans because we are just getting swallowed up in our own processes, misguided management, and bureaucracy that WE created.

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1043718
Posted Thursday, January 6, 2011 7:24 AM


Group: General Forum Members
Last Login: Wednesday, July 1, 2015 6:58 AM
Points: 196, Visits: 262
200 years to be a force to be reckoned with? That just doesn't seem that impressive.

What's really impressive is that in 5 years (from Pearl Harbor), the US military went from being somewhere around 15th in the world to the primary military power. Talk about process improvement. Wow!

Too bad we've lost that initiative.
Post #1043740
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse