January 5, 2011 at 9:42 pm
Comments posted to this topic are about the item Trust People
January 6, 2011 at 12:07 am
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 http://en.wikipedia.org/wiki/Battle_of_the_Allia
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. 😉
January 6, 2011 at 12:36 am
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.
January 6, 2011 at 12:43 am
gserdijn (1/6/2011)
Dutch Anti-RBAR League
Heh... off topic a bit myself, I like your signature line... a LOT! 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
January 6, 2011 at 2:22 am
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.
January 6, 2011 at 2:40 am
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.
January 6, 2011 at 6:32 am
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, Chief Data Engineer, Enterprise Data & Analytics
January 6, 2011 at 6:55 am
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.! 😉
January 6, 2011 at 6:56 am
"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. ...:-D"
January 6, 2011 at 7:24 am
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.
January 6, 2011 at 7:33 am
I think it's best to have a small and well thought out number of business policies (or personal principles or religious doctrines), and dedicate our time and engergy to upholding only those things. Otherwise the system becomes unmanageable and we lose track of the things that really matter. The root cause of most preventable disasters (like the failure of the New Orleans flood walls or the mass dumping of classified military documents onto a thumbdrive by a low level officer) were the result of overlooking what should have been obvious, because those responsible were too busy looking somewhere else.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 6, 2011 at 8:23 am
I agree that processes should serve... In the case of low-skilled operators the process serves to constrain behaviors to those that are safe for system integrity. With higher-skilled operators structured processes serve to increase efficiency (ex: put a properly coded package on the conveyor and it makes it across the country with no other human involvement or delay: it's easier to code the package properly than to deliver it the wrong way) Even for highly skilled operators, consistent application of rules allows longer-term or larger-scope projects to assume details will be handled according to tested methodology.
I think more developers should embrace the HCI "natural constraint" concept (see Donald Norman) for software and processes rather than only literal objects. If a new system isn't easier to use than an old system, it may require enforcement to deploy. Obviously that should raise questions about design failure. I think this is a management analog to using triggers* as a crutch to overcome a schema problem when an improvement in design would remove the need for the hackish work-around in the first place. It works but do we ever do cost/benefit analysis of the get-it-done-for-today (often via brute force) shortcut and the "extra time" to develop the more efficient solution?
* I'm not criticizing triggers. I'm criticizing incorrect use of triggers. I admit I learned this lesson/example through experience. 🙂
January 6, 2011 at 8:44 am
"Put your trust in systems, not in genius I can't do that. But I can work within a system, when I know that the system will change when the need arises. If we aren't following a procedure how will we know it is flawed. Most of us are not consistantly a genius, but most of us do know when something isn't working, and occaisionally have a stroke of genius. Times change and no one would give those Romans and there tactics a chance against a modern army, and even now as our enemies change tactics a modern army must adapt.
To continue with the army analogy, The problem I see most often is that the soilders are forced to obey commands that no longer defeat the enemy, and the officers place the blame on the soilders . Those soilders can't be asked to follow orders without a say in what the tactics should be. I think the heirarchy can lead to a eletist attitude at the top, and we fail to see the wisdom of those who have recent battle experiance.
I think I am very fortunate, to be in a small orginization (less than 100). When someone sees a problem or has a stroke of genius, the change can get implemented rather quickly. I work for a government entity, so the business doesn't grow, but our rate-payers get better service and/or better rates. The technology grows very fast and we have to be nimble if we are going to keep up.
January 6, 2011 at 9:47 am
Interesting, especially Hugo's divisions of management/high-skilled/low-skilled. If only it were that simple. When I'm developing on a new project, I'm always considering/evaluating who I'm talking/interviewing with, and whether they're interested in a job well done or collecting a paycheck. I try to find the people at all levels that are in the former group and not the later. After all, if I do a good job, I'll be replacing the later group with an SQL script and a report. 😉
January 6, 2011 at 10:11 am
Alan Vogan (1/6/2011)
After all, if I do a good job, I'll be replacing the later group with an SQL script and a report. 😉
Or even better, just offshore their job to India. Seems like the thing to do nowadays anyway.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
Viewing 15 posts - 1 through 15 (of 53 total)
You must be logged in to reply to this topic. Login to reply