Editor's Note: With the imminent launch of Intel’s next-generation Core processors at the International Consumer Electronics Show on Jan. 5, we thought it would be interesting to hear a perspective from the person who has been leading the chip design teams responsible for Intel’s latest flagship product. Ron Friedman is vice president and general manager of Intel’s Microprocessor and Chipset Development group responsible for microprocessor design teams in California and Israel, including Intel’s new “Sandy Bridge” architecture.
Previously, Friedman was design manager for the original Pentium M processor, He was also involved in the design of the next-generation mobile processor code named “Merom” — which would become the first mobile variant of the new Intel “Core” architecture, sold as the Intel Core 2 Duo.
As you and your teams worked on the new microprocessor architecture, what unexpected challenges did you run into?
Sandy Bridge was new to us in many ways. It was the first time at Intel that we were doing real integration of graphics and the IA core in the same die. And we were trying, at the same time, to prepare up-front for multiple permutations of the product — to allow the best optimization of cost and performance.
And finally, the team had to work with groups we hadn’t interfaced with before — but it was essential to establish good working relationships and close cooperation. Those were the main challenges in bringing Sandy Bridge to product release qualification.
Can you give an example of one of the unexpected technical challenges that arose?
As we integrated the graphics and the Intel Architecture on the same die, we had to figure out ways to validate the interactions between the compute core and the graphics — interactions that didn’t exist before, because they had been on two separate dies.
Debugging got much more complex, too. That’s because when you have functions on multiple dies, you have more interfaces exposed outside the silicon, which makes it easier to debug. When you are integrating everything on one die, you improve the cost and power envelopes — but the debug gets harder because there are fewer places to test.
If it was hard bringing the silicon together, how difficult was it to bring together teams from Israel, the U.S. and elsewhere? How do you handle cultural differences?
Absolutely, I think that there are differences between, let's say, American culture and Israeli culture. For example, in Israel, we are very accustomed to have heated discussions on everything.
Here in Israel, people interpret this as, “We care, and therefore we express our opinion openly.” And when we debate, it’s not because we want to offend anybody but simply because we care.
But in the U.S., sometimes it can be interpreted by people as “arguing for the sake of arguing.” So you have to educate the people both in Israel as well as the U.S. that, yes, they may witness different behaviors, and they need to interpret it correctly. And people need to be sensitive to the fact that interpretation may be different.
Are there ways U.S. team members might be misinterpreted?
For example, in the U.S., when they tell someone, "Hey, you may want to consider looking at X, Y, Z," it actually means, "You need look at this because maybe there is a problem there.”
But in Israel, they will hear that to mean it as simply a suggestion, like "Hey, I’ll think about it if I have time."
So how do you manage these differences?
Some of the people, of course, are experienced in working across cultures. But for those that are new to it we have cross-culture education classes. And we make sure that people that are in those interfaces are going through these classes and are aware of the cultural differences so they don't run into them unprepared.
How would you characterize your management style?
I talk to a lot of people in one-on-ones, in corridors trying to see how they feel, what problems they face, and how we can help them. I also believe that managers need to be technical at all levels. Our first-line managers, second-line managers, project managers, and even at my level, they need to be technical enough so they ask the right questions, make the right tradeoffs and identify problematic trends.
I believe in a learning organization. That is why in my groups, people view post-mortems and after-action reviews as a way of life, not as something that is threatening. It is simply a way to get group learning and continuous improvement.
Where did your management philosophy come from — did you have a mentor or did it come through all the experiences you’ve had?
I’ve worked with multiple managers — I learned different things from different managers, so I cannot say it was a single manager who defined my management style.
But I would mention two events in my career that really had a deep influence on me and the way I manage products.
The first was when I was a junior manager, working on the Pentium with MMX technology.
We were trying to adopt some new methodologies, which were supposed to be revolutionary and buy a lot of productivity. For various reasons the methodology didn't really lead to any improvements. But for a very long period of time, we kept blindly believing that the methodology would eventually pan out. And we weren't really looking at the mirror, comparing our progress to other similar projects and figuring out that we were really late.
At the end of the day, we were late with the project by six months. Pentium MMX did turn out be very successful in the market. But I did learn that you can’t simply, blindly believe something without doing benchmarking, comparing to other projects.
The second was when I was working on a project called Timna. I was responsible for the design of the second half of the project. We were ready to bring these products to market — but it turned out the marketing team didn’t really know how to sell it. So we brought the product to market — it was already in production — but it got cancelled.
That was a really traumatic experience. And what I learned from this experience is that our job as a project manager or engineering manager is not just to design the product, but to be involved in the goodness of the product and the way that it will be marketed and sold. Because if you don't do that, you may end up with a product that is great engineering-wise, but that the marketing team doesn’t really know how to sell.
How do you keep a balanced life?
I can't say that there is a simple recipe. I'm traveling to the U.S. and to other geographies every month where I have teams.
It certainly takes a toll. I think you need to define the boundaries. You need to say, “OK, I'm willing to have meetings in these hours and not in other hours. I'm willing to have a two-hour meeting during my weekend and not more than that. I'm willing to travel to the U.S. once a month and not once every three weeks.”
You really need to set the boundaries — because there is always more work and more meetings to attend. And of course when you have a family that is supportive, it's of course very helpful.
What do you and your family like to do when you do have down time?
We like to travel, even though I fly a lot and I hate airports. We like to do a lot of sports together — water sports, playing tennis together, doing active vacations.
Maintaining that balance was tougher when we had smaller kids. My children have already finished their high school. So today, it’s easier.
To be open, I am probably addicted to work. I always travel with my laptop. So down time is when the mail server is down.