Contact us

Blog

Engineer Blog

At Least Half of Every Job Well Done is Made up of Non-engineering Aspects

Three Lessons for Effective Projects

What qualities do you think are important in an engineer? Technical expertise? Knowledge and research skills? Creativity? The stamina to go without sleep for days at a time? While there is something to be said for all of these, I believe the ability to run effective client meetings is as important as all three put together.

An Entire Lot Gets Rejected

This article concerns something that happened 36 years ago, about six months after I joined Kikusui. I was a member of a team that developed bespoke power supplies. Back then, we did not have enough staff to fulfill the high demand from manufacturers of electronic devices for bespoke power supplies, and the production of a number of our models was outsourced to a design contractor. One day, my boss informed me that a shipment of power supplies built by such a third-party contractor was about to be delivered, and that I should inspect them.

The following evening, I stood in front of ten switching power supplies, which had been laid out on a bench in the production division. As all were fitted with mains plugs, I suggested plugging in the first power supply to power it up. However, the second I plugged it in, the device gave off a “pop” and emitted a small spark as the fuse blew. At a loss, I moved to the second power supply to test that, only to have the same thing happen.

I immediately told my boss, who got straight on the phone with the third-party contractor. His voice was raised. It turned out the contractor had not bothered to “fire up” (plug in) the power supplies after assembling them.

A Crash Course in Modification

Hanging up the phone, my boss turned to me.

“Fire them up and test them without breaking them.”

I didn’t know how I was supposed to accomplish this with power supplies that would blow their fuses as soon as they were plugged in. In any case, I couldn’t do anything until I understood how they worked. First, I consulted the circuit diagram. It cryptically referred to a “MB3759 switching regulator controller”. I had no idea what this meant, and the circuit was a mystery to me. I set about researching the components, the circuit itself, and all the other aspects of the device. About two weeks later I had finally succeeded in getting all 10 power supplies operating, but they still did not conform to specification.

We could not deliver the power supplies to the customer as they were, so I began performing modifications so that they would conform to the customer’s specification. First, I rewound the switching transformers. Next, I redesigned the circuit boards. These were bespoke devices, so it was imperative that they were delivered on time. For the next month or so, I worked around the clock to get the job finished on time.

My efforts paid off, and we were able to deliver the first lot of 10 units on the agreed date. On the date of delivery, I accompanied our salesperson to the client’s premises. I will never forget the words of the client’s design engineer.

“Great! We can finally turn our devices on!”

These made-to-order power supplies had four fixed outputs that supplied +5 V, ±12 V, and +24 V. We would go onto deliver some 12,910 of the units, which went into commercial word processors that were capable of automatically converting text inputs into Japanese characters and cost a whopping $25,000 a piece.

The job was very rewarding for me, as our devices powered what was at the time state of the art technology. It was hard work, but I remember enjoying the experience of encountering new challenges and learning new things every day. This assignment also changed the way I would approach my work in the future.

Getting to the Root of the Problem

The assignment not only gave me technical expertise on winding switching transformers, selecting components, printed circuit board design, thermal design, and derating, but also taught me how to communicate with the other people on project.

The failure of the prototype delivered by the third-party contractor was not the result of some lack of technical expertise on their part. Rather, I believe the major cause of the problem was insufficient instructions from my side and the failure to share information properly.

I’m not sure about now, but in those days, instructions to contractors were terribly vague, often with no follow-up until the device was delivered. This meant getting a big shock when the device arrived. I learned later that the job I worked on was no exception: the initial brief was very vaguely articulated, with the natural outcome that the entire first lot of prototypes was rejected.

Three Lessons I Learned About Effective Meetings

The experience taught me the following lessons about effective meetings.

  • Always take minutes
    It is essential to take minutes in every meeting. Also, minutes are no good if they only serve as a record for yourself. The minutes must be shared with the other party if they are to be a record of both parties’ mutual understanding.

  • Clearly define what is restricted and what is left to the discretion of the other party
    A brief needs to do more than simply define what the contractor has to deliver and when. It also needs to define which parameters are subject to restrictions and which are left to the contractor’s discretion. If you simply hand the contractor a circuit diagram without any explanation, you will almost certainly end up with something you didn’t want.

  • Sharing schedules
    Almost every project has a schedule, and yet it is all too common for schedules not to be shared. When a final deadline has been set but development milestones are not disclosed, it becomes impossible to track progress, and you end up making a last-ditch effort to catch up, much like a school holiday homework assignment. Milestones, too, should therefore also be mutually agreed upon and made available for inspection.

Furthermore, a small development project may be possible to handle alone, but above a certain scale, you will need a team. In such development projects, the technical expertise of the individuals on the project is important, but equally important is communication. Unfortunately, there are no opportunities on the project for learning how to communicate effectively. (In most cases, it is just a case of imitating your more senior colleagues.)

It is my hope that in addition to honing their engineering skills engineers early in their careers learn how to work as a team. I believe that at least half of a job well done is made up of non-engineering aspects.

TEXT BY
Kazuo Akiyama
Solutions Development Section, Solutions Development Department (Supervisor)

[Major achievements in product development]
PAK-T, PAK-A, PAD-LET series regulated DC power supplies
PAX and PBX series high-speed programmable power supplies
PFX40W-08 battery charging and discharging tester

Contact us