Process, People, and Tools - where do you place your trust?
-
Mawi Ramos wrote:
If I don't trust People, I can't trust Process and Tools since basically it's the People who make these two.
That's a very good point. :) Marc
Thanks. I hope I've somehow helped you in your dilemma :)
A designer knows he has achieved perfection not when there is nothing left to add but when there is nothing left to take away Antoine de Saint-Exup'ery
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
Full Trust: no one Partial Trust: on everyone
Proud to be a CPHog user
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
I trust only myself. :~
-
Gary R. Wheeler wrote:
So... why are you asking? Feeling betrayed lately? The System got you down?
Because my client has broken (or actually no) processes, people have proven to be untrustworthy, and the tools don't work, probably because of the lack of processes and the inept people. Marc
That's been my experience too - if one of the three is broken, all three tend to be. Good luck. Is this your chance to be a knight in shining armor?
Software Zen:
delete this;
Fold With Us![^] -
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
In my business, I trust process first, then people, then tools. If we make a mistake, people can die and property burns. Every action is preceded by writing a process, called a switching procedure, then all of our staff review it. It's called a "tailgate" meeting. The newest apprentice is entitled to object or question any step, and everything stops until that question is answered. I, myself, when I was two weeks on the job asked a question about a switching action, and everyone listened. It turned out that I'd caught a step missed by my boss, who has 30 years' experience doing what I'd never done at the time. They listened, corrected the procedure, and thanked me for catching the mistake. Tools can always fail, however simple. We use insulated hotsticks for switching, but we wear gloves rated for 30kV when using them, because sticks can fail and you don't live through it usually. There's nothing we can do about multiple failures, but we never fail to take every precaution available, just in case. I deviated from the intent of your question just to illustrate the wide range of possibilities. I know you're talking about other circumstances. In general situations, I trust the people who know how to get the job done. Policies and procedures are just shortcuts to avoid thinking, and having to evaluate all situations individually. All policies and procedures need exception mechanisms that allow people to make the final decision; things come up that the standards didn't anticipate. Both tools and procedures also become obsolete, and need to be re-evaluated once in a while. Those that no longer fit should be abandoned without remorse. One of the best books I've ever read is called "Sacred Cows Make The Best Burgers" and I commend it to your reading list. From it I learned ways to objectively view policies and procedures that have been in place forever and to unemotionally determine whether they really fit the way we do business today. Those that no longer work need to be dumped, and new ways defined. Similarly, people who will not give up doing things "the way we've always done it" need to be dumped. They only impede the progress of the rest of the organization. Overall, to function efficiently you must be able to trust all three - Processes, people, and tools. Any that don't function must be put to pasture or the company is doomed.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
Marc Clifton wrote:
So, where do you place your trust
In me.
My Blog: http://cynicalclots.blogspot.com
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
Processes? We sort of have a process; you write the code, you test the code, somebody else tests your code. This generally finds coding mistakes. It doesn't really coordinate anything though. People? I don't really trust my coworkers. I've been given far too many of their projects that they screwed up and I have to fix. They all follow the process though. Tools? We have one tool that causes a lot of problems: SourceSafe. For most of our coding projects, we all have to edit the same project file. Thanks to SourceSafe we can't all edit the file at the same time so we end up doing a lot of check-out, edit a little, check-in so somebody else can check-out, edit a little, then check-in. We recently had a disaster where someone's changes got overwritten by somebody else and we lost a week of work that had to be made up in one night as we were doing a version release that night. Like several others before me have mentioned, I have learned to trust only myself.
My mind is like an aluminum trap. Some things get caught in the trap, and some things bend the trap and get away.
-
Processes? We sort of have a process; you write the code, you test the code, somebody else tests your code. This generally finds coding mistakes. It doesn't really coordinate anything though. People? I don't really trust my coworkers. I've been given far too many of their projects that they screwed up and I have to fix. They all follow the process though. Tools? We have one tool that causes a lot of problems: SourceSafe. For most of our coding projects, we all have to edit the same project file. Thanks to SourceSafe we can't all edit the file at the same time so we end up doing a lot of check-out, edit a little, check-in so somebody else can check-out, edit a little, then check-in. We recently had a disaster where someone's changes got overwritten by somebody else and we lost a week of work that had to be made up in one night as we were doing a version release that night. Like several others before me have mentioned, I have learned to trust only myself.
My mind is like an aluminum trap. Some things get caught in the trap, and some things bend the trap and get away.
FyreWyrm wrote:
It doesn't really coordinate anything though.
If there's no feedback, the process is worthless. Coders learn nothing from errors they never hear about. Software development is iterative; code evolves as requirements are defined with each buld. If your people don't get feedback from the testers they're doomed to repeat past mistakes. Coordination is critical, and if it doesn't take place you badly need a new system. Your people have got to be in "the loop" to be effective.
FyreWyrm wrote:
I have learned to trust only myself.
That gets lonely, and leaves you exposed. You're working for a seriously dysfunctional company if you have to resort to that sort of defensive thinking. It's time to reorganize things, or get out.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
In my business, I trust process first, then people, then tools. If we make a mistake, people can die and property burns. Every action is preceded by writing a process, called a switching procedure, then all of our staff review it. It's called a "tailgate" meeting. The newest apprentice is entitled to object or question any step, and everything stops until that question is answered. I, myself, when I was two weeks on the job asked a question about a switching action, and everyone listened. It turned out that I'd caught a step missed by my boss, who has 30 years' experience doing what I'd never done at the time. They listened, corrected the procedure, and thanked me for catching the mistake. Tools can always fail, however simple. We use insulated hotsticks for switching, but we wear gloves rated for 30kV when using them, because sticks can fail and you don't live through it usually. There's nothing we can do about multiple failures, but we never fail to take every precaution available, just in case. I deviated from the intent of your question just to illustrate the wide range of possibilities. I know you're talking about other circumstances. In general situations, I trust the people who know how to get the job done. Policies and procedures are just shortcuts to avoid thinking, and having to evaluate all situations individually. All policies and procedures need exception mechanisms that allow people to make the final decision; things come up that the standards didn't anticipate. Both tools and procedures also become obsolete, and need to be re-evaluated once in a while. Those that no longer fit should be abandoned without remorse. One of the best books I've ever read is called "Sacred Cows Make The Best Burgers" and I commend it to your reading list. From it I learned ways to objectively view policies and procedures that have been in place forever and to unemotionally determine whether they really fit the way we do business today. Those that no longer work need to be dumped, and new ways defined. Similarly, people who will not give up doing things "the way we've always done it" need to be dumped. They only impede the progress of the rest of the organization. Overall, to function efficiently you must be able to trust all three - Processes, people, and tools. Any that don't function must be put to pasture or the company is doomed.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
How are your processes reviewed and improved? That is the key problem I have with most process systems. They start well but do not evolve and people become dependent on antiquated process which ends up killing them (or the project if there is no 30kV supply involved. Crikey.)
cheers, Paul M. Watson.
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
"So, where do you place your trust?" I place my trust in : "trust nothing, question everything." best, Bill
"The greater the social and cultural distances between people, the more magical the light that can spring from their contact." Milan Kundera in Testaments Trahis
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
It's quite shocking the number of people who only trust in themselves. This really doesn't do you any favors in the long run. For a start it kinda suggests you need to work a little your social skills! I once felt exactly the same. Then I realized that my dreams were far to big to become a reality relying only on myself! I came to the conclusion that unless I code up an intelligent being, I'm not going to get very far by myself. Trust is earned you don't have to trust everyone, be frank if they don't do it to standard then tell them. Processes above tools any day thats an easy one. AS for people, they should be trusted to develop the processes with you. The guys following the process should feel responsible for improving and maintaining them with support from their managers. The guys doing the work should also be working on how they do it! Managers should facilitate this, they should get their hands dirty and understand things from the bottom up. This rarely happens how many times have you had to follow a really dumb process? But don't moan too much the coding world is far more advanced in terms of processes and standards than many other industries. This comes with the job a good coder secretly get all excited by the idea of standards.
Steve O'Brien A successful person isn't necessarily better than her less successful peers at solving problems; her pattern-recognition facilities have just learned what problems are worth solving. - Ray Kurzweil www.newicon.net
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
Marvellous question! The first port of call is whether you trust the people. People have to earn trust and prove their competency not just to their employers, but also to their co-workers. I don’t have trouble trusting someone who has demonstrated their competency. If you are surrounded by people who have sufficiently proven their competency and are trustworthy, then you can look at the process. The processes are (in my humble opinion) both a way to catch and compensate for mistakes and a way to improve coordination and effectiveness in the team. Bad processes can ruin good developers and good teams, but I believe that good teams will naturally gravitate towards good processes. Processes are only as trustworthy and effective as the whole team. I always view a process with a little suspicion and I always question the processes’ effectiveness and the steps involved in it: is it as good as it can be? If the team is good I have less suspicion about the process but if the team is bad I have great trepidation about the process. This leaves tools... there are some good tools out there and some bad ones. If a good team with good process is using a bad tool then you will get bad results, but the good teams will again naturally gravitate towards good tools. Like processes, I always regard tools with suspicion: does this tool really help me in my work? If it doesn’t or I can find a better tool, then I use a better tool. Even if a tool is spectacular, it will not solve the problems of a bad team or a bad process. I've been doing some research about this area recently and thought I'd share a little of what I've learned. Ciarán
-
Gary R. Wheeler wrote:
So... why are you asking? Feeling betrayed lately? The System got you down?
Because my client has broken (or actually no) processes, people have proven to be untrustworthy, and the tools don't work, probably because of the lack of processes and the inept people. Marc
Marc Clifton wrote:
Because my client has broken (or actually no) processes, people have proven to be untrustworthy, and the tools don't work
SN-AFU.
Cheers, Vıkram.
Stand up to be seen. Speak up to be heard. Shut up to be appreciated.
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
I am equating trust with predictability - mainly. Least is People. As the circumstances change their commitment and performance becomes less predictable. I'm not a mind reader. Emotion, prejudice, greed, laziness, etc. clouds reason. Process, if you mean the broader sense, can be very predictable. There are always processes at work. Knowing how to discover and normalize them can result in a high degree of predictability. I was a process consultant for a large CPA firm at one point. I did forensic systems work mainly. There was always a predictor that the client missed that foretold the failure of the system they bought or built. I was hired to find it. The result of this was often messy. I learned lot about processes and systems project management doing this. Tools used the same way each time are very predictable, if viewed as implementations of algorithms. I certainly have doubted the ones I use daily when I keep getting a syntax or logic error. But its always me and not the tool in the end. Sometimes limitations in tools like interpreters and compilers are at the root. The messages are misleading but there is an error there. One bizarre one I had recently, when coding too late and should have stopped but stubbornly kept going. I had misspelled my JavaScript Array prototype statement. I kept getting a syntax error that I had an extra \n hidden somewhere (a nasty red herring). I thought I may have entered a control character or had a \n in position 200 on a line, or something similar. I was starting to doubt my VM, then finally after Firebug, Komodo, IE Dev Toolbar, etc., etc., my eyes cleared for a moment and there it was a dumb-s... typo. :)
"Coding for fun and profit ... mostly fun"
-
In my business, I trust process first, then people, then tools. If we make a mistake, people can die and property burns. Every action is preceded by writing a process, called a switching procedure, then all of our staff review it. It's called a "tailgate" meeting. The newest apprentice is entitled to object or question any step, and everything stops until that question is answered. I, myself, when I was two weeks on the job asked a question about a switching action, and everyone listened. It turned out that I'd caught a step missed by my boss, who has 30 years' experience doing what I'd never done at the time. They listened, corrected the procedure, and thanked me for catching the mistake. Tools can always fail, however simple. We use insulated hotsticks for switching, but we wear gloves rated for 30kV when using them, because sticks can fail and you don't live through it usually. There's nothing we can do about multiple failures, but we never fail to take every precaution available, just in case. I deviated from the intent of your question just to illustrate the wide range of possibilities. I know you're talking about other circumstances. In general situations, I trust the people who know how to get the job done. Policies and procedures are just shortcuts to avoid thinking, and having to evaluate all situations individually. All policies and procedures need exception mechanisms that allow people to make the final decision; things come up that the standards didn't anticipate. Both tools and procedures also become obsolete, and need to be re-evaluated once in a while. Those that no longer fit should be abandoned without remorse. One of the best books I've ever read is called "Sacred Cows Make The Best Burgers" and I commend it to your reading list. From it I learned ways to objectively view policies and procedures that have been in place forever and to unemotionally determine whether they really fit the way we do business today. Those that no longer work need to be dumped, and new ways defined. Similarly, people who will not give up doing things "the way we've always done it" need to be dumped. They only impede the progress of the rest of the organization. Overall, to function efficiently you must be able to trust all three - Processes, people, and tools. Any that don't function must be put to pasture or the company is doomed.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Roger Wright wrote:
Sacred Cows Make The Best Burgers
The title alone is great :-D.
Software Zen:
delete this; -
Processes? We sort of have a process; you write the code, you test the code, somebody else tests your code. This generally finds coding mistakes. It doesn't really coordinate anything though. People? I don't really trust my coworkers. I've been given far too many of their projects that they screwed up and I have to fix. They all follow the process though. Tools? We have one tool that causes a lot of problems: SourceSafe. For most of our coding projects, we all have to edit the same project file. Thanks to SourceSafe we can't all edit the file at the same time so we end up doing a lot of check-out, edit a little, check-in so somebody else can check-out, edit a little, then check-in. We recently had a disaster where someone's changes got overwritten by somebody else and we lost a week of work that had to be made up in one night as we were doing a version release that night. Like several others before me have mentioned, I have learned to trust only myself.
My mind is like an aluminum trap. Some things get caught in the trap, and some things bend the trap and get away.
FyreWyrm wrote:
SourceSafe. For most of our coding projects, we all have to edit the same project file. Thanks to SourceSafe we can't all edit the file at the same time so we end up doing a lot of check-out, edit a little, check-in so somebody else can check-out, edit a little, then check-in.
This is a case where your process is defective, not your tools. There is no tool out there that would allow all of you to edit the same project file simultaneously and maintain its consistency and correctness. You need to break the project up into smaller, more manageable pieces.
Software Zen:
delete this; -
How are your processes reviewed and improved? That is the key problem I have with most process systems. They start well but do not evolve and people become dependent on antiquated process which ends up killing them (or the project if there is no 30kV supply involved. Crikey.)
cheers, Paul M. Watson.
Paul Watson wrote:
How are your processes reviewed and improved?
By any and all of us. One nice thing about working with something as tangible as electricity is that it always obeys the laws of physics - it's objective. It helps some that each action is unique, except for a few things we do fairly often. Each process is written for the specific action and reviewed by everyone involved. Once it is approved, we use it. If it works, we keep it. But anytime we make a system change we review the associated procedures again to ensure that they still make sense and are safe to use. We've had a few minor mishaps; once we opened a switch and started a 69kV arc that would not go out until the switch was slammed shut again. Checking with the manufacturer revealed that the switch was designed to open a line no more than 12 miles long, and our line was 22 miles long. Oops. More recently we asked our supplier to open a breaker to kill a line (the same line) before we tried switching. They did, one of our linemen started to open the switch, then the line suddenly came hot again. It turned out that the supplier's procedure was flawed, as well - it didn't include disabling the feature that automatically restores power when the voltage drops. Both procedures have since been fixed and tested. It has to be a continuous process - review, test, revise - for it to work. I think we're lucky that the danger factor is involved, as it makes everyone very conscious of the importance of having procedures that work. For more mundane issues - like a HR policy - the urgency isn't there, and bad procedures can sit and molder for years, far past the time when they may have been useful. Those are the organization killers. One such caused me to leave my first engineering job. There were two employee rating systems in use, one the employee could see, and the other a secret rating that only managers could access. While my ratings were excellent in the open file, I found out later that my secret file contained a "Z" rating - too valuable to promote out of the current position. That was a bad policy, and I'm not the only one who left because of it. I assume they never changed it, as they went out of business about three years after I left. Probably ran out of employees willing to work for them...
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Let me explain. Process: do you have processes that you trust? Are the processes there to compensate for mistakes people make, or to facilitate the work they do and facilitate coordinating work among people and across departments? People: do you trust your coworkers to do their work competently, to follow the processes, etc? Tools: Do you trust your tools, or are your tools causing problems? Are they causing problems because the process of using the tools is broken? The people using the tools don't use them appropriately or haven't configured them to actually be useful? So, where do you place your trust? Marc
Processes - very little trust (Since I work developing the processes I know how bad they can be ;) ) They are only as good as your people. Tools - again, only as good as the people who use them. A screw drivers no good if you can only use a hammer. People - more to the point, the RIGHT people. Some I trust some I know not to trust. If you get the right people using the right tools with a process that is flexible enough to accomodate the job then...BAM! the project is a success.
-
A little trust and a little doubt in all. I personally don't like fully automated completely because it takes the human out of the equation. I prefer semi-automated guns, I mean processes, because you can kill, I mean check, intermittently what's going on.
A little intermittent killing is a dangerous thing :laugh:
-
In my business, I trust process first, then people, then tools. If we make a mistake, people can die and property burns. Every action is preceded by writing a process, called a switching procedure, then all of our staff review it. It's called a "tailgate" meeting. The newest apprentice is entitled to object or question any step, and everything stops until that question is answered. I, myself, when I was two weeks on the job asked a question about a switching action, and everyone listened. It turned out that I'd caught a step missed by my boss, who has 30 years' experience doing what I'd never done at the time. They listened, corrected the procedure, and thanked me for catching the mistake. Tools can always fail, however simple. We use insulated hotsticks for switching, but we wear gloves rated for 30kV when using them, because sticks can fail and you don't live through it usually. There's nothing we can do about multiple failures, but we never fail to take every precaution available, just in case. I deviated from the intent of your question just to illustrate the wide range of possibilities. I know you're talking about other circumstances. In general situations, I trust the people who know how to get the job done. Policies and procedures are just shortcuts to avoid thinking, and having to evaluate all situations individually. All policies and procedures need exception mechanisms that allow people to make the final decision; things come up that the standards didn't anticipate. Both tools and procedures also become obsolete, and need to be re-evaluated once in a while. Those that no longer fit should be abandoned without remorse. One of the best books I've ever read is called "Sacred Cows Make The Best Burgers" and I commend it to your reading list. From it I learned ways to objectively view policies and procedures that have been in place forever and to unemotionally determine whether they really fit the way we do business today. Those that no longer work need to be dumped, and new ways defined. Similarly, people who will not give up doing things "the way we've always done it" need to be dumped. They only impede the progress of the rest of the organization. Overall, to function efficiently you must be able to trust all three - Processes, people, and tools. Any that don't function must be put to pasture or the company is doomed.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Roger Wright wrote:
I deviated from the intent of your question just to illustrate the wide range of possibilities
Well, that made for a fascinating read, as usual. And thanks for the book recommendation too!
Roger Wright wrote:
Overall, to function efficiently you must be able to trust all three - Processes, people, and tools. Any that don't function must be put to pasture or the company is doomed.
Agreed. Hard to do though, when the process for evaluating the processes, people, and tools is frought with inaction, emotions, and politics. :) Marc