Adam Bosworth

Note: Podcasts on Leading Smart are produced for the ear and designed to be heard. If you are able, I strongly encourage you to listen to the audio, which includes emotion and emphasis that's not on the page. While the text is carefully transcribed, it may contain errors. Please check the corresponding audio before quoting in print.

CW: Adam Bosworth has spent a lifetime chasing a singular vision. Few people are fortunate enough to find their passion early, fewer still are lucky enough to pursue it their entire life. In chasing his vision, Adam worked for some of the seminal companies of the tech world, Microsoft, Google, Salesforce, Amazon. He has birthed and led some of the most famous software in the world. Borland’s Quattro, Microsoft’s Access, Google’s entire suite of Gmail, Calendar sheets, and more. Recently, he created Amazon’s Honeycode, a new easier way for anyone to create software. All of these products, most of his working life, in fact, stem from a singular focus. as Adam puts it:

AB: you know, Alan Kay’s dictum, in some sense, is the root of everything I believe, which was the simple things should be simple and hard things should be possible. That became the vision that I chased. Like everyone has something that then was a formative moment, once I realized that was possible. I spent most of the next 40 years trying to deliver that in the context of the technology of the time.

CW: A few weeks ago, I had a chance to talk to Adam about how he got started on this vision, and how he built and led teams to create these amazing products. One of the highlights of our discussion was where he explored at length, the very different cultures of each of the companies, and the effect that culture had on the products, the people and him.

It was such a fascinating conversation that try as I might, I couldn’t find a place to split it up. So I presented here as one longer than normal episode. And that’s what this is all about.


This is Leading Smart, the show about managing in the brainpower age. It’s a field guide to the joys and challenges of leading and working in the modern workplace.

I’m Chris Williams, your guide to the stories and ideas that I hope will inspire you to be a better leader in the world of knowledge work.

This time we talk with a pure force of nature in the tech world. This is Episode 226, my conversation with Adam Bosworth.


CW: Adam Bosworth was a self described math wonk. But when he got to Harvard, he soon realized that pure math was too impractical for him. A required course in computers got him interested in the field of computer science. But he says he was too interested in skiing and girls to take much of anything seriously, and he ended up with a degree in history. I asked him how he ended up choosing software,

AB: Mostly accidentally, and I had expensive girlfriends, I’ve been doing construction, it turned out it was a lot easier. It was more air conditioned, it was sedentary and a paid better to program than to do sheet rocking and cement work and roofing. So I switched from construction to computer to sort of join the air I consulted for the astronomy lab or whatever. And then during the summers for these people down in New Jersey.

And then when I came out of college was a mini recession 76. And the same people had done a startup and they asked me to come join them and know they were paying me and no one else seemed to be willing to pay me and I had no desire to go to grad school. And so I went off to be classic systems programmer, at least that was the thinking for about a year.

But you know, I don’t know that I would have stayed in software. It was really, it was more way to pay the bills. And then in 77, I went to work at Citibank. And there was this guy out of MIT who had just taken over half of the bank, a guy called John Reed. He was only about 30 something very bright, very driven. He was spending a fortune on time sharing. And you know, it’s there’s a real advantage to being 23, you’re fearless. You do not know that anything is impossible. I used to sit next to Anders Hejlsberg when he was reading Turbo Pascal, version two or three in Copenhagen and tell him that the only reason he was able to do it was because he was fearless. He didn’t know it couldn’t be done. And he was about that age.

So I went into my boss’s office, and I said, Give me a million dollars. And I’ll shut down your timing time service systems and give you much better data. So he grilled me for a bit and he roared this huge laugh and said, Fine, you’ve got a year, get the system up and running. And I ended up building the biggest Vax data center in the East Coast. But delivering, you know, we replaced the MIS systems, all of those streaming companies. I think my bias figured out at one point we during the company 300 million more dollars than they would have earned that year.

CW: Wow.

AB: By then I’d figured out what I wanted to do, you know, what I wanted to do was not write the code. Like I like writing code, because but it feels to me like playing solitaire, it doesn’t feel like an occupation, I should be doing full time. Um, maybe as a guilty pleasure.

What I wanted to do is I wanted to design and write products. But I wanted to make sure the products made sense for the customer. So I want to understand both what the engineering enabled and what the customer wanted. And I ended up effectively as a GM of a group doing this for Citibank. And I really never looked back to be honest after that,

CW: At Citibank, Adam was tasked with converting 300 companies to the new system. But he really didn’t want to do all the work, it took for each one of the 300 companies, days of work for each one.

AB: And I realized I need I don’t want to convert by hand these 300 companies. So then I go on a road trip, right. And I just talked to the key, you know, financial employees of these companies. And as I talked to them, it becomes clear to me, I can build something they can use. They don’t have to be programmers. Right. And this is this eureka moment for me, where I realized that I can open up the world to large numbers of people, they were using spreadsheets, there was Visicalc by then, large numbers of people, you know, two orders of magnitude more than programmers who are bright, and are good tools users. And actually think more abstractly than the average Applications Engineer, but are not programmers, and that was enormously empowering to me. And really exciting.

And I built this system that today, we would call OLAP. And as I said, By the time I was 25, it replaced almost every IBM System. In Citibank retail, Reed got promoted to be the rent to run the whole bank, probably on the strength of this stuff. Unfortunately, for me, that meant that I got promoted to go be a banker, which I had zero interest in. So I decamped to go to the west coast into a software startup.

CW: Had you had any kind of leadership experience? How did you know you’d be good at at leading people to write software?

AB: So that’s a good question. Okay, so I left Harvard and I go to work for this odd team at this company that I’ve worked for over the summers and now started, and they dumped me in this group that was in trouble. This group of about 20 engineers, and they were already in essentially these custom applications. But all of the same ilk, for a bunch of people are doing publishing. So they would could do cost estimation, what it would take to do publishing jobs.

And it was the closest thing to a PC that they had, there was at the time, it was this thing called the Olivetti, P652. The thing was, it was taking most of them eight to 10 weeks to write this stuff. And then they were losing money on every deal, because they couldn’t bill that much out.

And I came in and within about a week or two, I was taking me about a week. Then I was taking about three days and then two days, right. And so looked around me to see what was going on. And there were a variety of bad practices going on. And at that moment, the head of that team, who was a lifelong friend of mine, was a Summa Cum Laude mathematician from Columbia, brilliant guy, but temperamental, sort of had a mental breakdown, because his team was failing. They weren’t producing, they weren’t working well. There was huge stress on him. And he announced that he was getting his PhD in pure math from Columbia, which would have made all the sense in the world, except for the fact that wasn’t true. And he was just he couldn’t deal with it anymore.

And the VP of Engineering and the CEO, they asked him who should take over and he named me, but I’ve been there about three months at that point. And they called me up, but they know me, right? Because I’ve worked with these guys over the summers. And they called me in and said, “will you run this team?” And at that point, I had never managed anybody in the sense that you’re asking. I had led teams, but I had not managed them. And so I sort of thought about and I sized up the situation. And I said, Yeah, but I have to be able to fire to people right now. And they said, Who?, what was their sons? It was the son of the VP and the son of the head of engineering. And they said, why I said, cuz they’re sending a terrible example to everyone else. They’re doing nitric oxide in the stairs after lunch, their code is crap. No, they say that. And then everyone asked, why should they work, these guys don’t have to work. But if I fire them, and they, your kids, everyone will know. They have to work or else. So, you know, then you’ve empowered me and I can fix this.

