#66-7/21/08: On The Shoulders Of Giants!
On The Shoulders Of Giants!
Can you think your way through management?
Posted by Steven Cerri on Monday, July 21, 2008
Hello everyone!
How does science progress? On the shoulders of giants, so the saying goes.
Those of you who have taken my classes have heard me say that for the typical engineer, management is a new career. That’s my saying.
You’ve also heard that science progresses on the shoulders of the giants who have come before us. All knowledge builds on the foundations of the past. Algebra is the foundation for the calculus which is the foundation for differential equations. We must understand one level before we can understand the next. And so it goes… until things get stuck.
Yes, stuck. In fact, science doesn’t move in nice progressive steps up the ladder of knowledge. Nor does it move in chaotic fashion. Science advances in logical, incremental steps with each level using the previous level as foundation, until progress can no longer be made. And then, a completely new way of looking at the world must often emerge. If science continues to rest on the known knowledge as it’s foundation for the next step, it will ultimately fail to model the world.
Therefore, for progress to ultimately be made, science must embrace that which has never been seen before. It must embrace a totally new way of understanding the world and it must abandon, to varying degrees, that which came before.
This has happened and is happening with relativity, as one example. Einstein developed the general and special theories of relativity. That worked well enough until it didn’t. Then we got quantum mechanics and the uncertainty principle. Those theories worked well enough until they didn’t and now we are seemingly moving toward string theory as one possible alternative.
So what does this have to do with engineering, engineers, and management. Well, it’s exactly the same process. As an engineer you think you can “think” your way through management just as you “think” your way through technical challenges. But the process of management is as different from engineering as quantum mechanics is from relativity. And whatever theories, rules, processes, and strategies you use to solve the engineering issues, I can guarantee you they will not work in the arena of management.
In fact, engineering is as certain as relativity at predicting the future. Management is as uncertain as the Heisenberg uncertainty principle at predicting the future.
The question is, which way of being in the world can you live with?
Be well,
Steven Cerri
“What would it be like to be as successful with people as you are with your technology?” Steven trains, coaches, and facilitates engineers and technical managers to BE the answer to that question. More information can be found at the:http://stevencerri.com/index.php/Home/index/
Copyright©2008 STCerri International and Steven Cerri. You are free to pass this information on to others and to reproduce it. If you reproduce it in whole or part please give attribution to Steven Cerri. Thank you.
Posted by Steven Cerri on 07/21 at 09:34 PM (0) Comments • (0) Trackbacks • Permalink
#65-7/14/08: Managing Projects Half A World Away
How To Manage Projects Half-A-World Away
Can I make a contractor part of my team?
Posted by Steven Cerri on Monday, July 14, 2008
Hello everyone!
I have a coaching client who has a big challenge. He is attempting the development of a website by hiring contract website development from overseas independent contractors and companies. He is finding programmers who are technically competent. In some cases very technically competent.
He uses instant messaging (IM) and emails and in some cases phone calls to communicate with his contractors. In most cases these are one-person shops. In one case it’s a small contracting company that has perhaps 100 independent contractors available to it.
However, he is having a difficult time “managing” them. They don’t return his emails in a timely fashion. Sometimes they’ll disappear for a week without a trace. When they finally show up again on the email radar screen they’ve finished their task and it’s well done, but my client is frazzled because he was out of contact for a week and didn’t know if the project was being worked on, or if the contractor was dead, or drunk, or on vacation, or.....
So my client contacted me and said, “What do I do?” “How do I manage these people?” “They’re driving me nuts.”
I asked my client what he wanted… and it boiled down to the following items:
1. He wanted the contractors to return his phone calls, IMs, and emails in a timely fashion.
2. He wanted the contractors to behave as if they were part of his team. He wanted them to be invested int he success of the project not just behave as “hired guns”.
3. He wanted to feel comfortable by having the contractors keep him informed as to what was going on regarding their part of the project.
My gut response to these requests is the same as Matchbox 20’s Rob Thomas sings in Santana’s song, Smooth; “Forget about it.”
Well, not quite. There is a solution.
Let me pose the question succinctly: “What is the best way to manage contractors who are located overseas and are doing programming work for you or your company?”
There are several steps that must be taken simultaneously, as follows:
Expectations: Lets get really clear about expectations. My colleague wants his overseas contractors to be part of his American team. In 90% of the cases that isn’t going to happen. Separated by thousands of miles, oceans, continents, languages, cultures, values, and beliefs, the expectation that your contractor will be committed to your project as much as you are or as much as your American employees are just isn’t going to happen. So don’t expect it. Expect that it’s going to be a job for your contractors and nothing more and prepare accordingly.
Genius or Hard Worker Here is the big one: Would you rather have a brilliant genius working for you overseas who you can’t control, does really brilliant work but causes you grief because you can’t track him or her down… or would you rather have someone who does work a little slower, is not quite so brilliant but gets the job done and is willing to keep you in the loop?
My coaching client has, up until now, opted for the genius who can get things done quickly but can’t be found to hand it over until my client has pulled out his hair. Unless I absolutely have to have the genius, I’ll always opt for the less brilliant but more cooperative team player. Remember, we hire people for their expertise and fire them for lack of fit.
Project Management Next, make sure that your projects are very well “contained”. By that I mean don’t make the projects too big. Make them small enough that you can control the design and functionality.
Who Does What?Next, you, the hiring entity, must decide on the functional requirements of the software. You must decide on what you want. The contractor/programmer decides on the implementation but you decide on the requirements.
My client has been giving himself a huge amount of grief because he has not been defining the functional requirements of the software well enough before giving the project to his contractors. He has been leaving it up to the contract programmer to decide not only the implementation but also some of the requirements and the design. This has left my client out in the cold. The best approach is to clearly, with structure, forms, documents, and change processes, lay out the requirements of the software. One can even go so far as to develop dummy screen shots of how the website is supposed to look. Where are the buttons to be placed? What text should be included and where do you want it placed? How are the users to move around the pages? How are the pages to “respond” to the user’s requests.
It’s the job of the hiring firm to design to a very specific level of detail what the website is to look like and what it is to do. For sure there can be adjustments as the design gets implemented, but the hand-off from the hiring firm to the programmer should be very detailed, very clear, and very structured. The only thing the programmer should do is make the requirements “happen”. My client should design and decide, and the programmer should implement and provide feedback. Obviously there can be some “give and take” here but not nearly as much as if the programmer is located down the hall from the manager.
My client has been managing his overseas contractors too loosely. He has been managing them as if they are part of his team. They are not. They don’t want to be and he should not expect them to be.
That means that he must go through the following steps:
1. Establish a clear visual representation of what the web page(s) and system are to look like.
2. Establish a written document that explains how the various functions and operations in the web page(s) are to perform their functions.
3. Provide clear milestones with timetables, and feedback events (i.e., meetings, documents, emails, phone calls, etc.) Work this out in conjunction the the contractor BEFORE work begins.
4. Establish incentive payments along the way so that when deliverables AND communications take place as planned, payment is made; otherwise there is some appropriate penalty. Don’t make the penalty punitive of you may not get anything back.
5. Select programmers and contractors who will work with you the way you want. Find those who can do the work you want done and do it the way you want it done. Don’t sacrifice the process by assuming that it will all “come out in the wash”.
6. Finally, when you find contractors who you work well with, ask them if they know of other contractors who they would recommend. Remember the old adage, “Birds of a feather flock together.”
When people are separated by thousands of miles, different languages, different cultures, significantly different values and beliefs, it is imperative not to make assumptions that they will work the way you work. It’s challenging enough to find that in your own company office building, why would you expect it with someone halfway around the world from a completely different country.
Remember: “Keep your local direct reports close. Keep your overseas contractors even closer.”
Be well,
Steven Cerri
“What would it be like to be as successful with people as you are with your technology?” Steven trains, coaches, and facilitates engineers and technical managers to BE the answer to that question. More information can be found at the:http://stevencerri.com/index.php/Home/index/
Copyright©2008 STCerri International and Steven Cerri. You are free to pass this information on to others and to reproduce it. If you reproduce it in whole or part please give attribution to Steven Cerri. Thank you.
Posted by Steven Cerri on 07/14 at 09:52 PM (0) Comments • (0) Trackbacks • Permalink
#64-7/8/08: Just Say No or Is It I Don’t Know?
Just Say No or Is It I Don’t Know?
What to do when you don’t have the answer.
Posted by Steven Cerri on Tuesday, July 8, 2008
Hello everyone!
Just say No or is it I don’t know?
How often do you say, “I don’t know?”
How often do you say, “I forgot to do that?”
How often do you say, “Sorry, I didn’t do it?”
To most engineers, scientists, and technical professionals these are deadly statements. No self-respecting engineer wants to say, “Oh, I forgot to do that”. And no self-respecting engineer wants to say, “I don’t know the answer to that”.
I can tell you, after managing engineers, scientists, and technologists for many, many years, if you want to really tick me off, give me an answer when you really don’t have the answer. Give me an excuse when you just forgot. Give me an answer when you were just too busy to get to it.
Probably more than most people, we engineers, scientists, and technologists think we are always supposed to have an answer. And not only an answer, but the right answer. I’ve watched engineers “dance” around topics because they just can’t bring themselves to admit they don’t have the answer, or admit that they just made a mistake.
I learned my lessons and got my chops when I was in college. I was raised on a farm and rather than work on the farm every summer during college I worked for Del Monte Corporation. It was better pay than working on the farm and it gave me exposure to something other than the family farm.
I worked in a “weight and inspection station”. This is the station that receives produce, in this case, tomatoes, from farmers. The trucks that bring in the produce are weighed as they arrive at the station, the produce is inspected and graded, the produce is off-loaded at the station, the trucks are once again weighed empty.
The tomatoes are inspected by government inspectors and inspection tags are attached to the produce load. The farmer is paid for the full tonnage of the tomatoes minus the percentage of the tomatoes that have been found to be rejected during inspection. The process involves a lot of weighing, tagging, inspecting, and reweighing. Numbers and tags are flying everywhere and in those days these tasks were not done in as automated a fashion as they are today. At the end of each 8-hour shift the weights of all the loaded trucks, minus their empty weights, should add up to the total of the tomatoes delivered to the station.
I was called a weight master and, during my 8-shift, I was in charge of weighing the trucks loaded and empty and ensuring the inspection numbers were accurately recorded for each load delivered.
Once or twice a week, during any weight inspector’s 8-shift (there were three of us) we could expect that our numbers, at the end of our shift, wouldn’t add up. Even if we were very, very careful it seemed to happen anyway.
Now at the end of my shift, if the numbers didn’t add up, it meant that I had made a mistake, somewhere, somehow, sometime during my shift. And after looking at the numbers a couple of times, if I didn’t find the error, it meant that we were not going to find the error. It was a recording mistake and that was that.
At the end of my shift I had two choices. I could tell my colleagues on the next shift of the error so they could start fresh with an adjustment, or I could keep my mouth shut and let them wrestle with the error as if it might have occurred on their sift.
I’m not sure I understand why, or what I had been taught, but my approach was to be “straight up” with my colleagues. If my numbers were off, the next shift knew by how much and that it had happened on my watch. No one on the next shift nor my manager ever criticized me for making an error. They knew I was doing my best. I didn’t make many errors, but when I did I told them about it right away. They just acknowledged it and we all went on from there.
It wasn’t until many, many years later that I found out from my father that one of the things my co-workers at Del Monte really appreciated was that when they came in to begin their shift they knew exactly what the situation was. I always told them whenever I had made a mistake and they could take it from there. Apparently that was rather unique. Other weight masters weren’t so forth coming with errors they had made.
I kept that philosophy throughout my engineering career and beyond. I always taught my direct reports that “I don’t know” is a perfectly good answer. I also taught my direct reports that I’m not too concerned about a mistake that happens once in a while. I am concerned about mistakes that are repeated.
So I’m not suggesting that you always answer with “I don’t know”. I’m looking for patterns. If a direct report is “always” telling me “I don’t know” or always telling me “I forgot to do it”, then we are in big trouble. But I don’t expect my direct reports to be geniuses or to have every answer to every question I might ask right at their fingertips. But I sure as heck expect them to be able to find the answer, given time.
So to all of you who think that you can’t answer a question with “I don’t know,.... but I’ll find out” or who think you can’t once in a while answer “I just forgot to do that… but I’ll get on it right away and have it to you ....” think again. If you aren’t being honest with your manager then you either have the wrong manager (you are working for Attila the Hun) or you are underestimating your manager and you need to have a talk with him or her.
Honesty is always the best policy. Straight up information is always the best approach. No one should expect you to be perfect, not your manager, not your customer, not even you.
If your work environment can’t abide an honest “I don’t know” or “I forgot to do it” then it will grind you down in the long run any way.
Be well,
Steven Cerri
“What would it be like to be as successful with people as you are with your technology?” Steven trains, coaches, and facilitates engineers and technical managers to BE the answer to that question. More information can be found at the:http://stevencerri.com/index.php/Home/index/
Copyright©2008 STCerri International and Steven Cerri. You are free to pass this information on to others and to reproduce it. If you reproduce it in whole or part please give attribution to Steven Cerri. Thank you.
Posted by Steven Cerri on 07/08 at 09:25 PM (0) Comments • (0) Trackbacks • Permalink