Why is Engineering the last to call for help?

Engineering and the product development organization are critical to a company’s survival. In successful companies, they deal daily with a vast array of problems, from technology shifts to people loss. One of the key talents of successful technical managers is to deal with changing priorities and resource availability. They manage these dynamically whether by PERT charts or just seat-of-the-pants intuition.

So why is it that they don’t often ask for help?

I believe it has to do with two aspects of the occupation itself.

(1) When your daily life is filled with adaptation and improvisation, you have trouble imagining that there is anything anyone can do to help. Your talent as a technologist managing others is to be able to evaluate technical directions in an instant, moving people around to cover the top priorities of the day, and communicating to your bosses what is going on. How could a consultant or an internal mentor help this kind of activity?

(2) You are already in the midst of trying to improve the engineering process and the way your people accomplish projects. You have the credibility with them, so you can influence their work to improve a little at a time. It is inconceivable that an outsider, or a non-specialist insider, could have more influence on your staff.

The Marketing Department and even the Finance people know that Engineering is in trouble when products don’t get completed on schedule, turnover is high, or products need extensive tweaking to meet customer needs. But inside Product Development, life is normal: dynamically adapting to the shifting priorities, making quick decisions about fixes, and just getting the next product out the door.

The only way to get the processes to improve significantly is to get perspective. And perspective is the one thing that most Engineering departments don’t have. They’s too busy meeting their commitments. Perspective is what consultants and internal mentors have.

Managing and listening

What makes management difficult for people who are technical experts? In a way, it’s like the reputation that medical doctors have when they are managing their investments — they are so accustomed to being the ones who “know” they have trouble taking advice from financial advisors. As a result, docs are reputed to be have the worst record as self-managed investors.

I can sympathize. As a technologist, I tried managing my own investments over a long period of time. Eventually, I realized that I “knew too much” about the technology and the companies as technology sources. So I would invest in companies that had great technology, but they would turn out to have poor businesses or inadequate marketing — things I didn’t recognize.

Moving from technical contributor (engineer, programmer, analyst, etc.) to manager is another difficult transition in which the contributor is accustomed to “knowing.” As a resource for others on technology, we’re used to being the authority. So the first thing we have to learn as managers is humility.

Actually, the first thing we need to learn is that management is an honorable profession with its own set of objectives, methods and styles. Our training is in “hard” sciences and technology, so we’re rarely prepared to deal with the “soft” stuff of people interactions, influencing, leading, and communications. So let’s be clear: there are a lot of new things to learn about.

Since we tend to manage our interactions by intuition and by reference to our upbringing, most of what we do as managers is not conscious: we don’t see it as skills, but temperament. Believe me, however, you CAN change your interactions. The keys? Being interested in becoming effective as a manager. Becoming aware of the effect we are having on people. Being willing to listen to feedback. Being willing to listen.

Being a manager is all about dealing with non-quantitative stuff. Let the MBAs bring out their spreadsheets. When we need to do quantitative measurements, we’ll have plenty of expertise with the methods and the tools. What we need is a willingness to listen, learn and improve.

Improve what? How do we measure ourselves as managers?  We’ll address this question in a future blog post.

Death by Mismanagement

I had breakfast recently with an old colleague who is a top-notch ASIC designer. Among the many stories he told me, the lessons of this one stand out:

One year when he had been a key player in designing a new interface that doubled the speed of the devices we made, he was nominated for “Inventor of the Year.” But he didn’t find out about this nomination from his boss. Instead, he was invited to the dinner event at which the award is given out (without anyone knowing in advance which of the nominees is to receive the award). Of course, he says, he didn’t receive the award; his boss, who had to attend the event with him, would not make eye contact with him during the event.

Later, at annual review time, he was ranked in the bottom 1/8th of the company’s contributors. Naturally, he was curious about how this could happen while he was being nominated for Inventor of the Year. He asked HR about it. “Is this consistent?” he asked. “Of course not,” they replied.   “Can you do anything about it?” he asked.   “No.”

When management is sending two extremely conflicting messages to individual contributors like my colleague, it is an indication of deep trouble at several levels in the company. First, the immediate boss was almost certainly acting out a personal aversion — if not vendetta — against this engineer. Second, the fact that no one from higher levels of management were willing to take action is a sign of serious sickness in the company.

How long would you expect a company to last which sends such messages to experienced and long-term contributors? In fact, the “boss” in the story above was eventually laid off. But the damage to the engineer’s morale and respect for the company was irreversible.

And so, no doubt, was the decline in the company’s competitiveness. The company’s sale to a former competitor was announced just a couple of months later.