So they did. They fired their kids. I came in and told the team, I was running them, and I fired their kids, the kids. And this stuff had to stop. And we were going to be writing this stuff. Not that fun. But to get these things done very quickly.

It was it was a tough love management strategy. It was not that I was Mr. Touchy Feely. And this probably doesn’t surprise you, since you knew me and Microsoft, it was set the bar high and make it or else you know, it worked within the company very rapidly promoted me until I left to go to Citibank. And the team performed, it went from losing a lot of money to making money.

So at that point, I was pretty confident I can manage people. But then when I got to Citibank, I hired a couple of kids out of Columbia University. And they were right out, right, they were computer science students, right, or mathematicians right out of Columbia.

You know, from the very beginning, the culture was learn from each other. If you’re really confused, come find Adam and ask him, but don’t, don’t sit there and, and stew, right. And, you know, that was a skill, I sort of picked up from the first job, and then I honed on the second job.

And then I hired people, I think I had this discussion with you once, you know, I said, you basically have to hire people who are pragmatic, you know, they’re not pragmatic, they’re going to go off in the weeds and try and do something very hard, just because it’s fun and intellectual. And that’s very nice for them. But it doesn’t help you get done, what you want to get done. You have to hire people are smart and hard working. And that’s the other thing, you have to hire people who are focused and smart, if they’re not focused, they’ll be all over the map. If they’re not smart, you know, it’s not you can’t cure stupid.

So um, so you know, we hired pretty carefully. People who are very pragmatic, very hardworking, very focused, and very good at working with others, they’re, they’re, you know, they’re, they did not have an attitude or an ego. And I learned that partly from some people that I’d hired and then had to kick out in that first job. People came in fancy degrees, sort of, tried to lord it over everyone else, or over-design and, you know, ended up ended up firing them.

CW: But you’re a, you’re a guy with a lot of big ideas. So was it sort of your job to be the dreamer in the crew is that I mean, somebody’s got to set the bar out there. And,

AB: You know, my real job has always been talk to the engineers a lot, and write enough code or be in the code enough to understand what can be done. I call that the physics. What’s physically possible, then spend a lot of time with the customers understanding what they really want, and then I call that the psychology. And then figure out what’s the best way to deliver what they want, that is the easiest way for that customer. That actually is physically possible.

And, you know, so his vision, but it wasn’t just product vision, right? It was, I found that I really, I’ve never understood how you can build a great product without having one on one leg in the engineering on one leg in the customer. And I still don’t.

CW: And and many companies or many organizations try to solve that with groups of people, right? So they have people who contact the customers, and then people who are down in the engineering and but then there’s a translation problem. So what you’re suggesting is that that probably needs to be at least one person or somebody who’s seeing the whole picture.

AB: I think it’s a fiasco. I mean, here’s a concrete example. I mean, there’s many concrete examples, like my whole career has been spent cleaning up concrete examples, but one of them that you’re familiar with, is I was recruited to Microsoft, by Steve Ballmer and Bill, ostensibly to build version two of something called Omega, which was a database product they’ve been working on for three years spent maybe $20 million on was supposed to start shipping in months, but it was they were hearing that they were very uneasy, and the brought me in really to see if this is thing viable and if it’s not viable, what do we do?

So I come in and I look at the product, unfortunately, three months into very careful analysis. Because there were a lot of very good engineers on this team. Like I said, they spent 20 million on it, the company was assuming it was going to go out. You know, I conclude it was not viable, that the product would be a disaster, right?

The interesting thing was, I took the identical engineers and built Access. I even took some of the same product managers and built Access. What had gone wrong was they had had a bunch of Harvard MBAs go out and talk to customers about requirements, then they’d written these sort of Harvard MBA-ish requirements docs, where it’s appeared that they were being paid by the word, and paid extra if the words were, you know, obscure. Um, this had been handed over the wall to a bunch of extremely bright, anal retentive product managers, out of Harvard and Yale and Princeton, who then produced an extraordinarily elaborate and thick spec, which was pointed to with pride by everyone about that thick, which was handed over the wall to the engineers. I have never ever seen a product worked out that way. I do not believe I ever will see a product worked out that way. And God knows this was not one of them.

And you know what, what I did frantically once I ended up in charge was drag the engineers to developers conferences and make them eat lunch with the developers and talk to them and write up write ups of what they learned. And then separately is you and I discussed to hire Dave Risher to write up for them when he was learning from the customers and bring customers in? You know, I think I figured out very early on, that not understanding the customer was fatal and not understanding the physics was fatal. I think that’s largely speaking still true today.

CW: One of the things you just said, though, was that, like, you need to hire a team full of sort of very practical people. And I can get that with respect to the customers and everything. But in order to sort of hit a mark out in the future, doesn’t somebody have to be the dreamer? Doesn’t somebody have to be the the visionary? Is there?

AB: I mean, yes, but you know, I think there’s too much focus on dreamer. Um, I mean, I’ve built a lot of things that ultimately, I was lucky enough to see do well, that we’re rethinking how to do something. But, you know, the intellectual effort to figure out what was new and different, was a pretty small part of the effort. It’s the famous Einstein. Was it Einstein? Whoever it was who said, you know, genius is 1% inspiration. 99% perspiration.

Mean, like in Access? I mean, here’s how it came up, you know, I, I had worked with this head of engineering, we started to agree on what to do. But you know, we had not written anything down really. And then suddenly, I get this mail from Bill who just read my 60 page memo on what was wrong, saying, I’m gonna have a review tomorrow on Omega to see what we should do be there and be prepared to say what to do instead.

So the by now it’s five in the evening, and in Redmond in the winter, it’s dark. So I go to find the Bill Bader later called Bill Marklin, And he says, Well, what do you think we should do? And I sketched up on the whiteboard, he says, great, write that up and bring it in. Which was the antithesis of how my boss at the time would you know spend weeks perfect perfecting the PowerPoints for Bill, but that’s not…

So I go home at that point in time, I had a six year old and a one year old, two year old, whatever, and so all I had was construction paper in the house. So I draw up pretty much what is Access as of when we launched it, except the Query Tool was wrong. And I, you know, write it down on construction paper and come in in the morning and Xerox it. And to my boss’s horror when he comes and sees what I’m doing. And then when Bill asks, What do you think we should do? You know, hand him the construction paper, he gets the color version, everyone else gets the black and white.

And that was the genius part. Right? That was the vision. The rest of it was just hard work right there. So it was like a zillion hard questions. They you don’t think of at that point. And in fact, you shouldn’t even try to think of at that point. Because you don’t know until you try and use a product, you have no clue, until you try and at least desk check it you have no clue. You can do all the thinking in the world. But you start to get increasingly asymptotic and then even diminishing returns from it. If you can’t actually start to play with the thing, and then understand that you’re not done when you play with it. You’re just you’re working out a zillion details. And it’s the details that make the difference. It’s the usability that makes the difference. It’s how well you’ve actually tried to use the product to do things and then come back and said, Okay, what do we do to make this easier to use that makes a difference.

