I am amazed -- stunned -- how many people here seem to think that Gelsinger was the right person for the job, but wronged by the people who pre-dated him (BK?!) or the CHIPS act (?!) or other conditions somehow out of his control.
Gelsinger was -- emphatically -- the wrong person for the job: someone who had been at Intel during its glory days and who obviously believed in his heart that he -- and he alone! -- could return the company to its past. That people fed into this messianic complex by viewing him as "the return of the engineer" was further problematic. To be clear: when Gelsinger arrived in 2021, the company was in deep crisis. It needed a leader who could restore it to technical leadership, but could do so by making some tough changes (namely, the immediate elimination of the dividend and a very significant reduction in head count). In contrast, what Gelsinger did was the worst of all paths: allowed for a dividend to be paid out for far (FAR!) too long and never got into into really cutting the middle management undergrowth. Worst of all, things that WERE innovative at Intel (e.g., Tofino) were sloppily killed, destroying the trust that Intel desperately needs if it is to survive.
No one should count Intel out (AMD's resurrection shows what's possible here!), but Intel under Gelsinger was an unmitigated disaster -- and a predictable one.
Interestingly, people were bullish about Gelsinger at VMware too. Many still talk about the glory days with him at the helm despite decisions that IMO significantly harmed the company
First, thanks for the love -- it's deeply appreciated! Our go-to-market is not an accident: we spent a ton of time (too much time?) looking at how every company had endeavored (and failed) in this space, and then considering a bunch of other options besides. Plugging into a "cheap Gigabyte" system wouldn't actually allow us to build what we've built, and we know this viscerally: before we had our system built, we had to have hardware to build our software on -- which was... a bunch of cheap Gigabyte systems. We had the special pain of relearning all of the reasons why we took the approach we've taken: these systems are a non-starter with respect to foundation.
You may very well not need the system that we have built, but lots of people do -- and the price point versus the alternatives (public cloud or on-prem commodity HW + pretty price SW) has proven to be pretty compelling. I don't know if we'll ever have a product that hits your price point (which sounds like... the cost of Gigabyte plus a few thousand bucks?), but at least the software is all open source!
Please forgive my tergiversation. I fully trust that you know your path and I know how annoying it is to be why-dont-they-just'd. As I said, I'm rooting for you.
There's two dictionary definitions of tergiversate. One is the one you quoted, the other is one of desertion. Both meanings of the word are pejorative in the sense that the word comes with a connotation of betrayal of a cause. What I wanted to express was an acknowledgement that I understood the feeling that you get when someone who's clearly a fan of your work nevertheless does not provide a clear endorsement. It's easy emotionally to dismiss people who "just don't get it". But when someone does get it but chooses to equivocate, that can feel like an emotional betrayal. So I was looking for a word that covered that with the right connotation. I originally used apostasy, but it didn't feel quite right, because I wasn't really renouncing, more failing to fully endorse, so tergiversation it was. Of course having to write an entire paragraph to explain your word choice kind of defeats the purpose of choosing a single well fitting word over just writing a sentence of simple words that explains what you mean. But hey, I write enough technical writing, documentation, reports, grants, etc. all day where clarity is paramount that I feel like I get to have a little vocabulary treat in my personal writing ;).
We are definitely very much building a business! We have the iconoclastic belief that you can build a business by having a terrific team building a great product that customers love. And we're getting there![0]
Obviously a very reductive question -- even if sharpened slightly to "most influential" book. I will reduce it even further: one of the few books that I have read twice (and the only one that has exerted different, profound influence on me on each read) is Tracy Kidder's "Soul of a New Machine." This is a book that every engineer should absolutely read, though not without an uncritical eye for Tom West and Data General. I wrote about my second read of "Soul" five years ago[0], and I know that there are folks who have read it on my recommendation -- and I don't think anyone has regretted it.
I finally read it recently (few months back or so) and I thoroughly enjoyed it. One of the many takeaways for me was how similar the SW world is to the HW one when it comes to actual human being behind engineering -- I guess I shouldn't be surprised but for some reason, the book reinforced that notion in my head. I'm sure I will read it again at some point.
I would really like to write about what you guys are doing, because it seems fascinating. But it feels to me like it's 95% podcasts, videos, and online chats, and I just do not have time for that. (And I'm about 9 timezones away or something.) I try to produce 2 articles a day, and to do that, I read tens of thousands of words of info a day... Speech just isn't fast enough.
The podcasts are more like 1% -- most of what we have done is via the written word; see our RFDs[0] or our docs[1]. (And at the risk of being too on brand, it is worth listening to our recent podcast episode on RFDs themselves.[2])
It's great to hear about someone else using AsciiDoc! We use it for all of our documentation at Oxide, so I had assumed that it was ubiquitous -- and it was only when we had a recent podcast episode about our RFDs[0] that I learned that it was really much less broadly used than I thought! Anyway, we're big fans of AsciiDoc; glad we're not (totally) alone!
I agree that startups need to be very careful with adding people -- and that most are not. For whatever it's worth, at Oxide we have long past the scale where everyone knows everything (currently ~75 employees); there is no doubt turbulence ahead as we grow with respect to employees, but I do think that some of our cultural idiosyncrasies (e.g. writing-intensive, recording every meeting)[0] have helped/will be helpful in this regard.
Thanks for the link! Basically all of "Demo Fridays, morning water-cooler, no-meet Wednesdays, recorded meetings, dog-pile debugging (aka CSPAN for debugging), RFDs (requests for discussion), no performance review process..." sound like music to my ears
This is a good piece in that there is absolutely truth to it -- but it's also a bit dangerously non-specific in that it potentially leaves founders with the notion that whatever they happen to think is tautologically correct. To supplement this piece, I would make three specific recommendations that I think tack into the same themes (namely: mistakes founders make -- including trusting the wrong people at the wrong times), but with quite a bit more detail.
First, Tim O'Reilly wrote a superlative piece in 2013, "How I Failed."[0] I cannot recommend this piece highly enough, and it had enormous impact on me as a founder. Its message is quite a bit more complicated than the Graham piece: there are times to stand your ground and resist conventional wisdom (HR in O'Reilly's piece), and there are times when expert practitioners of that conventional wisdom will save your bacon (the CFO in O'Reilly's piece). And the truth is more complicated still in that O'Reilly's specifics may or may not be the ones that a founder needs to apply to their own situation.
Second -- and I recommend this whenever anyone mentions Jobs -- is Randall Stross's "Steve Jobs and the NeXT Big Thing"[1], a history of NeXT written at Jobs' darkest hour. An extraordinary book that will leave you with a much more nuanced view of Jobs: not only in terms of his strengths (definitely those!) and his weaknesses (here in spades!) but especially the way that the NeXT experience surely informed Jobs's (much more successful) return to Apple. (It is a galling failure of the Issacson biography that he spends so little time on NeXT.) Selfishly, I would also recommend our Oxide and Friends discussion of the book.[2]
Third (and finally): a very common specific mistake that technical founders make is how they build out a go-to-market team. This isn't discussed nearly enough, and I was on a podcast episode of Software Misadventures ("Ditching the Rules to Build a Team that Lasts"[3]) with my own co-founder (who came up on the go-to-market side) in which he elaborates on this mistake -- and how founders can avoid it.
Unwarranted perspective from someone who is not a founder, but works with and has a lot of respect for them
I think the common thread between the two blogs is context and detail are important. I kind of think “Founder mode” is just doing your own diligence on your decisions rather than trusting heuristics or outside third parties. The “HR lawyers” or the “professional managers” are probably not nearly as tied to the company as the founder, and therefore unwilling to wade into the details and rely on such heuristics or “playbooks” for decision making or advice giving.
Tim does raise a salient point though in that finance functions are often overlooked or under invested, and siloed division. The whole company probably does not need to know the daily cash balance of the company, but team members should maybe think a bit more carefully about relative rates of return on their invested time or money, and “finance” is a good framework for doing just that. The best CFOs (or people more generally) look for that context (and help others do so too), so they can understand intuitively the impacts of potential decisions. Meanwhile, the professional managers run away from the detail and prefer to rely on playbooks and heuristics like the Conjoined Triangles of Success.
I don’t think it always has to be that way though, you just need people to care enough to wade into the depths of detail and care as if they were a founder.
I find myself thinking more and more that Bryan Cantrill, despite him highly disliking Elon Musk, seems to agree with him regularly on many things including things such a this.
Gelsinger was -- emphatically -- the wrong person for the job: someone who had been at Intel during its glory days and who obviously believed in his heart that he -- and he alone! -- could return the company to its past. That people fed into this messianic complex by viewing him as "the return of the engineer" was further problematic. To be clear: when Gelsinger arrived in 2021, the company was in deep crisis. It needed a leader who could restore it to technical leadership, but could do so by making some tough changes (namely, the immediate elimination of the dividend and a very significant reduction in head count). In contrast, what Gelsinger did was the worst of all paths: allowed for a dividend to be paid out for far (FAR!) too long and never got into into really cutting the middle management undergrowth. Worst of all, things that WERE innovative at Intel (e.g., Tofino) were sloppily killed, destroying the trust that Intel desperately needs if it is to survive.
No one should count Intel out (AMD's resurrection shows what's possible here!), but Intel under Gelsinger was an unmitigated disaster -- and a predictable one.
reply