* Jerry Sanders | 1969—2002 | Founder, electrical engineer * Hector Ruiz | 2002—2008 | Electrical engineer * Dirk Meyer | 2008—2011 | Computer engineer * Rory Read | 2011—2014 | Information Systems * Lisa Su | 2014—present | Electrical engineer
And yet only two of them (Jerry and Lisa) are considered truly successful at running the company and one decent at keeping things afloat (Rory). The real answer is much more complex and has to do with Intel’s constant monopolistic actions against AMD; some internal struggles (overheating issues early on, bad laptop support, spinning off business divisions right before they were set to be wildly valuable [Adreno, Spansion, etc], wildly overpaying for ATI, etc).
While Jerry and Lisa are both great CEOs for the company, and all credit belongs to them for their leadership; AMD’s woes were simply more complex than that.
What i have seen in other companies is that even if the CEO is a subject matter expert, they get to the level of CEO then start deferring business matters to the MBA's who are viewed as subject matter experts of business. This weak leadership and difference to MBA's often leads to extreme short term thinking and lack of vision centered around quarterly probability statements not around core competences or a vision for making the companies product good
I’m a big proponent of domain drive design, at least in principle, but I’ve yet to meet the manager who’s going to let developers “waste” the time of the domain experts on “pointless minutiae” instead of just shutting up and writing the damned software.
Don’t shy away from learning the business. The hardest part of my MBA was accounting — and you can take an accounting class at community college.
Good sales people "want" make your company viable by having money
Tech people "want" to have state of art product
Both are good things at different moments of company lifetime
It sucks to have only engineering people and no people who can do business.
Intel has been dropping the ball in engineering precisely because their teams seem to be focused exclusively on the next quarter/year results.
In a market where it takes 5y to get a product out, you need your people focused in the long term.
If only the world was this simple.
Engineer leaders tend to have more focus on long term and incremental building. They consider the engineering departments to be the heart of the company.
MBAs tend to focus more energy on sales and marketing, and they generally follow the “internalize profit centers, externalize cost centers” mantra. It’s not uncommon for engineering departments to get axed and externalized.
Semiconductor engineering, and specially computing products flourish i. The first scenario and suffer in the second.
To an MBA, selling off all the IP, selling it off, divesting of key assets and leasing them back, while owning a portion of the relationship at the end is success, treating sales as the most key part of the business process.
To an engineer, in-sourcing, building up strong engineering, R&D, recruiting strong engineering talent, and optimizing product for tradeoffs, treating the output of products itself as the most key part of the business process.
Lisa Su has done just that - if you create the best product based on the best engineering, the buyers will come.
In some markets, absolutely. In others not so much.
MBA's are plagued by short term thinking around quarterly earnings not building sustainable businesses
Lisa has absolutely got the power to cause catastrophic ruin to AMD through a couple of small decisions and there is nobody who can stop her.
The reality that she didn't do that is just more important than the fact that Papermaster or Keller are technical geniuses and work hard. There are 8 billion people in the world, we are not short on technical geniuses. There are something like 8,000 people out there who are natural born one-in-a-million geniuses at CPU design, Su "just" has to find a few 10s of them for AMD to get insanely good results. There is an eternal shortage of people who are both powerful, good decision makers and capable of recognising a 1:1,000,000 genius.
If there are 8,000 people who can design excellent CPUs, there are perhaps 1,000,000 people who can recognize such talent.
It is easier to recognize a great painting than to paint it. I'm surprised that HN so often lionizes those who organize the work of others.
"Organizing the work of others" is no small task, and people who can really do it well are few and far between.
That's not to take anything away from engineers, but it is to say that good management is something you largely only notice when it's missing, and you need good management to create the environment where good engineers can do their work.
It's an SF book, you have a small group trying to survive in an alien world at war. The guy who pulls them through is the canny merchant, who marshalls the skills of others and negotiates their salvation.
I think the narrator in the book was the engineer - and so was the author, Poul Anderson.
There's interesting interview about Keller's role in AMD, especially
>We had this really fun meeting, and it was one of the best experiences of my life. Suzanne called me up and said that people on the Zen team don't believe they can do it. I said, ‘great - I'll drive to the airport, I’m in California, and I'll see you there tomorrow morning, eight o'clock. Make sure you have a big room with lots of whiteboards’. It was like 30 angry people ready to tell me all the reasons why it wouldn't work. So I just wrote all of the reasons down on a whiteboard, and we spent two days solving them. It was wild because it started with me defending against the gang, but people started to jump in. I was like, whenever possible, when somebody would say ‘I know how we fix that’, I would give them the pen and they would get up on the board and explain it. It worked out really good. The thing was, the honesty of what they did, was great. Here are all the problems that we don't know how to solve, and so we're putting them on the table. They didn't give you 2 reasons but hold back 10 and say ‘you solve those two’. There was none of that kind of bullshit kind of stuff. They were serious people that had real problems, and they'd been through projects where people said they could solve these problems, and they couldn't. So they were probably calling me out, but like I’m just not a bullshitter. I’m not a bullshitter, but I told them how some we can do, some I don't know. But I remember, Mike Clark was there and he said we could solve all these problems. You know I walked out when our thing is pretty good, and people walked out of the room feeling okay, but two days later problems all pop back up. So you know, like how often do you have to go convince somebody? But that’s why they got through it. It wasn’t just me hectoring them from the sidelines, there were lots of people and lots of parts of the team that really said, they’re willing to really put some energy into this, which is great.
>Ian Cutress: Most of the audience questions are focused on your time at AMD, so let’s start there. You worked at AMD on Zen, and on the Skybridge platform - AMD is now gaining market share with the Zen product line, and you're off on to bigger and better things. But there has been a lot of confusion as to your exact role at AMD during that project. Some people believe you were integral in nailing down Zen’s design, then Zen 2 and Zen 3 high-level microarchitecture. Others believe that you put the people in place, signed off at high level, and then went to focus on the Arm version of Skybridge, K12. Can you give us any clarity as to your role there, how deep you went with Zen versus K12, or your involvement in things like Infinity Fabric?
>Jim Keller: Yeah, it was a complicated project, right? At AMD when I joined, they had Bulldozer and Jaguar, and they both had some charming features but they weren't successful in the market. The roadmaps weren't aggressive, they were falling behind Intel, and so that's not a good thing to do if you're already behind - you better be catching up, not falling behind. So I took the role, and I was president of the CPU team which I think when I joined was 500 people. Then over the next three years the SoC team, the Fabric team, and some IP teams joined my little gang. I think when I left, it was 2400 people I was told. So I was a VP with a staff. I had senior directors reporting to me, and the senior fellows, and my staff was 15 people. So I was hardly writing RTL!
>That said we did a whole bunch of things. I'm a computer architect, I’m not really a manager. I wanted the management role, which was the biggest management role I'd had at the time. Up to that point I'd been the VP of a start-up, but that was 50 people, and we all got along - this was a fairly different play for me. I knew that the technical changes we had to make would involve getting people aligned to it. I didn't want to be the architect on the side arguing with the VP about why somebody could or couldn’t do the job, or why this was the right or wrong decision. I spoke to Mark Papermaster, I told him my theory, and he said ‘okay, we'll give it a try’, and it worked out pretty good.
>With that I had direct authority as it were - but people don't really do what they're told to do, right? They do what they're inspired to do. So you have to lay out a plan, and part of it was finding out who were the right people to do these different things, and sometimes somebody is really good, but people get very invested in what they did last time, or they believe things can't be changed, and I would say my view was things were so bad that almost everything had to change. So I went in with that as a default. Does that make sense? Now, it wasn't that we didn't find a whole bunch of stuff that was good to use. But you had to prove that the old thing was good, as opposed to prove the new thing was good, so we changed that mindset.
>Architecturally, I had a pretty good idea what I wanted to build and why. I found people inside the company, such as Mike Clark, Leslie Barnes, Jay Fleischman, and others. There are quite a few really great people that once we describe what we wanted to do, they were like, ‘yeah, we want to do that’. Architecturally, I had some input. There was often decisions and analysis, and people have different opinions, so I was fairly hands-on doing that. But I wasn't doing block diagrams or writing RTL. We had multiple projects going on - there was Zen, there was the Arm cousin of that, the follow-on, and some new SoC methodology. But we did more than just CPU design - we did methodology design, IP refactoring, very large organizational changes. I was hands-on top to bottom with all that stuff, so it makes sense.
>IC: A few people consider you 'The Father of Zen', do you think you’d scribe to that position? Or should that go to somebody else?
>JK: Perhaps one of the uncles. There were a lot of really great people on Zen. There was a methodology team that was worldwide, the SoC team was partly in Austin and partly in India, the floating-point cache was done in Colorado, the core execution front end was in Austin, the Arm front end was in Sunnyvale, and we had good technical leaders. I was in daily communication for a while with Suzanne Plummer and Steve Hale, who kind of built the front end of the Zen core, and the Colorado team. It was really good people. Mike Clark's a great architect, so we had a lot of fun, and success. Success has a lot of authors - failure has one. So that was a success. Then some teams stepped up - we moved Excavator to the Boston team, where they took over finishing the design and the physical stuff, Harry Fair and his guys did a great job on that. So there were some fairly stressful organizational changes that we did, going through that. The team all came together, so I think there was a lot of camaraderie in it. So I won't claim to be the ‘father’ - I was brought in, you know, as the instigator and the chief nudge, but part architect part transformational leader. That was fun.
So, it's finally confirmed! Zen had an ARM front-end after all.
They cancelled it though as they saw : 1) the ARM server market wasn't happenning, at least not at the timeframe the product was to be ready for 2) the x86-64 could really be competitive with Intel
Then Intel had some issues and here we are.
When he joined Intel, he publicly implied it was where he belonged and his 'last job.'
Not long after, he left, for personal reasons. A lot of people speculated it was health related, for some reason. Then, he just goes elsewhere, making it clear he just didn't like Intel.
Part of me wonders if this had some hand in the CEO getting sacked. If your business is so toxic Keller won't touch it, that's a really bad sign.
The guy is so..normal/humble. Looks like someone who you'd get drunk with at some barbecue. Then he talks and just blows you away with how much he knows.
If you haven't already, highly suggest watching his Lex Fridman interview. I learned a lot from it, both about chips and Keller.
AMD had 2020 revenues of $9.76bln to Intel's $77.87bln. This eclipse is going to take awhile. I'm really excited for the results.
> AMD had 2020 revenues of $9.76bln to Intel's $77.87bln.
Ever heard of a solar eclipse? ;)
Intel was never 8 times bigger; AMD has actually always retained a respectable market share; ~20% market share is nothing to sneer at.
First, you need good material to work with. This is why it will be hard/impossible to fix WeWork. Sadly it may also make Intel hard/impossible to fix — lots of great stuff but deeply embedded in a matrix of mediocrity. same for HP (poor choices at the top didn’t help) and probably why google can’t be fixed — even more than Intel they have a lot of excellent resources and assets but they are embedded, not in mediocrity, but a fucked up management culture. And they haven’t had their near death experience yet.
Second: have enough domain knowledge to be able to identify and nurture the good stuff. One exception to this was Gerstner at IBM (at the time I derided him as “the cookie guy”). He famously visited most of IBM around the world and then his grand plan was: “actually things are great — let’s not make any changes”. In reality he shook up the management culture but let most the tech people keep teching. That righted the ship. Sadly he was not followed by successful CEOs, some of whom were otherwise admirable.
Third: be lucky the right way. Sometimes a company won’t catch a break (e.g. being a stagecoach maker today) but if there is a trend, or even better a phase change in the market you can take advantage of, take advantage of it. This is the “lucky generals” theory.
Lisa Su is a consummate techie but she uses her brilliance cleverly: she can match what’s going on inside the company with external needs, and channel the marketing and sales people to address it in the right way.
Sometimes you can’t pull it off. Hector Ruiz was a wizard at Motorola yet somehow he could pull it off at AMD. I couldn’t understand why.
OTOH look at someone like Gil Amelio. He only got one thing right at Apple, which was to fire himself and bring back Steve Jobs. But that was an important thing.