And that’s all hard work. It’s not genius. It does not require someone with great insight. It requires someone who actually cares passionately about the customer, working equally closely with an engineer who cares passionately about the customer, but equally passionate about not incurring tech debt when they can avoid it. You know, that’s most of the work. It’s like that point what really matters is are you thoughtful? Are you patient? Are you prepared to admit that you’re wrong? When you are wrong? Do you stop and go back to the customer a few times to make sure that your new idea actually works better?

So I don’t I mean, yes, to do what I do is something you have to stop first and ask, what can I do differently, that will make it a lot easier. But that actually is never the hard part. Like, I think this is where being dyslexic is useful. That’s always pretty obvious. What’s hard, is the details.

You know, I just, I firmly believe that if you have someone with no vision, you know, they have no idea where they want to go, they’re gonna make a mess. Without a doubt. In fact, the better they are, in some sense, the worse a it will be.

There has to be, yes, there has to be somebody in the team with the clue of where are you trying to go, and an opinion. And it has to be opinionated, you have to make bets. Because whenever you’re trying to go somewhere, you’re making some bets.

That just means that person can’t be a bureaucrat. That’s all it means. They don’t have to be visionary they have, they can’t be a bureaucrat.

Whenever I build a product, you know, I have a hard time shipping the first product, it’s always well known. And it’s because there’s so less much less there than I wanted. And the actual vision that I have first, versus when it gets there’s always five years. Right, it takes five years to actually get to where I want it to go. But teams can’t do everything at once. Right teams have to come along one step at a time. But most of the hard work is still done by the team. And that hard work is okay. How do we actually make sure this is usable?

CW: You just said something that was going to be one of my next questions. There’s the some old line about the last 20% of the product takes 80% of the time, right? Do you have trouble finishing version one or version two? I mean, are you it does that get you frustrated and impatient. And…

AB: It does, I get exasperated, Brad once famously called me a starter. And what happens is, you know, I work really hard for two years, usually getting this thing to a certain point. And at that point is in the end game, if you know what I mean. At this point, really, what you’re doing is you’re fixing bugs, and tuning performance, you know, you’re not actually doing anything new.

And you you know, it feels like it should be 10% of the time, right, because you’ve done all the heavy lifting by now. And then it isn’t 10% of the time, and then crucifyingly, if you’re customer obsessed, and I am customer obsessed, crucifyingly the team starts to pick more and more bugs not to fix that you know, really will hurt the customer.

Even worse, that’s what I call the broken branch problem. The team, you know, every feature you give a customer should either be really good, or it shouldn’t be there. Giving customers crappy features as a negative, it’s better not to give them anything and give them something that’s ugly and bad. And not infrequently, a bureaucratic mentality will take over for those last a year or nine months or whatever it is. And they will start cutting features and not asking themselves I mean, but about, you know, cutting bug fixes, and not asking themselves, what am I doing to the feature. And sometimes the feature is now so undermined that you’d be better off just walking away from the whole thing and doing it later. Because otherwise, you’re just gonna lead to a bad user experience. And then something then you have to come in and be the bad guy. I’ve had to do this more than once in my career. And so you can’t do this anymore, you have to cut this feature, because it’s not good enough. And this can’t go out like this.

So yeah, I get very frustrated. And sometimes I just move on, it’s true. And the other thing is, I don’t add much value at that point. And I don’t like being in a place where I don’t add much value. You know, I said this actually, in my LinkedIn, I’m not a good operational leader. If I’m sitting there reviewing endless numbers of burndown lists, my mind is already thinking about the next feature, or how to build an app with the product, it’s not thinking about the burndown lists. So the team gets to a point where all it can do is work for burndown lists. You know, having me around at that point generally pisses everyone off, because I’m pissy. And so because I can’t believe we’re not fixing these bugs or I can’t believe we can get the performance benchmarks we need or whatever it is. And because you know, I know perfectly well, we could. We’re just not going to get there in this release. So yeah, I think that’s a fair comment.

CW: Almost every other word in this conversation so far has been the word customer. So is some of it that you’re also disappointed that you can’t get it to the customer fast enough?

AB: No, no, I don’t worry about that as much as everyone else does, I know the whole valley thinks it you don’t have everything. You know, in fact, I think the valley is wrong about this, this is pervasive wisdom in the valley, that you should release this thing to the customer sort of when it’s still almost embryonic, let the customer act as if you will be, you know, the womb that then just states it from, you know, blastula to a fully formed fetus, you know, fetus and out the door. I mean, that’s nonsense.

And once in a while customers react that way, Slack might be a good example. But most of the time, if you’re gonna deliver a product to the customer, particularly if you’re competing against genre. And by the way, it’s a hell of a lot easier to build the product by competing against a genre than invent a new category. So if you’re trying to reinvent or compete against genre, your product has a lot of things it has to do. If it doesn’t do them, the customers gonna go, why would I use this product is crippled? Well, you know, you’re trying to play catch up. Now speaking, as a guy of those spreadsheets, when there were spreadsheets and databases, when there were databases and browsers, when there were browsers, you know, you’re not going to get there by building 10 features, when the customer has 1000, enough to build 1000, the customer is not going to use all 1000, you’ve got to do some pretty heavy lifting. And that means you’re never going to get this thing done in three or six months or whatever.

So no, I’m not in a rush. It’s more that I feel terrible if we do a bad job for the customer. I feel terrible shipping something that you know, is not high quality for the customer, I feel terrible champion saying just as bad user design for the customer.

Like the precipitating thing that caused me to leave AWS was the product management team wanted to make a decision, they actually made the decision for the UI, that was a really bad decision. And I said, I’m sorry, you can’t do that. It’s a really bad way to solve the problem. There are 18 ways that are better to solve the problem. They said, well, we’ve made it, we’re going to go ahead and I saw you can. And you know, we ended up going to my boss because and I’ve asked her well, you know, what’s the vote. And as soon as I heard that I knew, you know, like, I was gone. Because, you know, this wasn’t the kind of thing you voted on this was this product actually clear and intuitive or not. And the team had made a choice that really reduced clarity and intuition, in terms of what the product could do, that the other guys couldn’t do.

And the reason they done that was they were sort of trying to copy a model that was simpler, but was now trying to do something harder. And you can’t do that. When you have it, when you make something harder, you have to change the model to make it easier to understand the hard thing, you can try and make the simple thing just work.

That I hate that I mean, I hate it when in the interest of time the team makes a decision actually makes a product card are clumsy to use. And at the same time, it’s hard to control the team at that point, because they are very focused on getting to the ship date, period. And when you’re very focused in in in the ship date period, you’re not focused on the customer at all.

CW: It makes it very hard. Particularly with a new product, once you’ve established a paradigm or a view or a perspective, it’s very hard to go back later and sort of change the entire paradigm for the customer as well.

AB: I don’t think so. I actually think that products that don’t grow stagnate. I mean, you know, the Amazon UI now has nothing to do with the old Amazon UI. There were multiple fundamental changes to the paradigm.

