The Power And Limits Of Money

What motivates successful engineering organizations, and why Google, Facebook and Amazon don’t get or keep all the talent.


Wally Rhines, CEO of Mentor Graphics, sat down with Semiconductor Engineering to discuss how semiconductor engineering teams make their dollars work even when budgets are limited. The issue is as important as ever, given the industry’s unrelenting margin and cost pressure and the growing competition for top talent. What follows are excerpts of that conversation.

SE: How can semiconductor companies ensure their engineering dollars are well spent?

Rhines: Spending earlier is better in any design project. The problem is the tendency to put off the spending until things get tough, which is really just passing the buck. Take a design’s power budget. Early in the architecture if it doesn’t get there, maybe you have some uncertainties. But you are always aware that you have to keep the schedule, and people start to feel that ‘we have to keep moving in the program’ squeeze. What that can mean is the last person gets stuck with an impossible goal. It’s human nature to put things off and think things will get better. But, they don’t always get better. And we all know, there is a budgeted amount [of man-hours and resource-spending]. Squeezing people is a motivator in many cases. But sometimes it’s the father of poor products and late products.

SE: What about salaries? How do semiconductor companies pay enough for the engineers they need but not blow their budgets? How important is being the top salary payer?

Rhines: I’m probably in the minority on this, but I’ve been at this a long time. Over my years of experience, people want to be paid fairly but they really want to be part of something exciting and feel valued. At TI, where I worked for 21 years before I came to Mentor, I led a consumer products group. We made chips for calculators and for the ‘Speak & Spell’ and all sorts of things. The design engineers could finish the project and take the calculator home and show their families. They could see their product and know it was selling and helping kids learn math and all of that. It was really motivating and exciting to be a part of that. One company I worked at had a semiconductor project. It was a very aggressive program for a microprocessor, but it had gotten out of control. It was late. People started to put on the squeeze: ‘Just get the tape out,’ and ‘Just do what you have to do.’ You cannot force good people, good engineers, to do bad work. It makes them unhappy and causes problems. And no amount of money changes that.

SE: This is a great example.

Rhines: On that consumer team, we had these old beat-up metal cubicles—tiny desks, five people in a cubicle. The roof leaked. We worked crazy hours for the whole two months leading up to CES. But I never lost a person. The microprocessor team had new furniture, big on-the-spot cash bonuses, extra break time, limited hours, all the perks you try to give people. But they were losing people day after day because they were working on something they weren’t proud of. Salary level is important. You always need to pay people fairly. But it’s not the only thing.

SE: How does that dynamic on paying engineers and keeping them productive play out today?

Rhines: There are companies in the Bay Area giving out absolutely exorbitant pay to get good people. We [at Mentor specifically, and EDA in general] can’t compete with that. But we do compete in a way, because we are giving people challenging tasks and making sure they know that what they are doing is important to us—and making sure they know we know that and recognize their contribution. If you are asking people to do mediocre work on an unimportant project, there is no salary you can pay good engineers to do that.

SE: And you face deep pocketed competition from companies like Google, Facebook and Amazon for software engineers, which every semiconductor company needs for their embedded systems, right?

Rhines: Extraordinarily deep pockets. But they want these people to help a huge dispersed team optimize database search. People are tempted. They say, ‘The money is too good, I’ll go do this for a while.’ But I’ve never seen anyone who made that decision who ends up feeling good.

SE: Let’s talk about a semiconductor company and how it sets its program budgets, and how it decides which tools and processes and people to spend on.

Rhines: Setting budgets and spending money to impact engineers and designers is an interesting one. After TI I moved to the other side. For the last 23 years, I’ve been on the side of providing tools and watching what the semiconductor companies decide to spend on. People think productivity is the key driver, but that’s not always true. There are two things that drive purchases at the management level—capability and cost. When they talk productivity you always hear management say, ‘We don’t need that new tool, our engineers can work Saturdays and Sundays.’ That’s a mistake. What causes management to actually make an investment in a new tool—the big thing—is capability. You get to a project that you realize you cannot complete unless you adopt a new technology or a new tool. It’s natural to be squeezing every penny. ‘I don’t want to spend more than I absolutely have to,’ is the notion. I’m trading off my engineers working harder and working smarter versus giving them the tools. That’s a tradeoff that frequently is not made. Short of waiting for a project to turn into a disaster, are there ways you can spend intelligently? When it’s a new capability, the first thing that’s important is to target them to a group that is competent and can benefit from the new capability.

SE: Is there an example of a company or executive that really understood this?

Rhines: Henry Samueli at Broadcom would personally sponsor a best-practices study, and be actively, personally involved in it. Every year, he sponsored a careful review of what worked best in their design engineering programs. And it’s a matter of being open enough that groups could try new things, but then applying a regimen and rigor to that. And then, based on the results, fan that out to the entire organization.

SE: Why do some executives get that while others don’t? Do they need to be directly involved with the product engineers and how they do their work?

Rhines: Sometimes at that higher level of management, especially if things aren’t going well, they are bombarded. It all becomes noise, and you see them just push that work down to others.

SE: How important are conferences and travel for semiconductor engineers?

Rhines: At Mentor, we do think that’s important and we always encourage our people to build an international following. But you have to prioritize. You can’t be too democratic. And you have to have standards. The kind of conference where you have published a paper, say at ISSCC [ the International Solid-State Circuits Conference], is more important than a poorly attended conference. The travel cost is actually minor versus the time lost having a key person away.

SE: The cliché is that engineers are hard to manage. How do you identify engineering team leaders who can manage schedules and budgets and keep their people motivated?

Rhines: It’s a hard to generalize. They come in all shapes and sizes. I’m an advocate of managers who interact with their people. In general, and I’ve been at this a lot of years, managing by the numbers tends to make the wrong decisions over time. And I always believe in the importance of having project managers who have gone through the experience of what the engineers are trying to do. They have done it themselves. That is always better than someone who learns it from their business school training.

SE: That helps the team leader understand what everyone needs, and helps that leader advocate up the chain for the spending, right?

Rhines: Yes. With almost every tool, the adoption ultimately occurs because you can’t do it any other way. The people who get differentiation from that change to a new tool, or that decision to spend, are the ones who have anticipated the need before it becomes a problem. I’ll give you an example. Even after I joined Mentor, the standard for physical verification was Dracula from Cadence. But it was clear it was breaking for some folks. We started a skunkworks program where we were introducing hierarchy to physical verification. That became a family of products called Calibre. [Cadence has since introduced Virtuoso for DFM.] Most of the adoption of Calibre occurred because people found that they couldn’t finish their verification with the existing products. But, importantly, there were a few people who did it in anticipation of that need. It was much more differentiating for them because the adoption was done. We had been talking to one of our customers, but they hadn’t made a decision. There they were in their Dracula verification. It’s still running. One week goes by. It’s still running. After two weeks, they called us. That’s not the time to try a new tool. There is proven data that the more you spend early on, the bigger the benefit, versus the more you spend late in the process to fix problems after they have arisen, the more expensive and the less effective the spend is.

Leave a Reply

(Note: This name will be displayed publicly)