Moral of Cooperation

Many junior people misunderstands the meaning of cooperation. Here is an email I once sent to my coworkers.

Hi Group,

Because the two groups are working together, cooperation is more important than ever. We have to ask about missing information from each other to come up with solutions. For that, I’d like to share
my thoughts about basic moral of engineers.

Let me begin by telling you two extremely bad examples.
By the way, those two people are not with us any more.

Horror 1
He came over to receive my program and port it for a custmer. Apparently, he didn’t know the syntax of Make and when his compilation didn’t work, his attitude was “I have to this important work done today. You have to help me.” He came to my cube every 30 minutes, and I had to tell him basics. This lasted all day long until I finally got mad.

Horror2
She was hired to work with C++. However her ability was just as she finished C++ course at the college. She noticed I always had knowledge for her problem, and eventually she came to see me a few times a day. I was like coding and debugging for her. This lasted until she got laid off.

Those examples are not real cooperation we want to accomplish. Let’s call them “noise requests”. My proposal here is to agree about what is the noise, to increase the oppotunity to serve the real requests from each other.

There are two major type of noise. I’ll talk about them below.

Asking what you can learn by reading books
I think it is lazy to expect to learn such things for free.
This takes time of other people.

Exception 1: “Do you happen to know a command to do such and such?” This sort of know-how is hard to pick up in books; asking such is one good advantage of working together.

Exception 2: Verilog engineer can ask Perl engineer help writing a script. But C engineer should not ask about C (or even Perl) syntax.

Exception 3: If you spent your time with my problem yesterday, I’d happy to help you today. It is a natural way of helping each other.

Reporting a problem without much analysis
“I run the program. It is failing.” is not a good communication. You are an engineer; take a moment to open the hood to look before calling
service.

However after your analysis, when you report it, do not include your analysis. In the report, it is best to describe what you did and what you got. Usually, even describing is bad. Just cut and paste the
session log, showing where is the problem.

Before reporting a problem, I always do this:

1. Summarize what I did and what I got, without my interpretation.

2. Think at least once if it’s not my fault, or if it’s not my job to look at the problem.

3. Think if I may be able to solve the problem even if it is not my specialty.

Thanks for reading. I hope you understand that I’m not saying “Don’t bother me.” Let’s keep noise requests at a minimum to increase cooperation flow.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s