It’s tricky. I mean, Facebook does it every time they do it. There’s a zillion people who scream online about how it’s the worst thing ever. And then, you know, a month later you don’t hear anything. Right.

And so I think this is overstated. I think products that are good evolve, and grow, you know, in ways you would never expect. I think as I think as your understanding evolves, or as the physics evolves, the paradigm in the product will frequently evolve and should evolve. And the trick is it should not evolve in a way that’s complicated, and should still have a clear and crisp, user model.


CW: Thinking about how you’re building products and building teams, at what point does size and scale become a problem. I mean, it sounds to me like, like you want to manage a group of people that’s sort of small enough to get your hands on, but that limits the size and scope of the thing you’re working on, doesn’t it?

AB: It absolutely does. depends a lot on who your lieutenants are. Like one of the reasons I was able to run Google Suite is I had some great lieutenants who I had a lot of trust in. Then there was a guy called Alan Warren there. A guy called […], there was just some very, very good people who I could trust around whole chunks of the idea. And check in with me routinely. But you know, I could trust them to check when they needed to or not when they didn’t.

Even when I was running IE4 and Trident. You know, Holly Marklin was a great lieutenant. And so I could trust Holly to run a long way with Christian Fortini and so on. But yeah, I mean, my experience is that I am limited somewhere around about 100 to 150, engineers, uh people, when it gets over that size. If I don’t have the right lieutenants, I start to fail. Because I no longer have good mechanisms to make sure that everyone in the team understands what we’re doing and why we’re doing it. You know, what not to do, like, what are the right design principles? And what are the right? And what is the user vision?

If… it’s easy at 60, or 50, it’s hard at 100, it starts to be borderline impossible for me around 150. Unless there’s the right lieutenants. Another great great lieutenant I had when I was at BEA Systems was Byron Sebastian, I could just give Byron 150 people and say, here, go please do this. And you could go do it. And though, you know, I could go focus on Workshop. You know, Portal and Workshop Integration, while Byron focused on Workshop for web Services, because I knew he would get it all right. And Byron was not technical. By the way, he’s just a great leader and great manager, and had the vision and checked in a lot. We’re still best friends.

And so the answer is yes, with that caveat, give me the right. People, you know, to work with, and then I can scale up one level, but but unfortunately, not that good at picking up.

CW: I was just going to ask you, so how do you? How do you pick lieutenants? Or do you just take what you’ve been given and when you happen to get a good one you excel? And?

AB: No, that’s not how I picked them at all. So actually, a good examples are Byron and Alan Warren. In both cases, as soon as I spoke to them, I knew these were people I badly needed and wanted. And then I pursued them relentlessly until I got them.

I’m looking for people who both have their own vision are clearly very smart, are clearly much better people managers than I am, but are clearly very happy to collaborate. They’re not like, okay, it’s mine. Go away. I’m looking for people who are genuinely intellectually curious and customer, and passionate about the customer. And, conversely, who are not afraid to tell me I’m wrong. Holly Marklin is a great example, that she come in the office, shut the door and read me the writer. I back off.

So when those people show up, I know them right away. And I if at all possible, I hire them. There’s one right now that I’m trying to hire into a startup I advise. So I bought into Google was amazing. And just like this. So I know by and large, I actually know them when I see them. The problem is sometimes you can’t find them. And if you can’t find them, and you need to build something, I mean that.. I find on average, it takes a year to find one of these people have steady and constant recruiting.

CW: And where do you go look? Is it mostly network?

AB: Some of its really good recruiters. Some of its network I have a pretty good network, quite a lot of it is network. Some of it is you know, I’m kind of promiscuous when it comes to recruiting, if anyone interesting whose resume, just looks to me like the right feel or get on the phone to talk to them these days on zoom. And then if it goes, Well, I’ll start to try and meet them, you know, talk to them more and more. And I’ll push them and see, you know, how they react to that.

But I see I used to figure when I was at Microsoft, you know, I was running 100 and some people and my estimate was I spent 30% of my time on recruiting… maybe 25 but a lot, right. And a lot of that was on a plane, going to find them because they didn’t want to come up. Same thing at Google. Although Google had this counter counter recruiting thing that was very hard to break. If you recruit a Google, you can’t recruit for yourself.

CW: Okay.

AB: And it turns out that really cuts the incentive.

CW: Yeah.

AB: In general, I think your comment is correct. Like I manage through personal relationships with people. I manage by making sure they actually share a common understanding and vision of what we need to do. And that they’re, they’re constantly cognitively, you know, you’re aware of both statistics and the cut user model. And if they can’t do that, they don’t do well for me.

CW: It sounds like you thrive on pushback. That you really like people who are willing to push back at you.

AB: I think it’s generally agreed that you should not work for me if you cannot push back. I mean, these days, I’m wiser and more tolerant. And so I tend to tell people up front repeatedly in the meeting pushback if you don’t agree, right, particularly now that I’m teaching and advising, and I’m also teaching a company in Mexico City, and they’re a little less willing to be aggressive. So you have to ask, you have to pull more to get them to push back. Though once they learn to do it, they’re fine.

Look, every thing I ever built was right, in large part because someone argued with me and turned out to be right. And so if you don’t have people arguing with you, you’re not going to get it right. This is what meant. Vision only takes you so far vision is like, you figured out you want to get there. And you’re now pointing there. The problem is, is 18 different detours and paths, some twists along the road. And none of those are vision, those are all reality checks. And every reality check requires someone to come in and say, here’s a reality check, what do we do about it? And that’s pushback.

CW: But there’s some big larger vision that you’re all sort of signed up for, you just don’t know the exact path you’re gonna take to get there. Right.

AB: Visions are so easy in some, I mean, think about the vision behind Tesla, the vision behind Tesla’s you know, drives like a Porsche, but you feel good about it. You know, I mean, it’s a really easy vision, you know, you have this car, that’s insanely fun to drive. And yet doesn’t pollute, or at least, minimally right as little as possible. Um, as a vision, it’s amazing, right? And, and you can see it like, Elon embodied that vision into the look and feel of that car. Right from start to finish. Convinced. Same way Steve Jobs did the iPhone. I’m not saying Elon’s a perfect person, I’m just saying he had, you know, clearly had a vision. And he drove it.

Um, after that, it’s a zillion details about what can you actually do? how big should the computer be? What things should still be on the steering wheel? You know, how minimalist should the seat controls be? The vision was simple, right? The vision was this idea that this is a car that you don’t need gas anymore. And so you can now have a lovely car that everyone would want. But that doesn’t need gas. And everyone who to an entrepreneur you’re crazy, like the real, the reality is the opposite. You wake up every day, and there’s 250 miles in your tank, and you don’t have to do anything. You didn’t have to go to the gas station. Very, very rarely Are you wandering more than 250 miles a day when you do their superchargers. But which was the other part of the vision? And that was probably a reality check somewhat early on. Right? That was the thing they figured out they actually had to do?

I mean, yes, you have to have a common vision after that, and how do we get there? Right, and you can sketch some things kind of like a sketch for Bill and Access. But there are going to be a zillion reality checks, big ones, a little ones all the way along, and how well your people think about those and how clever they are, and how collaborative they are with each other. Like, if your product managers are not talking to their customers, you’re dead. If your engineers are not actually talking to principal engineers, you’re dead. And if your engineers and your product managers are not talking to each other, you’re dead. No matter how good a manager you are, well, actually, I would argue you clean out a good manager if you don’t make that happen. Because that is the minimum bar.

CW: Yeah, exactly.

AB: And it is amazing. How often, all four of those things are true. Or not. I mean, as if they none of them are talking to each other.

CW: Yeah, right.

AB: So, you know, I don’t view my job as being I don’t, I don’t measure myself by “Boy, you’re not a real man if you can’t manage 1000 people.” I measure myself by did you build something that was really great, and lived up to the vision?

And you know, very rarely were the original great things built anything like 1000 people even back you know, was a couple hundred people? Um, you know, I’m particularly Andy Hertzfeld, and people like that. No, it’s not an enormous team. It was run by brutal but but brilliant guy.

Your teams will become big if the things you build win. But that’s almost unfortunate. So yeah, I agree. Like the way I manage things, is not suitable to managing large teams.

CW: You said something that was interesting. A minute ago, you said, I like to have people who work for me, who are good at managing people because I’m not good at managing people.

AB: I didn’t actually say that, but that was absolutely implicit in what I said. I wanted to be good at managing people, the ellipsis was because I’m not good, but it is true.

CW: And why are you not good? You clearly have tons of empathy, right? You have customer empathy, you have engineer empathy, it would seem to me that you’d be a wonderful manager.

AB: Wonderful managers spend a lot of their time and get a lot of their satisfaction out of knowing that they are teaching and growing their people to be better at what they do. That’s what they do, right, they spend a lot of time thinking about it, they spend a lot of energy in it, they’ll have a lot of time with one on ones with their people, to coach them and advise them and listen to their complaints.

Wonderful managers, read people well, they can see when they talk to someone what they’re thinking, even though the person might be saying that direct opposite. I am good at none of those things. I have empathy. And you know, I can sense when someone is unhappy.

But almost all of my focus and thought goes into how do I make this product better for the customer? And how do we use the engineering better to get there? And how could the UX be better? And what feature you know, what could we change to make some sort of enable some scenarios otherwise not enabled? While not breaking the user model?

It’s it’s physically hard for me to take away from that thought in significant chunks, and delivered it instead to how do I better coach my people?

I’m also, you know, I’m pretty intuitive. It’s very hard when you’re intuitive to explain to someone why you don’t agree with what they’re doing. When your basic thing is, this just does not feel right.

CW: When you have somebody who isn’t cutting it, this is sort of along this empathy lines, are you inclined to try and help them figure it out? Or are you just a cut your losses and move on kind of guy?

AB: It depends. If they’re not cutting it, because they’re not doing the right thing operationally, I will try and help them.

If they’re not cutting it, because there’s some clear course of action they can take, that will clearly remediate it, for example, go and build some apps using this thing, and you will understand what you don’t currently understand. I will help them I will even direct them, you know, take a break, build some apps using this thing. So you actually get your head around, what do you have to do?

If it’s clear that they they cannot be pragmatic, or conversely, that they cannot understand the actual mentality of the customer. And they are using process and checkmarks as a way to work around that as opposed to understanding or if it’s clear, that they should have taken, they took on responsibility for something without having a clue that what it would mean for them to do it. And now you’re in a hell of a mess, because, you know, you committed to something and they in no way shape or form actually had engineered to meet that goal, then I will do my very best to fire them very hard to do these days. But, um, because I think they’re dangerous. You know, I think such people will never be great, they will never do a good job, they will never improve anything, because they’re irresponsible. Or they’re just dangerous, because they’re never going to have the ability to design something, right.

So it really depends, I mean, honestly, I end up sizing them up as flawed, but insightful, and smart, in which case I will try to remediate or, you know, fluid in the sense that they simply do not, you know, that they manage without understanding. They manage without diving deep. They managed without thinking through what they have to do, and really thinking it through. That that kind of person I don’t want around me.

The people who I want around me are very, very good. And actually doing the work and the research and the math to make sure that whatever they sign up to do they can do. I do it myself, you know, I’ll go back and measure, you know, the speed of certain things.

When I first showed up at Microsoft building Access, I told the team, I wanted a quarter of a second to repaint the grid when you page down. The team all told me this was impossible that I had gone over and I talked to the windows team and I talked to one a guy called David who was one of the original windows writers and he’d actually mocked up from me what it would take to do this, and we’ve done the math, and even with the machines of that time, which were 386 system, we had figured out it was theoretically possible, there wasn’t a whole lot of wiggle room, but it was possible. Right. And we knew that by the time we shipped, it would absolutely be possible Moore’s law being what it is.

And I brought him back and said, Look, it’s possible, you can do this. But that’s called doing the math, right? You know, we actually sat there, and we measured the speed of the windows API’s, and the bitblting API’s, all the things necessary to do what I just said. And you had to cheat a little bit like you didn’t repaint the grid, you were painted the contents of the grid.

You know, so that’s math, that’s, you’ve got to do that you have to. So if I get employees who don’t do that, because they don’t view that as their job, I’m too high level, you know, it’s, it’s beneath me, or they don’t have people who do it for them and turn and they double check it and count and review that this actually will work. You know, those people don’t try and salvage.

CW: That, that sounds a lot like one of the sort of the tenants that that Amazon talks about all the time, the willingness to do the deep dive so so you are certainly not above, diving down in on somebody’s work and saying, Hey, wait a minute, come on, this is crappy work, and you need to fix this?

AB: I had to actually work a little bit the opposite when I got to Amazon. So normally, I will spend a lot of time with every engineering team, asking dumb questions until I understand in my head, how it works. And why I believe it’ll be fast enough, or handle the use cases. That’s actually another third of my time normally.

At Amazon, I was a VP. And I hadn’t really internalized how senior this was an Amazon. And when I came down to this, the engineering team, they were like, Oh, my God, this, you know, the VPs are not expected to or one wanted to do that. And I ended up having to, you know, ultimately work through some people to do it. Particularly the principal engineers.

But in general, you know, yes, I will spend time talking to each and every engineering team to understand how what they’re doing is how they’re doing it. Right? And what are the hard things? And how do they find overcome those? And why do they think they’ll be fast enough? Or scale?

Because if you get the physics wrong, it doesn’t matter whether the vision is right, it doesn’t matter, the psychology’s, where did you get the physics from the buttock doesn’t work.


CW: So you’ve done, you know, looking back through your experience, you seem to oscillate between doing a startup and doing a big company thing and doing a startup and doing the big company thing. Is that an oscillation because you’re so tired of one model or the other is that opportunities is that… and and and compare and contrast the the startup world versus I mean, you’ve worked for several of the biggest of the biggest companies, you know, Microsoft, Google, Amazon, Salesforce. But you’ve also done you know, you started out doing a startup or really early on. And…

AB: So it’s a little misleading. I mean, really, all I’ve ever done are startups, if you actually look at my career, and you ignore who I’m working for, I’m always working on startups. Period. Like, I’ve never before, as far as I know, ever worked on version two of anything. And everything I’ve ever done was a startup.

So the real question is, are they startups that I start, or the startups that I start with in a big company. And it turns out that I’m much better at the latter than the former. Why?

Well, there’s two choices when you start your own company. choice. Number one is you’re the CEO. If you’re the CEO, you should be a salesperson. And you should be greedy. These are two requirements. Because if you’re a greedy person and a good salesperson, you will both be very good at talking to customers. And because you’re greedy, you will be very practical and making sure you find some customers willing to write checks, you listen to them very carefully, you build what they want for that check. And then you generalize from there. And that is the general winning recipe for startups. You will not have a vision. Notice the statement.

For every startup that successfully was started by someone with a vision, there are 99 that failed, maybe 999 that failed. Whereas for every startup started with a real customer had an itch and solved the itch, you know, the numbers were vastly better.

So in general, someone like me should not be doing startups. That would be my first comment outside of big companies. Big companies have the bankroll and the time. But the bigger thing is in a startup, there’s only one sail and you’re the winds behind that sail flag. So you go in irons, you’re dead.

In a big company, you know, the company is fine. It’s highly diversified. It’s got a zillion products out there generating revenue and you know, creating its own wind, in terms of customer demand. And your job is just to go add, you know, one more boat to that fleet. Maybe it’s an important boat, you know, yeah, the Trident stuff turned out to be important, maybe it’s not. But in a big company, you have the resources to do hard things over longer periods of time. And so, but you have to have a boss who’s invested and believes in what you do.

CW: It sort of sounds like what you were saying before, which was you, if you’re going to go do a startup, you really want it to be a fully formed product. And therefore you need to have the time and patience and resources to be able to execute a fully formed product, right?

AB: That’s right. I mean, I think that’s a short correct description.

Like I’m good friends with Marc Benioff. And Mark, if you looked carefully at Salesforce took the opposite approach, Marc had the same sweeping vision I did when I started Crossgain, when he started Salesforce, and we knew each other well, But Mark started by building this incredibly simple thing, which was the original CRM product, which was incredibly simple engineering, it was this tiny little layer called Resin sitting on top of PL SQL sitting on top of Oracle, and effectively is using Oracle as big table. So it could be multi-tenant. And he had one data center, there was no redundancy, there was no failover. That was it.

And you know, that worked. Right? And he had momentum, right, and he could get out the door. And then he could, with some help from me, and help many other people go and build the platform, and slowly generalize what he had, you know, look at him today. But that’s because Mark is the neoplatonic ideal, but I just described, he’s a customer obsessed sales guy. And he’s actually not greedy, but he likes to win. So that was a reasonable proxy. Mark is actually exceedingly generous.

You know, I think the point I’m making is, yes, I went back and forth, what really happened was, I didn’t like the companies I was in when I left them. So Microsoft in 1999, didn’t feel like a good place. It felt like it’d become big and arrogant, and a bully. And I liked Bill a lot. As you know, I was wonderful working for Bill. But I didn’t like the people who had risen under Bill by late 1999. And so I left because I didn’t want to be part of the company not because you know, of any other reason. I didn’t really want to do a startup, I kind of accidentally…

Like the only startup I ever intentionally started that made sense was the first one. The second one really didn’t make sense. So it’s deceptive. I mean, really what I do are startups. And I don’t do them anymore. Now I’ve stopped, but they’re within big companies.

CW: You touched on a subject I wanted to get to. You, you’ve also worked for, you know, for companies with almost diametrically opposite cultures, right. I mean, Microsoft is a very different company than Google, which is very different than Salesforce, which is very different than AWS, with respect to the sort of their, their company cultures. Did, did one fit better than another?

AB: You know, I think you learn from every one of them, and you learn a lot. And every one of them has extraordinary strong suits, otherwise, they wouldn’t be where they are.

I mean, in the end, I think the most functional culture that I worked at, was probably AWS and Amazon. The leadership principles are spectacular. They really are followed. They’re observed, they’re listened to, they’re adhered to, everyone is interviewed based on those principles. Everyone is reviewed and graded on those principles. You know, when you write six pagers, or when you critique people, you critique on the basis of the principles. The company has a very clear, very good culture that is really, really well designed to produce a great, great operational culture.

It does make it hard for the company to deal with things that require major changes in direction. It’s a more tactical than strategic company. And so when for, you know, for example, you know, at a certain point in Microsoft’s life, the balkanization that came out of everyone having fun building their own thing became a negative rather than positive feature. And ultimately, we had to build two things. We had to build Studio for the database and tools and then later, of course, Azure, and we had to build, you know, Office for the business apps. And they had to be welded together to be more consistent and more uniform. Right. And that was an incredibly painful change in culture. And it was a strategic change driven by Bill It was not a tactical change. It was a difficult strategic change driven by Bill.

It’s not clear to me that Amazon can do that. But this isn’t it doesn’t run that way. It’s not you know, once in a while Jeff will have some top down initiative. But in general, it’s not been that way. And it’s the tenants are you against, particularly be frugal.

So Google, Google has one great, great quality, its culture, which is not only they hire really brilliant people, and they give them a lot of room to run. And they have a lot of, they’re not in a hurry. Like, you’re never gonna get, maybe you will. But in general, Google’s not in a hurry. They just want to get it right. And they hire these really thoughtful people who really just think very, very hard about what’s right. And none of them suffer from NIH, none of them, all of them will go out and do a ton of research as to what’s this, you know, what did what is the prevailing understanding, what is the best thinking and the best research, and they’re incredibly well connected with the universities because of this, and they hire these people. So you know, Google led on machine learning from very early on, partly because they, you know, they had this relationship where they didn’t assume they knew everything. And so they were willing to learn. But it’s really, really hard to get anything done at Google. You know, it’s a glacial pace, and you never own anything.

And then the other thing you learn from Google, that’s super impressive is the KPIs. Like, when I used to run Google Suite, I’d walk through the, you know, the wall of floors in the morning. And there were these monitors up there everywhere. And they were red, yellow, or green. And they were measuring every KPI and every KPI was both what numbers should we be achieving? And if not, where are you know, where are we? So it’s both volume and performance numbers. And if they were green, I just keep walking. If there were yellow, I’d slow down, start asking questions. And if they were read, I’d stop and spend the day there? Right. And it was incredibly effective strategy that everyone saw from the beginning because people… You’ve heard of test driven development, and Google’s basically KPI driven development, you started with the dashboard and work backwards. Not quite, but you get the idea. That was in super impressive thing I haven’t seen any other company do now at least at that level. Every other company has dashboards, but they don’t, they’re not up there on giant screens in front of all the engineers all day long going red, yellow and green like that. So from Google, you and you learn a ton about collaboration industry work, which I happen to have lucked into accidentally when I was at Microsoft, through the XML work.

At Microsoft, you know, the big wins when I was there, were you know, hire very bright, very pragmatic people and bias for action to use the Amazon term. And it was abetted by Bill giving people a lot of authority. Right. And so the big wins for a lot of smart people almost in the Zuckerberg thing moving fast and breaking. And then when Microsoft had to change, it was hard. Right? Because, the culture really wasn’t around that. The problem the Microsoft culture, frankly, when I was there was it was really brutish. It was frat boy locker room brutish, it was super aggressive. You know, it was not polite. Like I never the entire time I was at Google heard anyone swear? In any meeting ever? Think about? Not once.

CW: That’s unusual.

AB: Well, that’s Google.

CW: No, no, I get it.

AB: But at Amazon, it’s rare. You’ll hear it, but it’s relatively rare. Okay, people try are tend to be much more, much more constrained and much more polite than at say Microsoft at least when I was there, Satya may have changed it beyond all recognition.

At Salesforce, you know, you have a completely different culture. But the thing that Salesforce is geniuses at, is understanding the importance of messaging, and then lining up behind the message and pragmatism and prioritization, Salesforce says, is the only company I know every time you do anything, there’s a list and every list is prioritized. And you have to defend every priority.

So you know, the Salesforce culture, you learn the V2MOM, is a magnificent mechanism. Mark knows, he taught me this mechanism. When I was doing my third startup. And, you know, the V2MOM is a great, great mechanism for making sure that you have a great company. And you know, that was something you learned. So yeah, they’re all different companies. My view is they all have things to learn.

CW: But back up and tell me what’s the V2MOM.

AB: So V2MOM is how Salesforce is managed. And so as opposed to six pages by which AWS is managed, and the group gropes by which at least Google used to be managed, and the various mechanisms that were sort of mostly unwritten before at least you were head of HR at, at Microsoft.

So V2MOM stands for values, I’m sorry, vision, values, methods, obstacles and metrics. So V2 is vision and values, and you write them down, but you read an ordered list of values, which would be tenants at Microsoft, I mean, I’m sorry to Amazon. And then you write down what are your methods which are basically what are you going to do? And then you write the only way obstacles which are What is it? What is it going to make it hard to do these things? Like what’s going to make, you know, fly in the face to be getting these things done? And then you write down metrics? How are you going to measure that you actually got them done? You know, what are you committing to? And how you going to measure yourself to see if you actually delivered it much like Kp? You know, what are they called the ones that, OKIs at Google, and then everything sorted for high priority, low priority. And, you know, there’s a really, really careful attempt to make sure that you understand what the priority of every item is. And then anything that’s not high enough for it gets weaned from the list, because you can’t really do that many things.

And that mechanism works really, really well. I mean, the company is not a state of the art engineering company. But it’s a super effective company. Because they institutionalize this method to make sure that whatever the vision is that Mark has, that vision is carried all the way down to everyone’s V2MOM, every single employee has a V2MOM.

CW: It sounds to me, like the cultures that you’ve just described, match and mesh with the companies and their objectives. For example, you know, Amazon is an incredibly tactical company that worries significantly about, you know, how long it takes to paint the webpage and how, you know, all the efficiencies of their, of their operational metrics, right, and everything from deliveries. And I mean, it’s all incredibly operational. So they’ve created a culture with some very strict and careful tools that help them manage to that operational culture. Salesforce, you described, it’s sort of about executing against the vision, Google has this wonderful value of the fact that they’ve got billions of transactions happening at every second. And so they can do the KPIs live in real time. And so it sounds to me like these companies have all sort of made a culture that matches their, their core, fundamental corporate need.

AB: I think it’s the other way around. I think, because they had that culture, they gravitated to the products that fit their culture. To be quite honest.

It’s a little hard to describe, I mean, you know, I was at several of these companies when they were small, like 2000 people. So not small, small, but relatively small. And I was working with Salesforce when they were, you know, 20, 20, 30, I was an advisor. Um, I think what really happened was, they had a culture. And the way they approached the market was very, very heavily influenced by their culture. And then what they became good at were things that that culture would make them good at.

And I mean, you could ask, why was it that Yahoo fell so far behind of Google on ads, it should never have happened. But Google’s culture was leading edge, sorry, academically informed technology. Right, that with constant KPIs to measure sort of click through rates. The Yahoo culture was much more media culture, you know, where a shop, the shop front, you know, and that and and they actually had separated the product, sorry, that the general managers from the engineering team, which was a core function, and that was disastrous, right.

So I think it’s more, or Jeff from the various as far as I can tell, from the very early days, Amazon ran that way, and the culture was the same. And so the culture was this intensely operational, take no prisoners, move fast, learn from your mistakes, and hire the best people, culture. And that culture when it was put into the cloud under Andy Jassy, you know, was a super pragmatic take no prisoners learn fast? You know, and they carried it right through.

Google approach the cloud, but they did it from exactly the opposite point of view, how do we make sure that everything we do will be done once in one consistent way and scale? Right. Whereas Amazon’s focus from the very beginning was, how do we in fact, it’s interesting, like the big focus at Amazon when I was there, it was blast radius. Blast radius is how many people go down, if you check in a bad piece of code, or there’s a bug or something bad happens, you know, hardware failure. The basic mantra at Amazon is, the fewer the better, right? And so everything is designed in cells, things are rolled out, first to 1% in the mean of five and then 10, and only my only later to 100. Make sure that at any given time, the number of people who are negatively impacted by something is as small as humanly possible.

Like even when we built Honeycode, it was designed as a pod architecture from the very beginning for this reason. So you know, the Amazon focus, which they learned, you know, because of all the operational issues they’d all hit. The very first bookstore they ever built was designed around operational issues. And how do you have a culture to manage operational issues? Because Jeff is a very operational… he was a visionary God knows, but a very operational guy.

You know, the Google culture was sort of the opposite, right? It wasn’t an operational culture at all. But they were very, very focused on what they could theoretically do to improve the numbers. And how good they are. Larry is only interested in things with big numbers. So they’re focused only on big numbers.

So I, you know, you could look at it either way, but I think it’s more that the industries that they excelled in were the industries where their culture was a winner in the industry is, you know, for example, Google, at least at last reading was still not a serious player in the enterprise. Maybe under […] that will change. But hadn’t, you know, for the first 15 years of Google’s life it was not a serious player in the enterprise. But that’s because there was nothing in their culture that they knew how to sell to the enterprise, cared about the enterprise, you know, wanted to integrate with the enterprise or in any other way. makes sense for the enterprise, right?

CW: Did you mesh well, with one particular culture versus another? Did you thrive better in one than another? Did you like one versus another?

AB: Well, I thrived it you know, it depends on the point in my career, overall, I would probably say, I liked the AWS culture the best. Because it suits me more. It’s kind of you know, if you look at the leadership principles, they’re all 14, like I love about 13 of them. So the Amazon culture suits me really well, what happens, and I’m not a great senior manager by Amazon panel standards, because of this issue of operational excellence. But you know, everything from raising the bar to hiring the best to, you know, you know, having backbone and disagreeing to, on… pretty much every, every leadership principles when I believe, and I thought the culture embodied it really well. So for the first two years, I was there, I was super comfortable. Because … and the only reason I got uncomfortable, was it Andy, and I started to differ when I wasn’t delivering on the speed of the, so I thought that I couldn’t thought that I should have. And he realized, you know, the operational issues there. And then I think he over over react to them, it’s a matter of opinion.

But the Google culture was very difficult for me. It was very difficult because both politically it was a clique. I was like a high school clique. And it was also you had no authority, I would have one general manager after another come into my office practically in tears and say, am I crazy? Or is the company crazy? And so what do you do mean? I can’t do anything, I have no authority. And they were right. And they were really hired to be process managers, and not to have any authority. And so that was a very difficult culture for me. And not when I was comfortable in at all. I loved building Google Suite. And I actually was having fun with Google house. But the culture was not what I was comfortable in at all, either from a political or an operational point of view. And I think perhaps tellingly, apart from the people I hired into Google, I heard a bunch. They’re relatively there are no actually people that I’ve sort of maintained relationship after I left.

The Microsoft culture, you know, was it was deceptive, like, as you probably know, at a very good relationship with Bill. And he trusted me. And, you know, I had a surprising amount of autonomy, because it was known that he trusted me. And so I had a lot of fun there. Like I had a great time, I left only reluctantly, because I didn’t like what the company become. But I was having a wonderful time. So as soon as suited me very well, but I didn’t like the culture. It was just that I had a lot of freedom to do what I wanted within it. I like the freedom.

On the Salesforce culture. I’m too much of the technologist to be happy at Salesforce. I can look at it, I can admire it. I can look at Mark almost with awe in how he executes. I can absolutely see that it wins. But as someone who wants to build great technology, it’s not a place I want it to be. That’s not a ding on the company. Because what they do they do really well. They’re very focused on what do they need to do? Like? And several times I argued with Mark, he needed to rewrite something. He said, No, we don’t. And they didn’t. And he was right. He didn’t. This is when I was chief strategic officer. So the Salesforce culture didn’t really suit me. But it was because it was a culture of a pitch. It’s a pitch culture, you go in and you make a pitch and however compelling your pitch is, that’s how much credit you get what you get to do. It’s not a culture of analysis. It’s not a culture of technology. And that was just you know, was was a difficult thing.

So for me Microsoft was when I was happiest in, but it was it was sort of an accident of fate because I just had a lot of de facto authority do what I wanted to do. And then I was very happy at AWS for a couple of years, because I really did like the culture operationally. And otherwise, the culture suited me.

CW: Yeah. So you ended up leaving AWS, and you’re now doing some, some consulting, I guess, or some mentoring or some angel investing…

AB: Sort of the same thing, you know, I’m talking to three, I guess, now four companies. Everyone has a vision that happens to fit something I’m I know about and, you know, have insight into. Much as originally I was advising Salesforce in those first four years.

In every case, I happen to really like the people who brought me in. And so the conversations from the very beginning, I’ve been good and collegial. In every case, you know, I’m not saying this is what you should do, I’m saying, here are design principles, and here are some things you are doing are violating these design principles. And as a thought experiment think through these use cases, and what could you do better? You know, why is it that I say this one doesn’t work well. But I’m trying to teach people much more how to design and how to build the right UI, or the right engineering or the right user model, particularly user model, than I am trying to tell them what the user model should be.

Now, that doesn’t mean, you know, you don’t go back and forth on that. Because you have to say, I find this really confusing, here’s a user model I would understand. But it’s all it’s all really a combination… I mean, I really believe in the company. So I was also able to recruit for them. And I’ve also been able to help some of them raise money, but or bring in talent they needed. But what really what I’m doing is teaching now, rather than doing

CW: And so you are, are you? Are you on the boards of these things? Or are you just being sort of a…

AB: I am not because, you know, I wouldn’t be interested, you know, it’s the same problem is why I didn’t manage 1000 people, you know, the boards are gonna worry about money, and they’re gonna worry about… you know, all sorts of things. I’m just not interested.

CW: Right.

AB: I’m interested in are they got the right vision of the product? Getting easy enough to use and simultaneously powerful enough?

You know, Alan Kay’s dictum, in some sense, is the root of everything I believe, which was the simple thing should be simple and hard things should be possible. And, you know, I, I worry about that a lot. And over and over, I’ll sit with teams, and I’ll say, okay, the simple thing is simple. But the hard thing is impossible. Okay, the simple thing is now hard, although the hard thing is now possible, you know, how can we do this better.

So I’m much, much more focus with working with teams of engineers and product people. I did help a big company on a strategic vision, but even then, it was a strategic vision around the product. And it was a vision, right? It was a product vision. So you know, it’s helping them put together a strategic plan for the next three years. And they reupped. So I’m going to go on helping them. But it’s not the same thing. I’m basically coaching.

CW: And so are you working with the CEO or with the directors of engineering, or the…

AB: One CEO of a startup, because it’s a smaller company? Yeah. Even though I work with the also the head of product and engineering, and then a bunch of a bunch of the engineers and product people?

CW: Yeah.

AB: And then I do work with a board. But that’s because I’m advising them on things they need to do to fund this company. Or because I helped this company raise around $10 million round, and in the middle of the pandemic.

CW: Wow

AB: I’m working. Yeah, about two weeks or three weeks. And they’re the CFO, CEO. And I have a very, very good, we have a relationship as good as Bill.

And then I’m working with the CIO of a very big company. And then we have again, as good a relationship. And, you know, we just talk a lot. And I work with his people. So I work with key architects, particularly here, architects, and then some key product and engineering people under his team.

And then the other team is more interesting company, because they’re big, big company, they’re public and there I work with the CIO, I’m sorry, the CTO and some other very senior people who’ve been there a long time. But all of us are working to basically effectively do to the company, what’s Sinofsky did to the individual products that became Office, but in a way where we get buy-in as we go. And so that’s a really interesting effort. And again, I work really well with the two people I wouldn’t have re-upped otherwise, that are sort of the key people… I work with the CEO too, and the CEO’s the one who brought me in along with the head of the board. But I don’t really work with him very much.

CW: With the singular exception of some of the work you did in the health arena, though, literally everything you did the stuff, the work you did at Microsoft with Access and, and those sorts of things, the work he all the way through to the work you were doing at AWS is all around this singular vision of trying to make sort of computer power accessible to…

AB: That’s right. That is that is the thing I wake up wanting to do. Even now the companies I advise are all around that area. And particularly the one in Mexico City, which I love company called Yellow Chat. And that’s my passionate belief is that, you know, computing is too valuable and too exciting and too wonderful to be sort of owned by the geeks, it should be known by everybody. And unlike Hadi Partovi, I don’t think everyone can or should program, I think they shouldn’t need to.

CW: It’s fun to see back through your life experience and see that thread, find its way through all of the various pieces.

AB: While I’m very persistent, in my own way…

CW: I want to thank Adam for this wonderful conversation. As I noted, it’s so much fun to explore the various companies and cultures he’s worked in, as he has relentlessly pursued his goal of making computing power easy for everyone to use.


Leading Smart is from me, Chris Williams. You can find out more about the show and discover other resources for leaders at my website, CLWill.com.

If you liked the show, please share it with your friends, especially on social media. Referrals are the greatest source of new listeners.

I’d also love your feedback. I’m theCLWill on Twitter, LinkedIn and Facebook, or send an email to pod at CLwill.com. That’s it for this episode. I’ll be taking a short break for the holidays and the next two episodes will be revisits of two of my favorites from season one. I hope you’ll listen. Until then, please remember that each of the several dozen decisions you make today are part of Leading Smart.